‍

From custodial uncertainty to verifiable agent authority

The Agent Wallet Challenge

AI agents introduce autonomous financial decision-making to Web3. This creates a fundamental trust problem: users must delegate transaction authority to agents operating across multiple chains and protocols without real-time approval of each action.

Traditional wallet architectures fail this requirement. Custodial wallets concentrate risk in single authorities managing keys for all users. Standard EOA wallets provide self-custody but lack the programmable policies, gas abstraction, and verification mechanisms that autonomous operations demand. Neither model bridges the gap between AI reasoning and blockchain execution with adequate transparency.

This is a fundamental shift. Agentic wallets are not simply automated signing tools. They are trust boundaries where AI reasoning interfaces with cryptographic authority. The Finance District Agent Wallet addresses this through a three-level architecture progressing from immediate EOA availability through programmable account abstraction to enterprise-grade delegated control.

Our analysis of agent operational requirements revealed a critical insight: we believe over 90% of agent wallet operations require only the baseline EOA wallet. Smart Accounts and Delegated Wallets, while architecturally necessary for specific scenarios, represent edge cases in most usage patterns. This insight fundamentally shaped our design philosophy—build for the 90%, accommodate the 10%.

‍

Core Design Principles

In this post, we explore the architectural decisions that enable trustworthy autonomous wallet operations:

• Three-level wallet architecture: Progressing from EOA baseline through Smart Account capabilities to Delegated Wallet controls
• Self-custodial key management: Hardware-secured enclaves with OAuth-based user control
• Gas-free execution transparency: EIP-3009 offline signing enabling verifiable authorization flows
• Deterministic multi-chain deployment: CREATE2-based addressing providing consistent identity across networks
• Modular verification boundaries: Separating MCP protocol, wallet operations, and blockchain execution into auditable layers
• Session-based authorization: ERC-4337 session keys enabling policy-constrained agent operations
• Resilient state verification: Transaction status confirmation across bundlers and RPC endpoints

These principles emerge from the specific requirements of AI agents operating financial infrastructure through the X-402 Payment Required protocol.

‍

Three-Level Wallet Architecture

The Agent Wallet provides a progressive enhancement path matching agent maturity and operational requirements. X-402 payment authorization requires EOA signatures—private keys signing EIP-712 typed data. Smart contracts cannot sign arbitrary messages. This technical requirement establishes the EOA as the foundational layer.

Our analysis contradicts the industry narrative that agents require sophisticated smart contract wallets. The operational reality is simpler.

Level 1: EOA Wallet: Automatically provisioned on first authentication. The baseline wallet provides immediate X-402 payment capability without deployment costs or setup friction. This EOA signs payment authorizations, executes direct transfers, and serves as the root identity. We believe this level will handle over 90% of all agent wallet operations. Token transfers, payment authorizations, swaps, protocol interactions—the vast majority of agent financial activity requires nothing more sophisticated than standard EOA signing.

Level 2: Smart Account (ERC-4337): Optionally deployed on-demand via CREATE2. The account abstraction wallet adds batched transactions, gas abstraction through paymasters, session key delegation, and social recovery. We anticipate this will represent approximately 6-8% of usage. Deployed when specific features justify the additional complexity—batch operations for DeFi strategies, gas sponsorship for customer-facing agents, or session key constraints for trading bots. Most agents never need this level.

Level 3: Delegated Wallet: Granular spending permissions with multi-signature options and enterprise-grade control. Advanced permission models including token-specific limits, recipient allowlists, time-bounded authorizations, and multi-party approval workflows. We anticipate this will represent approximately 2% of usage. Reserved for institutional treasury management, compliance-regulated operations, and multi-stakeholder governance scenarios. The overwhelming majority of agents will never require this capability.

The same private key backs all three levels. The EOA wallet is the root identity. Smart Accounts and Delegated Wallets are extensions owned by that identity. This architecture resolves protocol constraints while enabling progressive capability enhancement as agent autonomy and capital exposure increase.

We believe this distribution pattern—90%+ Level 1, 10% split between Level 2 and Level 3—will emerge across diverse agent types, use cases, and operational contexts. We expect this distribution to remain stable as the agent wallet ecosystem matures. The baseline EOA wallet is not a temporary solution awaiting smart contract replacement. It is the permanent architecture for the vast majority of autonomous agent operations.

