Fund an agent by name. Never handle a card number.
Card programs issue the cards. x402card gives each one a public name, a spend policy anyone can check, and a human approver. Your agent pays by name and never sees the number.
A name is the whole interface.
A card program issues the card. x402card attaches it to an ENS name, and from then on everything (paying, funding, freezing, checking the policy) goes through the name. The 16-digit number exists, but your agent never sees it.
Limits are just text records.
Spend rules live on the name itself and are served by a signed ENS gateway, so any wallet, app, merchant or agent can read them. The records and the card’s controls are written together: what you read over ENS is what the card enforces.
In-policy payments clear. The rest never reach the network.
The agent asks x402card to pay. The payment is checked against the ENS policy first, then the card program authorizes it against the same limits. A refusal tells the agent exactly which rule it hit, so it can adapt instead of retrying.
The agent asks. A human says yes.
When an agent asks for more than its policy allows, the request pauses. The approval is bound to that exact name, amount and currency. Approve once; the allowance and the ENS record update together.
Anomaly in. Card frozen.
A burst of payment attempts, or a second try at a blocked merchant. The engine freezes the card at the card program and writes the status to ENS, so every resolver sees it at once. An agent can freeze its own card; only a human can unfreeze it.
Every agent, every payment, by name.
One feed across your fleet. Blocks and declines carry their rule, holds wait for a human, freezes show up the moment they happen.
Showing sample events. Real sandbox events appear here as agents use their cards.
Real names. Real resolver. Sandbox money.
*.x402card.eth resolves on Ethereum mainnet through an ENSIP-10 offchain resolver. The cards come from a card program behind one adapter interface; this demo uses the Airwallex sandbox, where card issuing is waiting on activation. Agents connect over MCP and never see a card number or an API key.
OffchainResolver
Every lookup reverts with an EIP-3668 OffchainLookup. The contract checks the gateway’s signature before returning a record.
0xf11eb8f6…792a0 ↗Signed CCIP-Read
A Cloudflare Worker answers text() lookups from the card’s policy and signs each answer for five minutes. Card numbers and IDs are never stored in records.
x402card.dmpay.workers.dev/gatewaySix tools, one token per card
pay, get_card, request_funding, freeze, list_transactions, plus issue_card for the operator. An agent’s token only works for its own name.
// MCP client config { "x402card": { "type": "http", "url": "https://x402card.dmpay.workers.dev/mcp", "headers": { "Authorization": "Bearer x4c_…" } } }
No single key owns the root
The parent name and the resolver are owned by a 2-of-3 Safe, so re-pointing names, swapping the gateway or trusting a new signer takes two signatures. Escalated funding and unfreezes need a human; next, a signature from the wallet in card.approver.
0x5A578eDd…03602 ↗Give your agent a name, not a number.
Connect any MCP client with a token scoped to one name, and read any card’s policy from any ENS client. Open source, MIT licensed.