Execution framework

The execution framework turns a type-specific strategy decision into a constrained blockchain operation. It is shared by current and future agent types.

Execution flow

flowchart LR
  Decision[Strategy decision] --> Wallet[Agent Wallet]
  Wallet --> Registry[Adapter Registry]
  Registry --> Adapter[Registered adapter]
  Adapter --> Target[Registered target]

1. The runtime prepares an ERC-4337 UserOperation. An owner signature can authorize supported wallet actions; an agent-operator signature is accepted only for executeViaAdapter or executeViaAdapterBatch.
2. The wallet rejects the unrestricted execute and executeBatch entry points, applies its owner-controlled adapter and target blocklists, and checks the requested adapter against the target’s registry mapping.
3. The wallet delegatecalls the approved adapter. That adapter validates its supported operation and parameters before calling the protocol target.

Adapter-only execution

Each adapter accepts defined operations and validates their protocol-specific parameters. The wallet’s ordinary execute and executeBatch methods revert, so agent operations cannot use an unrestricted arbitrary-call path.

Registry controls

The Adapter Registry’s admin role registers adapters and maps targets; its emergency role can remove a target, unregister an adapter, or pause the getTargetAdapter lookup. Pausing that lookup blocks adapter-backed calls through the registry; removing a target or unregistering an adapter blocks calls through the affected mapping or mappings. Neither action blocks direct owner-only withdrawals of ETH or withdrawable base asset, and neither can reverse a settled transaction.

Owners can also block adapters or targets for their own wallet. A registered target is approved for a particular adapter, not a guarantee that the underlying protocol is safe or liquid.

Adapter context

Adapters run by delegatecall, so their code executes in the Agent Wallet’s context and makes protocol calls from that wallet. The adapter supplies protocol-specific validation and call encoding.

Agent-type boundary

The framework is shared, but the operations and risk checks are type-specific. Vault Agent adapters support vault, lending, reward, and swap operations; a future type must document its own adapters and validation rules.

See Security for the user explanation and AgentWalletKit integration for implementation details.