‍

Self-Custodial Key Management with Hardware Security

The wallet maintains strict non-custodial architecture through Finance District KMS integration. Private keys reside in hardware security enclaves with hardware-level isolation. Keys are provisioned per authenticated user and never exposed to applications, AI assistants, or the MCP server.

This architecture builds on institutional-grade custody practices refined through 1st Digital's traditional finance heritage. The same principles governing regulated trust and custody operations—hardware security modules, multi-layered access controls, and audit trails—translate to decentralized key management. The infrastructure meets enterprise security standards while enabling self-custodial control.

Authentication flow: Users authenticate via OAuth 2.0 when connecting AI assistants to the MCP server. The AI assistant receives an OAuth token representing the user. The MCP server uses On-Behalf-Of (OBO) flow to request signing operations from KMS. KMS validates the user token and signs using secure enclaves. The AI assistant receives transaction results without seeing keys.

Key provisioning: On first authentication, the middleware automatically provisions secp256k1 (EVM) and ed25519 (Solana) keys in KMS. These keys are associated with the user's OAuth subject claim. Agent Wallet addresses derive from the provisioned keys. The provisioning occurs transparently during preflight checks before the first MCP tool invocation.

Custody model: Users maintain exclusive control through authentication tokens. The AI assistant is an authorized client, not the wallet owner. The MCP server is a proxy with no custody. Finance District cannot sign without valid user authentication. This architecture preserves self-custody while enabling secure agent operations.

‍

Gas-Free Execution Through EIP-3009

The primary payment model eliminates gas requirements for agents through EIP-3009 receiveWithAuthorization. This standard enables offline signature generation for token transfers. Agents sign EIP-712 typed data containing payment parameters. Sellers execute the authorization onchain and pay gas. Agents never need native tokens for gas.

Authorization signing flow: The agent receives a 402 Payment Required response with payment details. The agent calls the MCP authorize_payment tool. The backend constructs EIP-712 typed data with domain (token name, version, chainId, verifying contract) and message (from, to, value, validAfter, validBefore, nonce). The KMS signs the digest using the Agent Wallet key. The backend returns the signed authorization to the agent. The agent submits the authorization to the seller. The seller executes receiveWithAuthorization() onchain.

Nonce management: Each authorization uses a unique 32-byte random nonce generated via RandomNumberGenerator.Fill(). Nonces prevent replay attacks without requiring sequential transaction ordering. The nonce is independent of blockchain transaction nonces.

Gas economics: This model simplifies agent operations significantly. Agents never manage gas token balances. Failed transactions are prevented through pre-signing validation rather than costly onchain reverts. No bundler or paymaster infrastructure is required for payments. Operational costs concentrate on sellers who have gas infrastructure and business incentives to complete transactions.

‍

Session-Based Authorization with ERC-4337

Smart Account operations use session keys for policy-constrained execution. The SessionKeyValidator module enables temporary signing authority with programmable limits.

Session key flow: Users authorize session keys through Smart Account configuration. Each session key receives specific permissions—spending limits, token restrictions, time bounds, and allowed operations. The Agent Wallet's KMS key serves as the session key for agent-initiated operations. User operations include the session key address in validator encoding.

ERC-7579 nonce encoding: User operations encode the validator address in the nonce key parameter. The encoding follows [validatorAddress:20][mode:1][type:1][counter:2] for 24 bytes converted to uint192. EntryPoint getNonce(sender, key) calls use this encoding to fetch validator-specific nonces. This prevents nonce conflicts across different validator modules.

Gas estimation and limits: The bundler estimates gas requirements for user operations. The implementation adjusts verification gas limits for SessionKeyValidator overhead. Minimum verification gas of 100,000 and call gas of 50,000 prevent underestimation failures. Gas parameters must be hex-encoded without leading zeros per ERC-4337 specification.

‍

Modular Protocol Architecture

The system separates protocol concerns into independent layers that evolve without breaking dependencies. This architectural isolation enables wallet layer evolution while maintaining stable agent interfaces.

