AI agent wallets are not just regular wallets with a friendlier API. They are a new class of account with unusual constraints: the "user" is non-human, decisions happen in milliseconds, spend limits must be machine-enforceable, and identity has to be something other agents and counterparties can verify without trusting a central registrar. Solving this cleanly takes two Ethereum standards working together — ERC-4337 for account abstraction and ERC-8004 for trustless agent identity — plus intent-based settlement on top to make the wallet genuinely useful across chains.

This article walks through the full architecture for a production-grade AI agent wallet. It covers the smart account, session keys, the ERC-8004 identity registry, ERC-7683 for cross-chain intents, and Eco Routes as the settlement layer that moves stablecoins between the 15 chains where agents actually need to operate. The goal is to give you a concrete mental model you can build against, not a survey of every competing standard.

A human's wallet has one job: keep a private key safe and sign when its owner approves. An AI agent's wallet has at least five jobs, often simultaneously.

No single EIP handles all five. The working architecture stacks several. Below is how the pieces fit.

ERC-4337 is the account abstraction standard that lets smart contracts behave like user accounts without requiring changes to the Ethereum protocol. The EIP-4337 specification defines a separate "UserOperation" mempool and a bundler that packages these pseudo-transactions into real ones. For agent wallets, ERC-4337 is load-bearing.

A 4337 smart account gives the agent three things a regular EOA cannot:

The two most mature 4337 implementations are Stackup's bundler and Biconomy's account abstraction stack. Both expose SDKs that an agent runtime can use to deploy a smart account, submit UserOperations, and manage paymasters. Coinbase's CDP Wallet API also provisions 4337-compatible accounts under the hood, which is part of why AgentKit-spawned wallets are a clean fit for this architecture.

A smart account is a shell. The question is what keys can authorize what operations. For agents, the answer is almost never "one root key does everything." Instead, the account installs session keys — scoped, time-bounded, spend-limited signers that the agent's short-lived processes actually use.

A session key might say: "This key can spend up to 100 USDC per day, only to addresses in this allowlist, only until next Friday, and only on Base." The account enforces those constraints in its validation logic. The agent process holds the session key; the root key (which could be a human, an MPC cluster, or another smart contract) stays cold and only signs new sessions.

The practical outcome is that the blast radius of a compromised agent process is tightly bounded. If an attacker exfiltrates the session key, they can spend at most whatever the session allowed before it expires. They cannot drain the account, cannot extend the session, and cannot install new sessions without the root key. Session keys are the single most important security primitive for agent wallets, and they are only possible because ERC-4337 lets account logic be arbitrary Solidity rather than baked-in EOA rules.

This pattern is closely related to what programmable stablecoin treasury automation requires at execution time — the same session-scoping logic that bounds agent authority also bounds automated treasury workflows.

A smart account tells you what an address can do. It doesn't tell you who the agent is or whether it's the same agent you talked to yesterday. That's an identity problem, and it's what ERC-8004 addresses.

ERC-8004, draft-standardized and described in the EIP-8004 draft, defines a minimal onchain registry for agent identity. An agent (or its operator) registers with the registry, providing a metadata pointer (often IPFS) that describes the agent's capabilities, operator, and any attestations. The agent's smart account is linked to this registry entry. Other parties can query the registry to verify: "this address is claimed by agent X, operated by entity Y, with these capabilities attested by this issuer."

Two design choices make ERC-8004 useful rather than ceremonial:

The practical value shows up in commerce. When an x402 endpoint receives a payment, it can check the paying address against ERC-8004 and decide whether to extend credit, apply a loyalty discount, or rate-limit. When a DeFi protocol sees an agent depositing, it can verify the agent passed a KYB check without requiring the human operator to resubmit KYC. Identity becomes a lookup, not a workflow.

With a smart account, session keys, and identity, the agent has a wallet that works on one chain. It still needs to operate across many. That's where ERC-7683 comes in. The EIP-7683 specification standardizes the format of cross-chain intents so that any wallet can express "I want outcome X on chain Y, paid from balance on chain Z" in a way any compatible solver network can fulfill.

