How AI agents execute trades onchain: intents, ERC-4337, and token permissions

How AI agents execute trades onchain comes down to plumbing, not “AI magic”: the agent produces signed intents that other actors turn into Ethereum state changes. The trade only settles if two rails are wired correctly, the execution rail (EOA transaction or ERC-4337 UserOperation) and the token-permission rail (allowances or Permit2-style permits).

Key Takeaways

• An AI agent does not “trade” by itself on Ethereum. It must control or be authorized by an onchain account that can trigger contract calls and token transfers.
• There are two execution rails: an EOA-originated transaction, or an ERC-4337 UserOperation that a bundler submits to the EntryPoint contract for verification and execution.
• Swaps require explicit token spending permission before token movement, and Permit2 AllowanceTransfer adds expirations and per-(owner, token, spender) nonces to bound and replay-protect that permission.
• For larger size or stricter controls, a Safe can separate duties by letting the agent propose a transaction while multiple owners confirm before execution.

How an AI agent can trade onchain

A model output is not an onchain action. The chain only reacts to messages that pass signature checks and call into contracts from an account that holds assets. That is the core reality behind autonomous onchain trading: the “agent” is an offchain decision engine, and the onchain part is an account plus a signed request that the network will accept.

Two rails show up on a block explorer. The first is the execution rail, meaning how the request becomes an Ethereum transaction. On Ethereum, only an Externally Owned Account can originate a transaction, because an EOA is controlled by a private key and signs the transaction directly. A smart contract account can hold assets and run logic, but it cannot originate a transaction on its own. It only does work when it is called by something else.

The second rail is token movement. A DEX swap is not “just calling a router.” ERC-20 tokens do not move because a swap function was called. They move because the token owner has granted spending authority to some spender, and then that spender uses that authority to transfer tokens. If the agent is building onchain agent execution that touches ERC-20s, it has to solve both rails every time: (1) get the chain to execute calls, and (2) ensure the right contract is authorized to pull the right amount of tokens.

This is where defai products cluster: autonomous execution wrapped in wallet UX, with guardrails around what gets signed and what gets spent. The useful mental model is the same one behind what is defai autonomous onchain execution as a category: the agent authors intents, and infrastructure turns those intents into settlement.

The ERC-4337 execution pipeline

ERC-4337 turns “send a transaction” into a supply chain with extra actors, and that changes reliability assumptions. Instead of an EOA broadcasting a transaction into the public mempool, an ERC-4337 wallet constructs a UserOperation object and hands it to a bundler that later submits an onchain transaction to a singleton EntryPoint contract.

The end-to-end flow is easiest to track as a sequence:

1. The agent prepares a payload. For an agent wallet that is an ERC-4337 smart account, the payload is a UserOperation with fields like sender, nonce, callData, gas limits, fee parameters, and a signature. 2. The agent submits the UserOperation to an alternative mempool. Wallets typically send it to a bundler RPC endpoint rather than the standard Ethereum transaction pool. 3. A bundler collects and simulates. Bundlers watch the alt-mempool, simulate candidate UserOperations, and decide which ones to include in a bundle. 4. The bundler originates the onchain transaction. The bundler calls EntryPoint.handleOps with an array of UserOperations, and that call is the actual Ethereum transaction that lands in a block. 5. EntryPoint verifies, then executes. EntryPoint follows a two-phase pattern: it calls validateUserOp on the account (and validatePaymasterUserOp if a paymaster is attached) and only then runs the execution phase. 6. Gas is settled via prefunds or a paymaster. ERC-4337 allows a Paymaster contract to sponsor gas by reimbursing the bundler under defined rules.

For ai trading agent mechanics, the key point is not the signature format. It is who is responsible for inclusion. With ERC-4337, “agent executed” is not when the agent signs. It is when EntryPoint executes, and that depends on bundler behavior and paymaster rules if gas is sponsored.

How agents get token spending permission

Token movement is where most agent designs leak risk, because permissions tend to outlive the trade. The clean model is permission first, execution second. ERC-4337 can compress those into one settlement by bundling multiple actions into a single UserOperation, but the permissioning still has to be explicit and bounded.

Uniswap’s Permit2 AllowanceTransfer is a concrete set of primitives for this layer. It supports three core entry points: approve (set permissions onchain), permit (set permissions via a signature), and transferFrom (spend when valid permissions already exist). The important difference versus the old “approve max forever” habit is that Permit2 allowances can be time-bounded using an expiration timestamp.