MCP Server layer: Exposes standardized Model Context Protocol tools to AI agents. Handles OAuth authentication, request orchestration, and tool discovery. Maintains protocol compliance independent of wallet implementation choices. Maps agent intents to wallet operations through well-defined interfaces.

Wallet layer: Manages cryptographic operations, key custody, and transaction signing. Implements payment authorization, token transfers, Smart Account deployment, and blockchain interaction. This layer can transition from custodial to self-custody models without MCP server changes.

Blockchain integration layer: Abstracts RPC connectivity, transaction submission, and state queries. Supports multiple chains through unified interfaces. Handles bundler communication for ERC-4337 operations. Provides transaction status verification across heterogeneous networks.

Application layer handlers: Orchestrate multi-step operations like swap execution or yield deposits. Coordinate security validation, balance checks, transaction construction, signing requests, and status verification. Implement business logic without direct blockchain access.

CLI connectivity layer: Provides command-line integration through Device Authorization Grant (RFC 8628). AI agentic applications like OpenClaw connect to the wallet via OAuth Proxy supporting dynamic client registration. CLI clients register once, obtain device codes, present user verification URLs, and poll for tokens. This device flow enables headless environments and terminal-based workflows without browser redirect dependencies. The same OAuth infrastructure supports both web-based assistants and CLI tools through appropriate grant type selection.

The Agent Wallet CLI demonstrates this architecture in practice. Users manage agent wallets, execute transactions, and authorize payments directly from terminal environments. The CLI serves both as a standalone wallet management tool and as reference implementation for integrating terminal-based agentic applications. OpenClaw and similar autonomous agents follow the same authentication patterns, enabling seamless wallet connectivity across diverse execution environments.

This separation allows development parallelization. MCP protocol implementation proceeds independently of wallet architecture research. Wallet signing mechanisms evolve without breaking protocol compliance. Blockchain integrations expand without impacting application handlers. CLI connectivity extends to new agentic platforms without modifying core wallet logic.

‍

Resilient State Verification

Autonomous operations must handle partial failures gracefully. Blockchain transactions can succeed, fail, or remain pending after submission. Network issues may prevent immediate confirmation. The wallet architecture verifies final transaction status through multiple validation paths.

Transaction status hierarchy: Operations progress through submitted, pending, confirmed, and reverted states. Exceptions during submission trigger status verification before reporting failure. The implementation distinguishes network timeouts from actual transaction failures.

Bundler receipt verification: ERC-4337 user operations query eth_getUserOperationReceipt when submission exceptions occur. A receipt with success=true indicates onchain confirmation despite the exception. A receipt with success=false indicates reversion with reason. No receipt indicates pending bundler mempool status.

RPC confirmation: Standard transactions query eth_getTransactionReceipt for status. A receipt with status=1 confirms success. A receipt with status=0 indicates reversion. Missing receipts indicate pending mempool status. Solana operations query getTransaction with commitment levels.

Explorer URL construction: All transaction results include blockchain explorer URLs for manual verification. The URLs use chain-specific explorers (Etherscan, BlockScout, Arbiscan, Solscan) with proper transaction hash or user operation hash parameters.

Error recovery patterns: Network timeouts extend retry windows rather than immediately failing. Status verification prevents duplicate submissions. Graceful degradation returns partial results rather than complete failures. Idempotency keys prevent duplicate operations across retries.

‍

Security Through Defense in Depth

The wallet layers security controls across multiple enforcement points. No single mechanism provides complete protection. The combination creates robust defenses against various attack vectors.

Authentication: OAuth 2.0 with Microsoft Entra ID provides user authentication. OBO flow validates agent requests against user tokens. Session expiration and token refresh enforce temporal access boundaries.

Key isolation: Hardware security enclaves prevent key extraction. Signing operations occur in isolated environments. Keys never appear in application memory or logs.

Policy validation: Application layer validates operations against spending limits, token restrictions, and recipient allowlists before signing. Blacklist checking prevents transfers to known malicious addresses. Fail-closed behavior blocks operations when validation services are unavailable.

Audit logging: All operations log with correlation IDs for tracking. KMS signing operations record caller identity and operation parameters. DynamoDB stores account registrations and deployment state.