ERC-7683 doesn't build the solver network itself. It builds the interop layer so an agent wallet doesn't need to know anything about the specific bridging or settlement infrastructure. The wallet creates an intent, signs it (using its session key, subject to the account's limits), and submits it. A solver fulfills it. The wallet sees an atomic outcome.

For agents, this matters more than for humans. A human can tolerate bridging UX — multi-step flows, waiting periods, occasional manual recovery. An agent cannot. Every step where a bridge might fail is a step where the agent has to reason about compensating actions, which it mostly can't do reliably. Intents collapse those multi-step flows into single atomic outcomes, making them something an agent can handle without baroque error-handling logic.

ERC-7683 is a specification. It needs a network of solvers to fulfill the intents. For stablecoin-denominated flows — which is what agents mostly care about — Eco Routes is the settlement layer optimized for that specific asset class.

Routes handles the 15 chains where real stablecoin liquidity lives: Ethereum, Optimism, Base, Arbitrum, HyperEVM, Plasma, Polygon, Ronin, Unichain, Ink, Celo, Solana, Sonic, BSC, and Worldchain. It supports USDC, USDT, USDC.e, oUSDT, USDT0, USDbC, and USDG. Solvers compete to fill each intent, which keeps pricing tight, and settlement is atomic — either the debit and credit both happen, or neither does.

For an agent wallet, Routes is the bottom of the stack. The smart account provides the authority structure. Session keys provide scoped spend. ERC-8004 provides identity. ERC-7683 provides the intent format. Routes provides the actual cross-chain movement. The agent's outbound transaction — "pay 10 USDC on Arbitrum to this address" — is a single signed intent, executed end-to-end without the agent ever touching a bridge contract.

This is why the wallet architecture matters. Without it, agents are trapped on whichever chain they started on. With it, agents operate chain-agnostically, which is the only way agentic commerce scales past demos. The same primitive powers intent settlement for other use cases like treasury rebalancing and cross-chain OTC.

Laid out top to bottom, the agent wallet stack is:

Each layer does one thing well and defers everything else to the layer below. That's how you build infrastructure that survives specifications moving underneath it. If ERC-7683 evolves, the agent runtime doesn't change — only the intent construction adapter. If the solver network shifts, the intent format doesn't change. If the LLM changes, the smart account's validation rules don't.

A concrete implementation starts at the smart account. Deploy a 4337-compatible account using Stackup's or Biconomy's SDK. Configure it to accept session keys validated by your chosen scheme (simple ECDSA scoped by call selector and spend limit is a reasonable default). Register the account with an ERC-8004 instance and attach whatever attestations your deployment requires — at minimum a capability attestation describing what the agent is authorized to do.

The agent runtime, on startup, requests a session key from the root authority (which could be a secure enclave, an MPC cluster, or a human-approved ceremony). The session key is installed on the smart account with a 24-hour expiration and a per-transaction spend cap. For cross-chain operations, the agent constructs an ERC-7683 intent describing the desired outcome and submits it to Eco Routes. The stablecoin marketplace settlement flow is the same pattern, generalized — intents express outcomes, solvers fulfill them, wallets see atomic results.

Monitoring and reconciliation round out the stack. Webhook notifications on intent lifecycle let the agent know when settlement is final. Attestation queries let counterparties verify the agent's identity without phoning home. Spend analytics against the session-key audit log let operators see exactly what the agent did — which matters both for compliance and for debugging.

ERC-8004 is a draft. Expect the metadata schema to evolve as ecosystem patterns settle. The implication for implementation is to keep identity resolution behind an abstraction in the agent runtime so that spec changes don't ripple through application code.

ERC-7683 is also early. Not every solver network supports every variant of the intent format, and gasless signing extensions are still landing. The practical mitigation is to use a routing layer that tracks spec changes and abstracts them from the wallet, rather than building against the spec directly.

Session-key standards are fragmenting across 4337 implementations. Biconomy, Stackup, Safe, and others each have slightly different session-key patterns. Pick one and commit — the cost of multi-backend session abstraction is not worth it for most teams right now.

An AI agent wallet is an onchain account designed for autonomous software agents rather than humans. It combines a smart account (ERC-4337) for flexible authorization, session keys for scoped spend, an identity registry entry (ERC-8004) for verifiable provenance, and an intent interface (ERC-7683) for cross-chain operations. The result is a wallet an agent can operate at machine speed without human approval on each transaction.

EOAs have no concept of spend limits, session keys, or gas sponsorship. Every transaction is signed by the same root key with no onchain-enforceable constraints. For human users, that's fine — they review each transaction. For agents, it's a security disaster: a compromised agent process can drain the account. Smart accounts solve this by putting authorization logic onchain.

ENS maps names to addresses. ERC-8004 maps agent identities to capabilities and attestations, designed for programmatic verification rather than human-readable naming. An agent's ERC-8004 entry might say "this address is operated by X, passed KYB with Y, and can be trusted for Z-type transactions up to $N." That's a richer claim than "this address is called alice.eth."

No. A reasonable minimum is ERC-4337 plus session keys plus an intent-based routing layer for cross-chain movement. ERC-8004 becomes important once counterparties need to verify the agent's identity, which for most agent deployments happens later in the lifecycle. Start with the authorization model and cross-chain settlement; add identity as commerce use cases require it.

With Eco Routes as the settlement layer, an agent wallet can operate across all 15 supported chains — Ethereum, Optimism, Base, Arbitrum, HyperEVM, Plasma, Polygon, Ronin, Unichain, Ink, Celo, Solana, Sonic, BSC, and Worldchain — using standard stablecoins and intent-based routing without requiring the agent to hold native gas tokens on each chain.