AgentWalletKit integration and security
This page is the technical companion to Security. It explains how the reusable AgentWalletKit design constrains autonomous wallet operations.
Wallet deployment
Section titled “Wallet deployment”The Factory deploys a deterministic proxy for an owner and agent index; its address can be calculated before deployment. Initialization sets the owner, base asset, Adapter Registry, cached agent operators, and fee tracker.
See AgentWalletFactory and YieldSeeker AgentWalletV2.
ERC-4337 authorization
Section titled “ERC-4337 authorization”The deployed AgentWalletV2 validates ERC-4337 v0.6 UserOperations. The owner can sign supported wallet operations; a cached agent-operator signature is accepted only for executeViaAdapter and executeViaAdapterBatch.
Wallets cache the Factory’s operator list, registry address, and fee tracker. After a Factory-level change, the owner or a cached operator must call syncFromFactory on each wallet to update that cached configuration; pausing a wallet’s currently cached registry immediately blocks that wallet’s adapter-backed operations.
Adapter-only execution
Section titled “Adapter-only execution”The wallet uses executeViaAdapter or its batch form; its standard execute and executeBatch entry points revert. It checks per-wallet adapter and target blocklists, then requires the registry to map the requested target to the requested registered adapter.
The wallet delegatecalls the adapter, which runs in the wallet’s context. Each adapter accepts specific selectors and validates its own protocol parameters before making an external call; adapter code is not a separate custody wallet.
Registry and emergency controls
Section titled “Registry and emergency controls”The registry can remove one target mapping, unregister an adapter (its existing mappings stay stored and become active again if the adapter is re-registered), or pause the getTargetAdapter lookup. These controls affect wallets sharing that registry and can block future adapter-backed operations, but cannot guarantee protocol liquidity or undo a settled transaction.
User controls
Section titled “User controls”The owner can block adapters and targets, withdraw ETH, and withdraw the configured base asset subject to accrued fees. Supported non-base tokens and protocol positions must be handled through approved adapters. The owner alone can use the wallet’s approved upgrade path; platform administration has no server-only withdrawal path.
Upgrade and timelock model
Section titled “Upgrade and timelock model”Factory implementation and configuration changes are subject to the AdminTimelock, giving users time to review a change or exit where appropriate. Production deployment sets its initial minimum delay to four days, but governance can change that live value. Approving an implementation does not upgrade deployed wallets: the owner must call upgradeToLatest, which only accepts the Factory-approved implementation.
Check the deployed AdminTimelock.getMinDelay() and contract addresses before relying on a specific delay or deployment.
Threat model
Section titled “Threat model”A compromised server may use a cached operator key to authorize adapter-call operations, but it cannot sign the wallet’s owner-only withdrawals or upgrades, and unrestricted execute and executeBatch revert. Its calls remain subject to the wallet’s per-wallet blocklists, registry mapping, and adapter implementation. This limits arbitrary-call authority; it does not eliminate risks from a flawed adapter, protocol, or execution infrastructure.
This is a risk-reduction model, not a guarantee that adapters, registries, protocols, infrastructure, or future implementations are bug-free.