Circuit breakers: RPC clients implement circuit breaker patterns preventing cascade failures. Bundler clients timeout and retry with exponential backoff. Health checks detect component degradation.

Input validation: All MCP tool parameters validate through JSON schemas. Address formats validate through checksum verification. Amount parsing prevents overflow and negative value attacks.

‍

Implementation Decisions

The Finance District Agent Wallet embodies these principles through specific technical choices that balance pragmatism with architectural rigor.

Open implementation: The complete codebase is available at github.com/1stdigital/fd-x402-wallet. Documentation includes wallet design specifications, system architecture, integration guides, and test implementation details. All contracts, services, and MCP tools are auditable.

Standard compliance: The implementation follows EIP-3009 for payment authorization, EIP-4337 for account abstraction, EIP-7579 for modular account interfaces, and EIP-1271 for signature validation. X-402 Payment Required protocol integration enables agent payment flows. MCP v1.0 protocol compliance ensures standard AI assistant integration. RFC 8628 Device Authorization Grant enables CLI connectivity for terminal-based agentic applications like OpenClaw.

Multi-platform integration: Web-based AI assistants connect via standard OAuth authorization code flow with PKCE. CLI applications and headless environments use Device Authorization Grant with dynamic client registration. Both paths authenticate through the same OAuth Proxy infrastructure supporting Microsoft Entra ID integration. The Agent Wallet CLI provides terminal-based wallet management, demonstrating the device flow architecture that autonomous agents like OpenClaw leverage for headless operation.

Multi-chain support: Base, Arbitrum, BSC, Ethereum, and Solana networks are supported through unified interfaces. Chain-specific RPC clients abstract network differences. CREATE2 deployment provides deterministic addresses across EVM chains. Native Solana integration handles SPL tokens and SOL transfers.

Testing rigor: The implementation includes 40+ tests covering salt generation, address prediction, deployment flows, and user operation construction. Integration tests validate service orchestration. Component tests verify nonce encoding, signature formats, and ABI compliance.

‍

Building Autonomous Financial Infrastructure

The design principles guiding the Finance District Agent Wallet emerge from the specific technical constraints of AI agents executing financial operations through the X-402 protocol. These are not theoretical ideals but concrete architectural decisions addressing real implementation challenges.

Our architectural analysis challenges prevailing assumptions about agent wallet requirements. The industry narrative suggests agents need sophisticated smart contract wallets with programmable policies. We believe the operational reality is simpler. We anticipate over 90% of agent operations will require nothing more than baseline EOA signing. Token transfers, payment authorizations, protocol interactions, swaps—these operations work efficiently with standard private key cryptography. The complexity and overhead of account abstraction solves problems that most agents never encounter.

The three-level wallet architecture reflects this distribution. Level 1 EOA wallets satisfy X-402's signature requirements and handle the overwhelming majority of operations efficiently and cheaply. Level 2 Smart Accounts exist for the minority of scenarios requiring specific account abstraction features—batch operations, gas sponsorship, session key constraints. Level 3 Delegated Wallets serve the edge case of institutional governance and multi-party approvals. Self-custodial key management in hardware enclaves preserves user sovereignty while enabling agent operations. Gas-free EIP-3009 execution eliminates operational complexity for agents. Deterministic CREATE2 deployment provides consistent multi-chain identity. Modular separation enables independent evolution of protocol and wallet layers. Session-based authorization constrains agent permissions without restricting capabilities. Resilient verification ensures reliable transaction status across heterogeneous networks. Defense-in-depth security layers protection at multiple enforcement points.

This architecture optimizes for the common case—simple, reliable EOA execution—while accommodating the uncommon cases that genuinely require additional capabilities. The market will likely maintain this distribution as agent adoption scales.

The design accommodates autonomous operation without sacrificing user sovereignty. The architecture maintains backward compatibility while enabling progressive enhancement from simple EOA operations through programmable Smart Accounts to sophisticated Delegated Wallet controls.

The critical insight: most agents never need to progress beyond Level 1. The EOA wallet is not a stepping stone to "real" smart contract wallets. For 90%+ of agents, it is the final and optimal architecture.


Access Agent Wallet: https://apps.fd.xyz/
‍

To continue the conversation, join our Discord community, follow us on X, or explore our documentation to learn more.

‍