Skip to main content

Agent Wallets: How AI Agents Spend Money

Agent wallets hold funds and sign transactions for AI agents under bounded authority. Compare custodial, smart-contract, MPC, card, and vault designs.

Written by Eco

An agent wallet is any wallet that holds funds and signs transactions on behalf of an autonomous AI agent under bounded authority. It differs from a human wallet in four ways. Identity is delegated, not personal: the wallet proves that an agent is acting for a specific user under specific permissions. Spend is policy-constrained, not signature-constrained: rules cap amount, merchant, time, and chain rather than relying on a human reading the prompt. Keys are scoped, not master: short-lived session keys do the actual signing while the master sits idle. And the wallet is programmable, not just held: it composes with checkout protocols (ACP, AP2, x402) and identity layers (Visa TAP, Skyfire KYA) at the wallet boundary instead of inside the agent code. This piece classifies the five agent-wallet architectures shipping in production in 2026 (custodial, smart-contract, MPC, card-issuance, vault), names the implementations, compares them across six attributes, and draws the trade-offs every team building agent payment flows has to make.

What Is an Agent Wallet?

An agent wallet is a programmatic financial endpoint that holds funds, attests identity, and signs transactions on behalf of an autonomous AI agent. It runs four jobs in order on every transaction: hold funds, prove identity, authorize within bounded limits, and settle via a chosen rail. Custody, signing surface, and policy enforcement vary by category.

An agent wallet is the financial endpoint that an autonomous agent uses to receive value, hold value, and disburse value within rules its operator can audit. The agent does not press a "send" button in a UI; it calls a wallet API, signs a payload programmatically, or hands a tokenized credential to a merchant. The wallet is the trust boundary between the agent's reasoning loop and the actual money.

The concept is older than the agentic-commerce wave. Custodial trading bots have used API-keyed exchange wallets for a decade. Programmatic card issuers like Lithic and Stripe Issuing have minted virtual cards under code control since 2019. What changed in 2024-2026 is the combination of three forces: large language models that can plan and act multi-step, payment protocols designed for non-human buyers (Coinbase x402, Stripe Link Agent Wallet, OpenAI Agentic Commerce Protocol, Google Agent Payments Protocol), and on-chain primitives (EIP-4337, EIP-7702) that let a smart account enforce arbitrary policy logic. Together they turn "wallet" from a passive store into an authorization gateway tuned for code-driven spend.

Two facts shape the category. First, dollars matter. The dominant settlement currency for onchain agent payments is a dollar stablecoin: USDC ($77.3B supply, per DeFiLlama Apr 29, 2026) and USDT ($189.5B supply) account for roughly 84% of the $318B total stablecoin float. Second, scale matters. The Coinbase-led x402 protocol has crossed 165 million transactions and 69,000 active agents at an average value under 31 cents per call (per Cryptonews' April 2026 reporting on Coinbase's published numbers), which means agent wallets at production scale must clear thousands of low-value events per minute, not handful-per-day human flows. Both forces push wallet design toward programmable, low-cost, multi-chain settlement.

How Do Agent Wallets Work?

Agent wallets execute a four-step pipeline per transaction: hold the balance, attest the agent's identity, check the proposed payment against bounded authority, and settle through a connected rail. Different wallet categories implement each step differently, but every production agent wallet runs all four checks before any value moves on behalf of the agent.

An agent wallet has four jobs. They run in order on every transaction.

Hold funds. The wallet maintains a balance the agent can draw from. Custody varies by category: a custodial wallet keeps the balance with a third party; a smart-contract wallet keeps it on-chain at an address only the smart account controls; a card-issuance wallet keeps no balance at all and pulls from a funding account at swipe time. The hold mechanism determines who is liable if a key is compromised.

Prove identity. Before signing, the wallet attests that this agent is authorized for this transaction. Two patterns dominate. Identity-as-token: Skyfire issues a signed JWT under its Know-Your-Agent (KYA) token spec naming the operator, the model, and the capability scope; merchants verify the JWT signature against Skyfire's registry. Identity-as-header: Visa TAP signs the agent identity into HTTP request headers using public-key cryptography per the specification on GitHub; merchants fetch Visa's directory key and verify. Both patterns sit at the wallet edge, not inside the agent.