Permit2 also gives a practical replay-protection handle that agents can actually use. Its nonce schema increments nonces per owner, per token, and per spender, packed into an allowance mapping. That means a permission is not just “did the owner sign once,” but “did the owner sign this specific spend window for this spender, and has that nonce already been consumed.” Permit2’s permit supports EOA signatures, EIP-2098 compact signatures, and EIP-1271 contract signatures, which matters when the owner is a smart account rather than an EOA.

For how agents trade DeFi, this is the operational pattern that shows up when things are built carefully:

1. The agent requests a narrow spend window. Amount is capped, expiration is short, spender is specific. 2. The agent packages permissioning with execution. A permit or approval can be combined with the swap call so the allowance does not sit around unused. 3. The agent spends via transferFrom only under that window. If the window expires, the permission is dead onchain.

This is also where intent based execution and a solver network fit conceptually. The agent can sign an intent that expresses the desired outcome, while solvers compete to route and settle it. Regardless of who routes, the token-permission rail still decides what can be pulled from the owner account.

Multisig and policy controls with Safe

The most robust control pattern for real money is policy separation: let the agent propose, but require a Safe threshold to execute. That keeps automation while removing unilateral authority from a single model-run key.

Safe’s documented flow is explicit about the handoffs. A transaction is created, proposed to the Safe Transaction Service, confirmed by other owners, and only then executed. In the Safe Protocol Kit guide, the sequence is: create a transaction object, compute the Safe transaction hash, propose it so other owners can see it, collect confirmations (signatures) from the owners, then execute with executeTransaction.

That matters for autonomous execution because it changes what “agent action” means. The agent can generate the exact calldata for a DEX router call, or for an ERC-4337 account’s executeBatch, but the Safe is the risk desk that decides whether that payload is allowed to hit the chain. This is a clean place to enforce policies that the sources do not standardize for agents, like limiting new spenders, requiring extra confirmations for new tokens, or gating size.

Safe also plays well with session key patterns at the account layer. ERC-4337 accounts can validate different signature schemes inside validateUserOp, and a session key can be one of those schemes. The point is not the buzzword. The point is that a short-lived key can be authorized for narrow actions while the long-term owners retain ultimate control.

For teams building defai systems, this is the difference between “the agent can trade” and “the agent can draft trades.” Drafting is cheap. Execution is where irreversible state changes happen.

Design tradeoffs and failure modes

The first failure mode is confusing message types. A UserOperation is not an Ethereum transaction. It is data in an alternative mempool until a bundler wraps it into an EntryPoint.handleOps call. That is why smart contract accounts cannot “just send transactions like EOAs.” Only EOAs originate transactions, and smart accounts act when called.

The second failure mode is treating the bundler as invisible infrastructure. ERC-4337 shifts assumptions from “my wallet broadcasts” to “will a bundler include me.” Eco’s description is explicit that bundlers watch the alt-mempool, simulate, and submit bundles, paying L1 gas and getting refunded from prefunds or paymasters. If a bundler endpoint is down, rate-limited, or refusing certain operations, the agent can keep signing and nothing will settle.

The third failure mode is permission sprawl. Unlimited approvals are not a trading feature. They are a standing loss surface. Permit2’s expiration timestamps and per-(owner, token, spender) nonces are the onchain controls that can bound that surface, but only if the integration uses them. A common integration mistake is authorizing the wrong spender or passing the wrong from address into a transfer call, which Uniswap flags as a security consideration for integrating contracts.

The fourth failure mode is over-crediting the AI. Most blowups in onchain agent execution come from wiring, not from the model picking the wrong side. If the agent wallet can sign a broad permit, or if the paymaster rules are too loose, the system can do exactly what it was authorized to do, and still be unacceptable.

The tradeoff summary is straightforward. EOAs are simple and direct but put the whole system behind one key. ERC-4337 adds batching, custom validation, and sponsored gas, but introduces a transaction supply chain with bundlers, EntryPoint, and optional paymasters. Safe adds friction by design, and that friction is the point when size matters. Near the bottom of any serious architecture doc, the broader topic is still autonomous onchain execution, and the question is which rail and which policy layer the system can actually support under stress.

The Take

I’ve watched teams obsess over the “AI” part and then ship the expensive mistake: a wide, long-lived token approval paired with brittle infrastructure. When something goes wrong, it is rarely because the model hallucinated a trade. It is because the permissioning layer let a spender pull more than intended, or because the ERC-4337 supply chain stalled at the bundler and nobody was monitoring inclusion.

The clean posture is to treat this like a two-key diagram every time: execution authority and spend authority. If the design can’t answer, in one sentence, who originates the transaction (EOA vs bundler via EntryPoint) and exactly what the spender can pull (amount, expiration, nonce scope), then the system is not “autonomous.” It is just unattended.

Sources

• QuickNode
• Eco
• Uniswap
• Safe