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 creates an Agent Wallet as a deterministic proxy for an owner and agent index. The address can be calculated before the wallet is deployed, and initialization associates the wallet with its owner, base asset, registry, and shared configuration.
See AgentWalletFactory and YieldSeeker AgentWalletV1.
ERC-4337 authorization
Section titled “ERC-4337 authorization”Agent Wallets validate ERC-4337 UserOperations. A valid operation may be signed by the owner or an authorized agent operator, subject to the wallet’s current authorization state.
Operator configuration can be cached for gas efficiency. After a Factory-level operator change, wallets may need to synchronize their cached configuration; the registry pause is the immediate emergency execution control.
Adapter-only execution
Section titled “Adapter-only execution”Agent operations use executeViaAdapter rather than an unrestricted arbitrary-call function. The requested adapter and target are checked against the Adapter Registry before the adapter runs in the wallet’s context.
Adapters should validate operation parameters such as the underlying asset, recipient, vault, pool, or swap route. Stateless adapter code executes through delegatecall and should not hold user funds itself.
Registry and emergency controls
Section titled “Registry and emergency controls”The Adapter Registry maps approved targets to adapters and can remove targets, disable adapters, or pause adapter execution. These controls apply across wallets that use the registry.
The registry can stop future adapter-backed operations, but it cannot guarantee underlying protocol liquidity or undo a transaction that already settled.
User controls
Section titled “User controls”The wallet owner can withdraw supported tokens and ETH, block adapters or targets, and use the wallet’s approved upgrade path. Platform administration cannot replace owner withdrawal rights with a server-only withdrawal path.
Upgrade and timelock model
Section titled “Upgrade and timelock model”Wallet implementations must satisfy the Factory’s approval rules. Administrative changes should pass through the deployed timelock process, giving users time to review a change or exit where appropriate.
Always verify the current deployed contracts and delay before relying on a specific address or guarantee.
Threat model
Section titled “Threat model”A compromised server may be able to sign operations as an authorized operator, but the intended controls limit it to registered adapters and targets with adapter-level parameter validation. It should not be able to use arbitrary calls, redirect assets to an attacker, or upgrade a wallet as the owner.
This is a risk-reduction model, not a guarantee that adapters, registries, protocols, infrastructure, or future implementations are bug-free.