Authorize within limits. The wallet checks that the proposed payment fits the bounded authority granted to the agent. For smart-contract wallets, the check is a policy contract executed during signature validation. For custodial wallets, the check is server-side rule evaluation. For card-issuance wallets, the check is the card-network's authorization step plus issuer-side velocity controls (merchant-category code, daily cap, single-transaction cap). The Mastercard Agent Pay framework wraps this step in network tokens scoped per session and per agent.

Settle via rails. Finally, the wallet moves money. Onchain settlement uses stablecoin transfer (`transfer`, `transferWithAuthorization` per EIP-3009, or x402's HTTP 402 flow). Card settlement uses the issuer's card-network connection (Visa, Mastercard, Amex). Bank-rail settlement uses ACH, RTP, or wire through the wallet provider's banking partner. Each rail has its own latency, cost, and dispute regime. Agent wallets that want to support multiple rails compose them at the same wallet boundary.

Across the five categories below, every wallet does these four jobs. They differ in where the keys live, what kind of policy they enforce, and which settlement rails they connect to.

The Five Categories of Agent Wallets

Agent wallets fall into five production categories: custodial, smart-contract, MPC, card-issuance, and vault-style. Each category names a different home for keys, funds, and policy enforcement. Most production agent stacks combine two or three categories, routing each transaction to the wallet whose rail matches the counterparty.

The agent-wallet design space sorts into five categories. Each category names a real production system. Most agent stacks combine two or three (for example, a smart-contract wallet for stablecoin settlement plus a card-issuance wallet for off-chain merchants).

Custodial agent wallets

A custodial agent wallet stores funds and private keys with a third party. The agent calls an API; the provider signs. This is the simplest category to integrate and the fastest to ship.

Concrete examples. Stripe Link Agent Wallet exposes an agent-authorized payment flow on top of Stripe's existing Link infrastructure: the user enrolls payment methods once, then agents draw against them under per-session limits. OpenAI's Agentic Commerce Protocol issues Shared Payment Tokens, scoped ephemeral tokens the buyer's payment provider mints per merchant per amount; the agent passes the token to the merchant, who runs it through normal processor rails (typically Stripe). Skyfire operates a custodial wallet behind its KYAPay product, layering identity attestation onto a custodial settlement flow. Each one removes the operational burden of key management at the cost of giving the provider the ability to freeze funds.

The trade-off is sovereignty. A custodial wallet is the right answer when an agent operator wants payments to "just work" and is willing to accept counterparty risk on the wallet provider, plus dependence on that provider's fraud rules and uptime. It is the wrong answer when the agent has to settle into self-custody (a treasury wallet, a smart contract, an off-platform recipient) on a rail the custodian does not support.

Smart-contract agent wallets

A smart-contract agent wallet is a programmable on-chain account. The account is itself a contract, with executable logic that decides what signatures count as valid, what policies apply, and what fees the wallet pays in. Two Ethereum standards define the category.

EIP-4337 (Account Abstraction) defines the smart-account interface, the `EntryPoint` contract, the `UserOperation` mempool, the bundler role, and the paymaster role. Bundlers package user operations and call `EntryPoint.handleOps()`; paymasters can sponsor gas so an agent never has to hold ETH. EIP-4337 deployed in March 2023 with no consensus changes. EIP-7702, activated on Ethereum mainnet on May 7, 2025 as part of the Pectra hardfork, adds a transaction type that lets a regular externally-owned account (EOA) temporarily adopt smart-contract code via a signed authorization tuple. EIP-7702 means an agent's existing EOA can act like a smart account for a single session without redeploying or migrating funds.

Concrete examples. Crossmint smart wallets use a 4337-plus-7702 hybrid across 40+ chains, including EVM networks, Solana, Stellar, and Sui; ZeroDev's kernel SDK and Privy's embedded wallets follow similar patterns. Circle Wallets ship a programmable smart-account interface with built-in USDC support, Gas Station for paymaster sponsorship, and CCTP V2 for cross-chain USDC movement. The shared design pattern is session keys: the master signer grants a short-lived secondary signer that can only spend up to a set amount, only to specific addresses, only under specific function calls, and only until expiry. ERC-7715 standardizes this permission model so any dApp can request the same scoped credential the agent's wallet enforces.

The trade-off is integration depth. A smart-contract wallet gives an operator on-chain enforcement of arbitrary spend policy, sponsored gas, and multi-chain operability. It demands real engineering work: writing the policy contract, choosing a bundler, paying paymaster fees, handling chain abstraction. Teams shipping a quick agent prototype usually pick custodial; teams shipping production payment infrastructure usually end up here.

MPC agent wallets

A multi-party-computation (MPC) agent wallet splits the signing key into shares so that no single party ever holds the full key. Any threshold of parties (`t-of-n`) can co-sign a transaction; below threshold, no signature is possible. The cryptographic primitive predates account abstraction and works on any chain whose signature is plain ECDSA or EdDSA.

Concrete examples. Coinbase CDP Server Wallets v2, which reached general availability on July 24, 2025, splits the key between Coinbase and the operator and exposes a server-side signing API; the same platform's AgentKit bundles wallet, identity, and onchain action tooling for agentic AI. Fireblocks Non-Custodial Wallets-as-a-Service offers an institutional MPC stack with reference architectures for AI-agent deployments. ZenGo, Web3Auth, and Privy expose consumer-grade MPC.

The trade-off is policy expressiveness. MPC removes the single-point-of-key-failure of a custodial wallet without requiring on-chain code. Cross-chain operability is essentially free since the underlying primitive is just signing; the same wallet abstraction works on Ethereum, Solana, Polygon, and Tron. What MPC does not give a team is on-chain policy enforcement: the rules live off-chain in the operator's signing service. For agent operators that want a single multi-chain wallet under cryptographic shared control without writing smart contracts, MPC is the most direct path.

Card-issuance agent wallets

A card-issuance agent wallet is not really a "wallet" in the on-chain sense. It is an issuer-side construct that mints a programmable virtual card for the agent to spend through. The card flows over Visa or Mastercard rails into the merchant's normal processor, but every parameter (merchant restriction, amount cap, expiry, single-use) is set in code by the agent's operator at the moment of issuance.

Concrete examples. Lithic exposes a card-issuing API that lets developers mint cards programmatically with merchant-category-code allowlists and per-transaction limits. Stripe Issuing offers a similar surface and powers the agent payment stacks at Brex, Ramp, and Mercury. Mastercard's Agentic Tokens, the network-token primitive behind Mastercard Agent Pay, are functionally a card-network-native version of the same idea: a token vault tied to a specific Agent Pay session, with per-session limits and per-agent identity baked into the authorization record. Mastercard launched Agent Pay on April 29, 2025; Citi and US Bank cardholders gained first access; full US rollout came in November 2025.

The trade-off is rail dependence. Card issuance gets an agent into the entire universe of card-accepting merchants without any change to the merchant. The cost is interchange (typically 1.5-3.5% per transaction), chargeback exposure, and a settlement window measured in days, not seconds. Card-issuance wallets compose well with custodial wallets (the funding account behind the card) but do not connect to onchain stablecoin rails; for agents that need both, the operator runs a card-issuance wallet alongside a smart-contract or MPC wallet.

Vault-style agent wallets

A vault-style agent wallet stores the credential, not the funds. The agent never touches the raw card number, bank credentials, or cryptographic key; it asks the vault to act on its behalf, and the vault enforces policy before performing the action. The pattern is borrowed from PCI tokenization and adapted for the agent context.

Concrete examples. Basis Theory operates a cloud-native PCI tokenization vault that takes a raw payment credential, issues an opaque token, and exposes APIs that perform reveal, charge, and forward operations under policy. Basis Theory raised a $33 million Series B in October 2025 led by Costanoa Ventures and co-founded the Agentic Commerce Consortium with Lithic, Crossmint, Skyfire, Rye, Channel3, Catalog, New Generation, and Henry Labs. Nekuda built a Secure Agent Wallet plus a Mandates SDK that lets a merchant verify a user's pre-authorization for an agent's purchase via Nekuda's MCP server; the agent presents a signed mandate, the merchant queries the vault, and the funds release. Nekuda raised a $5 million seed in May 2025 from Madrona, with Amex Ventures and Visa Ventures participating.

The trade-off is dependency. Vault-style wallets get an operator out of the PCI compliance perimeter and out of the cryptographic key-management business. They concentrate trust in the vault provider's policy engine, uptime, and exit posture. Vault designs are most common at teams that already have card credentials in hand (subscription companies, B2B SaaS) or that want a clean separation between identity attestation and the actual signing surface.

Comparing the Five Categories

The five categories differ across six attributes: where custody lives, where signing happens, what programmability is available, how identity attestation works, what settlement rails are reachable, and how gas or fees are paid. The matrix below summarizes the trade space, with one representative implementation per row, so a builder can pick the category that matches the agent's spend pattern.

The five categories trade six attributes: where custody lives, where signing happens, what programmability is available, how identity attestation works, what settlement rails are reachable, and how gas or fees are handled. The matrix below summarizes each category, with a representative implementation per row.

Category

Custody

Signing

Programmability

Identity / KYA

Settlement

Gas / fees

Custodial (Skyfire, Stripe Link Agent, OpenAI ACP SPT)

Provider holds keys

API call

Off-chain server rules

Provider attestation; KYAPay JWT

Stablecoin or card via processor

Provider sponsored

Smart-contract (Crossmint, Circle Wallets, ZeroDev)

Smart account on-chain

EOA + session keys

On-chain policy contract

DIY at the contract level

Stablecoin (USDC, USDT)

Paymaster sponsored

MPC (Coinbase CDP, Fireblocks NCW)

Threshold-shared

`t-of-n` signers

Off-chain rules

Operator-managed

Stablecoin, multi-chain

Operator pays gas

Card-issuance (Lithic, Stripe Issuing, Mastercard Agentic Tokens)

Issuer + funding account

Card auth (3DS)

Per-card MCC, cap, expiry

Issuer KYC

Card networks (Visa, Mastercard)

Interchange (1.5-3.5%)

Vault (Basis Theory, Nekuda)

Vault holds credential

Vault acts on behalf

Vault policy engine

Provider-attested mandates

Whatever the credential supports

Vault fee per call

A practical pattern: agents that need to spend across both onchain and off-chain merchants combine a smart-contract wallet for stablecoin settlement with a card-issuance wallet for card-accepting merchants and route per-transaction. Agents that only ever pay other agents (machine-to-machine API calls, compute, data) settle exclusively in a smart-contract or MPC wallet. Agents that act as buyers in chat surfaces (ChatGPT, Perplexity Comet, Amazon Rufus) typically use a custodial or vault-style wallet because the platform already holds the user's payment instrument. The choice is rarely "pick one"; it is "compose two."

Trade-offs: Identity, Custody, and Spend Control

Every agent-wallet decision trades three axes against each other: how the agent attests its identity to merchants, who controls custody and recovery, and how granularly spend is bounded per transaction, per session, and per allowlist. A fourth axis, the user mandate, sits between the agent and the wallet on consumer flows.

Three trade-off axes recur across every agent-wallet decision.

Identity attestation. Merchants will increasingly refuse agent payments without a verifiable agent identity. The two production patterns are the Skyfire KYA token (a signed JWT in the request body) and Visa TAP (a cryptographically signed HTTP header). KYA suits onchain agent-to-agent flows where both sides understand JWT verification; TAP suits card-side merchant integrations where Cloudflare and Visa-network infrastructure handles signature checking before the request even reaches the merchant's app server. Some agent wallet stacks support both. None should support neither: a wallet that signs spend without attesting agent identity exposes the merchant to scraper traffic and the operator to chargebacks.

Custody and recovery. Custodial wallets give the provider control of recovery; smart-contract wallets give the operator control through guardian sets, social recovery, or 7702 delegation; MPC wallets combine the two by sharing the key. The right answer depends on what failure mode the operator is most worried about. A consumer-facing agent loses users to forgotten-key UX; a treasury-facing agent loses dollars to a single point of compromise. Most production teams pick a default custody mode for new wallets and offer an upgrade path (custodial → MPC → smart-contract) as the user gains experience.

Spend control granularity.Spend control comes in three flavors. Per-transaction caps stop a single bad call from draining the wallet. Per-session caps limit total exposure inside one agent run. Allowlist controls (merchant, recipient, function selector, MCC) restrict where the agent can spend at all. Smart-contract wallets enforce all three on-chain via the policy contract; MPC and custodial wallets enforce them in the off-chain signing service; card-issuance wallets push them into the network token vault. Layered enforcement is the norm: an agent's smart-contract wallet may have a per-transaction cap, while its session key has a tighter per-call cap, while the operator's signing service has a circuit breaker on aggregate spend in the last hour. Each layer catches a different failure mode.

A fourth axis, less often discussed, is the mandate: a signed user authorization that sits between the agent and the wallet. Google's Agent Payments Protocol formalizes this layer with cryptographic mandates the user signs (via wallet or AP2-compatible identity provider), the agent presents at checkout, and the merchant stores as a non-repudiable receipt. Nekuda Mandates implements the same idea for non-AP2 environments. Mandates are not strictly part of the wallet but they are the artifact a court or chargeback investigator would need to evaluate "did the user authorize this purchase?" — which is why agent wallets that target consumer payments are now expected to support at least one mandate format.

How to Choose an Agent Wallet

Wallet selection falls out of three questions in order: what the agent buys (stablecoin counterparties versus card-accepting human merchants), who owns the user relationship (the operator or an upstream surface like ChatGPT), and what regulatory perimeter the operator wants to live inside. A fourth question covers which chain the funds actually settle on.

The right wallet category falls out of three questions, in order.

First, what does the agent buy? If it pays other agents in stablecoins for API calls or compute, default to a smart-contract or MPC wallet on the chain those services accept (typically Base, Solana, Arbitrum, or Polygon — on Base alone, gas costs are pennies even at 165M-tx scale). If it buys from card-accepting human merchants, default to a card-issuance or vault wallet. If it buys both, plan to run two wallets and route per merchant.

Second, who holds the user relationship? If the operator is the user-facing brand (a Brex spend account, a Stripe-built checkout, a custom enterprise agent), custodial or vault patterns shorten time-to-launch and let the brand own the support relationship. If the operator is downstream of someone else's user (an agent embedded in ChatGPT or Perplexity), the wallet is usually whatever the surface chose — ACP shared payment tokens or a Link Agent wallet — and the operator's job is to integrate cleanly.

Third, what regulatory perimeter does the operator want to live inside? Card issuance brings the operator into PCI scope unless a vault holds the credential; MPC and smart-contract wallets sit outside PCI but inside whatever crypto-asset rules apply in the operator's jurisdiction; custodial wallets push the regulatory burden onto the provider. Most production teams pick the wallet that minimizes their own compliance perimeter and live with the integration constraints that follow.

The fourth question, often skipped by teams new to agentic commerce, is what chain the funds actually settle on. An agent wallet that lives on Base while the recipient holds USDC on Solana needs cross-chain orchestration before the payment completes. The wallet does not solve that problem on its own; it sits at the top of a settlement stack that has to handle solver selection, liquidity sourcing, and finality. Cross-chain stablecoin tooling — covered in Eco's stablecoin swap aggregator survey and stablecoin developer-tooling guide — is what closes the loop between the wallet and the recipient's chosen rail.

Sources and methodology. Wallet product details verified against issuer documentation (Coinbase CDP, Stripe Link, Skyfire, Nekuda, Crossmint, Circle) linked inline. Funding figures from press releases. EIP specifications from eips.ethereum.org. Stablecoin supplies pulled from DeFiLlama on April 30, 2026. Figures refresh quarterly.

Eco's Role for Agent Wallets

Eco is a stablecoin execution network that sits beneath the agent wallet and handles cross-chain settlement once the wallet authorizes a payment. The wallet decides who can spend and how much; Eco moves the dollars from the agent's chain to the counterparty's preferred chain across 15 supported networks via a single intent-style API.

Agent wallets sit above payment rails, not on them. Once a wallet authorizes a transfer, the dollars still have to move from one chain to another to land in a counterparty's preferred rail. Eco is the stablecoin execution network that handles that movement across 15 chains, with Hyperlane and CCTP as the live transport rails behind a single intent-style API. An agent that holds USDC on Base in a Crossmint smart-contract wallet can pay a counterparty whose treasury sits on Solana, Arbitrum, or Tron without writing the bridging logic itself. The wallet decides who can spend and how much; Eco handles where the dollars actually settle. For teams building agent payment flows, that division of labor is the difference between integrating one settlement surface and stitching together a bridge, a swap aggregator, and a routing layer per chain. Eco does not replace the wallet category — it composes underneath whichever wallet the operator picked.

Did this answer your question?