As financial institutions move more capital onchain, the security question is expanding beyond whether a smart contract has been audited. A contract may function exactly as designed while the transaction produces an outcome different from the one a user was quoted or intended to approve. Changes in liquidity, transaction ordering, routing and blockchain state can all affect the result before settlement.
This execution gap becomes more consequential as financial activity moves across multiple protocols and blockchains. It also raises difficult questions about accountability: when an institutional transaction fails or produces an unintended result, responsibility may be divided among the application, wallet, routing provider, underlying protocol and end user.
The emergence of autonomous AI agents adds another layer of risk. Agents capable of initiating transactions at machine speed will require enforceable permission limits, spending caps, pre-execution validation and emergency controls—not merely instructions embedded in an AI model.
In a written interview with Korea IT Times, Enso CEO and Co-Founder Connor Howe and Co-Founder Milos Costantini discuss how simulation, validation and real-time verification can establish continuity between transaction intent and settlement. They also examine what institutions, regulators and risk committees will require before AI-powered financial agents can be entrusted with capital.
The following is Korea IT Times’ interview with Connor Howe and Milos Costantini.
1. As institutional participation in onchain finance grows, why is execution integrity becoming as important as smart contract security? Which risks within the transaction execution process remain most underestimated by institutions?
Connor Howe: For years, the industry treated a passed audit as the end goal, meaning that if the contract was sound, the transaction was safe. I don’t think that’s the full picture: a contract can be flawless, and a transaction can still cost the user far more than expected because the risk has moved out of the code and into the moment of execution—the gap between what you intend, what you are shown and what actually settles.
Smart contract security asks whether the code is correct. Execution integrity asks whether the user got the outcome they agreed to. Institutions moving real volume feel the second question far more acutely because it is the one that shows up in their reconciliation.
The most underestimated risk is a state change between decision and settlement. Institutions come from deterministic systems. Onchain, the state your quote was built on can shift between the block you simulated and the block you land in. Sitting behind that is over-trust in a single data source or routing path. When one component quietly degrades—a stale price, a reordered transaction or an unexpected pool state—there is usually nothing independently checking it before the value is gone.
Execution integrity is about building those checks in by default through professional DeFi tools such as Enso Quote Simulator, so the quote received matches the delivery.
2. A transaction may appear safe in simulation but produce a different result when executed onchain. What creates this gap, and where are users most exposed to quote manipulation, changes in market conditions or transaction tampering?
Milos Costantini: A simulation is a prediction against a snapshot, and the chain does not stand still. Between simulation and inclusion, the block advances, liquidity moves, other transactions execute ahead of yours, and the assumptions on which your quote rested quietly expire. A simulation that is not tied to the conditions of execution is an estimate, not a guarantee.
Exposure concentrates at three points. The first is quote generation, where a route priced against thin or manipulable liquidity produces a number that looks good but does not survive contact with the market. The second is the mempool, where a public transaction can be front-run or sandwiched, causing the user to absorb price movement engineered by an adversary. The third is the handoff between components, where a transaction is constructed by one system, signed by another and submitted by a third. Every boundary is a place where what the user approved and what gets broadcast can diverge if nothing is checking continuity.
Some of that is market drift. A lot of it is deliberate. We have watched aggregators quote a healthy number against a standard simulated trade and route real capital through a pool engineered to lie. That is why we built the simulator to run before the user signs rather than after: it surfaces the real output amount and price impact, catches routes that will fail outright instead of burning gas and leaving operations unreconciled, flags quotes that have decayed since generation, and shows the costs that would otherwise appear only at settlement. Screening and policy checks run within the same pass, so a non-compliant transaction never reaches the chain.
3. What safeguards should be applied between generating a quote and signing and submitting a transaction? How should simulation, validation, slippage controls and real-time verification work together?
Milos Costantini: Think of it as a chain of custody, where each stage constrains the next.
Simulation runs against the current state and produces explicit bounds, not just an expected outcome: this is the minimum you receive; these are the assets and approvals involved. Validation then confirms that the transaction about to be signed matches that simulated intent: the same route, tokens and recipients, with no approvals or external calls slipped in along the way. Slippage controls are the enforceable backstop—a floor written into the transaction itself—so if conditions move against the user, the transaction reverts instead of settling at a bad price. Losing gas is fine. Losing principal is not.
Real-time verification ties everything together at the last moment, rechecking conditions as close to submission as possible so that what lands reflects a state that is still valid rather than one that was valid three blocks ago.
No single layer is sufficient. Simulation without enforceable bounds is a preview. Slippage limits without validation can be routed around. Verification with nothing signed to compare against has nothing to verify. Integrity comes from the layers holding each other honest and from making the safe path the default rather than an advanced setting.
4. Routing across multiple protocols and blockchains improves efficiency but introduces dependencies and potential points of failure. How should infrastructure providers assess and contain these risks without creating a new systemic point of vulnerability?
Connor Howe: Aggregation earns its place. It is how a client gets good execution across a fragmented market without integrating dozens of protocols itself. But every protocol and bridge you route through is a dependency you have taken on someone else’s behalf, and consolidating complexity behind one interface cannot mean concentrating fragility behind it.
Containment starts with treating every external dependency as untrusted in every transaction. Verify the state you are routing through instead of assuming it. Isolate failures so that one degraded venue cannot compromise an entire route. Design for graceful failure, which means that a transaction that cannot execute safely does not execute at all, and that a route has alternatives rather than one leg that must succeed. Cross-chain transactions layer settlement risk on top of execution risk, so finality assumptions have to be stated rather than inherited.
Becoming shared infrastructure is a responsibility before it is a distribution advantage. The more applications depend on you, the more your failure modes become theirs. The standard we hold ourselves to is that the infrastructure with which we replace the plumbing has to be more robust than the original plumbing—not a convenient single point of failure that the ecosystem has not priced in. Five years, thirteen audits and no loss of user funds. That is the bar, and it is the whole job.
5. When an institutional transaction fails, is manipulated or produces an unintended outcome, accountability can be divided among the application, wallet, routing provider, protocol and end user. How should responsibility be defined, and what audit trails or standards are needed?
Connor Howe: Accountability is divided today because visibility is divided. When something goes wrong across five components, every one of them can plausibly point to another, and the user absorbs a loss that nobody owns.
It starts with evidence. Every transaction should leave a trail that can be reconstructed: what was quoted, what was simulated, what was signed, what was submitted and what settled. A failure can then be attributed to a stage rather than argued about afterwards.
Responsibility should follow control. Whoever builds the route answers for its integrity. Whoever holds the keys answers for what gets signed. The protocol answers for its own contract behaviour. Those responsibilities are separable, but only if the trail is good enough to distinguish between them. What the industry does not have is a shared standard for that trail—common ways to express intent, prove that a signed transaction matches an approved one and log outcomes verifiably.
Institutions will expect it because they already have it. Reconciliation and attribution are ordinary in traditional finance. Onchain, we start with an advantage because the settlement layer is already a publicly verifiable record. The missing work is holding every step before settlement to the same evidentiary standard.
6. AI agents are moving from generating recommendations toward initiating transactions autonomously. What safeguards—permission limits, spending caps, allowlists, pre-execution validation, human approval and emergency controls—should be mandatory before an agent is entrusted with capital?
Milos Costantini: An agent is only as safe as the boundaries around it, and those boundaries have to be enforced by the infrastructure rather than depend on the model behaving well.
Scoped permissions and spending caps set the maximum potential damage. An agent operates within a budget and a set of permitted actions that it cannot exceed, whatever it decides. Allowlists constrain where value can go, which is the single most effective control against a compromised agent moving funds to an arbitrary address.
Every action an agent initiates should then pass the same checks as a human-initiated transaction—simulation, validation, slippage bounds and verification before execution. Machine speed makes those safeguards more necessary, not less. Above a defined risk threshold, human approval should be mandatory; not every action needs a person, but crossing a limit does. There also has to be a stop: a way to revoke authority and halt the agent immediately from outside the agent.
Least privilege, enforced at the execution layer. The agent proposes. The rails decide what is permissible. Autonomy without those rails is not innovation; it is unpriced risk.
7. Over the next three to five years, how do you expect onchain execution infrastructure and AI-powered financial agents to evolve? What must the industry solve before autonomous onchain finance can scale institutionally?
Connor and Milos: Execution becomes invisible, in the same way that payments infrastructure disappeared behind ordinary commerce. Users and agents state what they want; the infrastructure handles routing, verification and settlement, with integrity guarantees built in rather than bolted on afterwards. Agents will be participants rather than advisers, and a large share of onchain activity will eventually be initiated by software operating under mandates set by humans.
Three things have to mature before institutions can rely on that. Execution integrity has to be a guarantee rather than a best-effort commitment, which means establishing provable continuity from intent to settlement so that an institution can trust an outcome without trusting every intermediary along the path. The industry needs shared standards for intent, verification and accountability so that components can interoperate and failures can be attributed to somebody. Agent autonomy also needs permissioning and controls that a regulator or risk committee will accept as sufficient.
The technology is arriving faster than the trust frameworks surrounding it. Closing that gap constitutes most of the work that remains.
Interviewees’ Profiles
Connor Howe is the CEO and Co-Founder of Enso, an execution and orchestration layer for institutional onchain finance. He co-founded Enso at the age of 25 and raised $14.2 million from investors including Polychain and Multicoin. According to the company, Enso has since processed more than $22 billion in trading volume and reached profitability. A blockchain engineer since 2016, Howe wrote the UK’s first Ethereum research paper and helped build blockchain infrastructure for Sygnum, a regulated Swiss digital asset bank.
Milos Costantini is the Co-Founder of Enso. He entered the crypto industry in 2016 after discovering Bitcoin while studying at university. His interest in decentralized finance and alternative financial systems led him to study the underlying technology and subsequently write his thesis on Ethereum.
Costantini began his professional career in Switzerland’s crypto industry, working on enterprise blockchain infrastructure, staking and related services. At Enso, he is developing infrastructure intended to abstract blockchain complexity into a single access point for developers, wallets, agents, neobanks and other applications.
