What is an agent wallet? A glossary of agent spend terms for Base and Solana
GetAgentCap team · published 9/26/2026
An agent wallet is a blockchain address whose transactions are started by software, not by a person clicking approve. That one-line definition hides a dozen terms (facilitator, transferWithAuthorization, associated token account, finality) that decide whether you can explain your agent's spend later. This is the glossary the GetAgentCap team wishes existed when we started, with each term defined the way it behaves on-chain.
What is an agent wallet?
An agent wallet is a blockchain account that an autonomous program controls and uses to pay for things without a human approving each transaction. On Base it is usually an EVM address, either a plain externally owned account (EOA) holding a private key, or a smart contract account. On Solana it is an ed25519 keypair plus the token accounts that hold its balances.
What sets an agent wallet apart is not the cryptography, which is the same as any wallet. It is the spending pattern: many small payments, often under $1, made around the clock, to counterparties that the program picked at runtime. A single agent making paid API calls can produce hundreds of USDC transfers a day, each worth a few cents.
In practice most agent wallets hold USDC rather than the chain's native token, because the services they pay quote prices in dollars. They still need a small native balance (ETH on Base, SOL on Solana) for gas, unless a third party sponsors the fees. That third party is the next term on this list.
What is an x402 facilitator?
x402 is a payment protocol built on the HTTP 402 Payment Required status code. A server answers an unpaid request with 402 and a description of the price, the asset, the network and the recipient address. The client signs a payment payload and retries the request with it attached in a header.
A facilitator is the service that checks the signed payload and submits it to the chain for settlement. The facilitator is what lets the paying agent skip holding gas and skip broadcasting transactions itself. Because it submits the transaction, the facilitator's address is often the one shown as the transaction sender in a block explorer.
The practical consequence: if you look up an agent's payment on Basescan, the 'from' field of the transaction can be a facilitator, not your agent. The USDC actually moves out of your agent's address, and you see that in the token transfer event, not in the transaction sender. Tools that read only transaction senders will undercount agent spend.
What is EIP-3009 transferWithAuthorization?
EIP-3009 is an Ethereum standard that lets a token holder sign an off-chain message authorizing a specific transfer, which anyone can later submit on-chain. USDC implements it through the transferWithAuthorization function. The signed message names the sender, the recipient, the amount, a validity window (validAfter and validBefore timestamps) and a random 32-byte nonce.
This is the mechanism under most x402 payments on Base. The agent signs, the facilitator submits and pays gas, and the USDC contract emits an ordinary Transfer event from the agent to the recipient. It also emits an AuthorizationUsed event carrying the nonce, and the contract refuses to accept the same nonce twice, which blocks replay of that exact signature.
Two things follow for anyone tracking spend. An authorization can sit unsubmitted until validBefore passes, so a payment the agent 'made' in its logs may never show up on-chain. And the amount field is in USDC base units with 6 decimals, so 40000 means $0.04, not $40,000.
What is an associated token account on Solana?
On Solana a wallet does not hold tokens directly. Every SPL token balance lives in a separate token account, and the standard one for a given wallet and mint is the associated token account (ATA), a program-derived address calculated from the owner's public key and the token mint.
For USDC this means an agent's USDC balance sits at an address that differs from the agent's own public key. Transfers credit and debit the ATA, and the transaction records the owner only as the authority that signed. A tracker that watches just the wallet address and skips the ATA will miss every USDC movement.
Creating an ATA costs a one-time rent-exempt deposit of about 0.002 SOL, which the payer puts up. An agent paying a new recipient may fund that recipient's ATA, a native-token cost that never appears in a USDC-only ledger.
What do finality and confirmation mean for agent payments?
Finality is the point after which a transaction cannot be reversed. Base produces a block roughly every 2 seconds, and the sequencer includes a transaction almost at once. That inclusion is a soft confirmation, though. Stronger guarantees come once the batch containing it is posted to Ethereum and that Ethereum block finalizes, which usually takes minutes.
Solana has three commitment levels. 'Processed' means a validator has seen the transaction, 'confirmed' means a supermajority has voted on its block, and 'finalized' means at least 31 blocks have been built on top of it, typically about 13 seconds after inclusion. Slots are roughly 400 milliseconds apart.
For a spend ledger the choice matters. Reading at processed or soft-confirmed level gives you near-real-time numbers that can very occasionally drop a transaction. Reading at finalized level gives you numbers that never change after the fact, at the cost of a delay of a few seconds to a few minutes.
What is the difference between an EOA and a smart account for agents?
An externally owned account (EOA) is controlled by a single private key, and whoever holds the key can sign anything. A smart account is a contract wallet whose rules live in code. ERC-4337 is the common standard for these on EVM chains, and the rules can include daily limits, allowlisted recipients or session keys that expire.
Smart accounts give agent operators on-chain enforcement: the contract itself refuses an over-limit transfer. The tradeoff is complexity. Transactions go through a bundler and an EntryPoint contract, so the transaction sender is a bundler address, and your agent's address shows up as the smart account in internal calls and token events.
For tracking, both kinds of account reduce to the same question: which Transfer events debit this address. Whatever the account type, the reliable signal is token movement out of the agent's address, not whoever broadcast the transaction.
What is agent spend reconciliation?
Agent spend reconciliation is the process of matching what an agent believes it paid against what actually settled on-chain for its address. The inputs are the agent's own logs (requests made, prices quoted, authorizations signed) and the chain's record (Transfer events on Base, token balance changes on Solana).
The gaps come from the terms above: signed authorizations that expired unsubmitted, facilitator-submitted transactions attributed to the wrong sender, ATA rent paid in SOL, and payments read before finality. A reconciled ledger states, for each payment, whether it settled, when, for how much in 6-decimal units, and to which recipient.
getagentcap.com does this using only public addresses. You give it the agent's Base address or Solana public key, and it indexes the token movements that debit that address, including those submitted by facilitators, and flags where they differ from what you expected. No keys and no wallet connection are needed, because everything that settled is already public on-chain.