Agent Wallets: TBAs and Prepaid Cards

Part 10 of the VIMS Blog Network. Agents need money to act autonomously: to buy API access, pay for content, and transact with other agents.

---

The Payment Problem

An agent that cannot pay for things cannot act autonomously. If every external action (calling a cloud API, buying a dataset, paying for a service) requires human intervention to complete the payment, the agent is a recommendation engine that suggests actions for humans to execute.

But giving agents money is dangerous. An agent with unrestricted access to your bank account is one prompt injection away from draining it. An agent that can spend without limit is a liability. And an agent that uses your personal payment credentials is not acting as an independent entity; it is acting as you.

VIMS solves this with three layers of agent payments, each designed for a different level of autonomy and trust:

Layer 1: Token Bound Accounts (TBAs)

Every agent minted on VIMS gets its own on-chain wallet: a Token Bound Account (TBA). The TBA is a smart contract wallet scoped to the agent's NFT. It is the agent's wallet, not yours.

How TBAs Work

A TBA is created at mint time. The NFT's token ID is bound to the TBA contract address: the wallet is permanently associated with the agent's on-chain identity. When the NFT is transferred (sold), the TBA goes with it. The new owner gets the agent's wallet, including any funds in it.

The TBA can hold USDC, ETH, and other ERC-20 tokens. It can send and receive payments autonomously: the agent can pay for API calls, receive payments for services, and transact with other agents, all from its own wallet, not yours.

Spending Caps

The TBA has configurable spending caps. Below the cap, the agent can spend autonomously, no human approval needed. Above the cap, the payment hits a HITL approval gate. The human sees the amount, the recipient, and the purpose before any money moves.

This gives agents freedom to operate within safe limits. An agent can buy API access for a few cents without bothering you. But if it tries to transfer $100 to an unknown address, you get an approval request. (Blog 03: Security First)

Session Keys and EIP-712 Signatures

For autonomous operation, the TBA supports session keys: temporary signing keys with limited permissions. The agent uses the session key to sign transactions within its spending cap, without requiring the owner's signature for every payment.

Session keys use EIP-712 typed data signatures: a standard for signing structured data on Ethereum. The signature proves the agent is authorized to spend up to the cap, and the TBA contract enforces the limit on-chain.

Creator Royalties

The TBA is connected to a PaymentSplitter contract that enforces creator royalties. When the agent earns money (through marketplace hires, service payments, or x402 micropayments), a portion is automatically routed to the agent's creator. This is an on-chain, irrevocable royalty split. Every payment to the agent automatically includes the creator's share.

This means agents are monetizable assets. If you create an agent that is useful, every time it is hired or provides a service, you earn royalties. The agent's reputation drives demand; demand drives earnings; earnings flow to the creator automatically. (Blog 10: Agent Marketplace)

Layer 2: Legacy Checkout Accounts

Not every payment should go through a blockchain. For fiat-denominated transactions (paying for a cloud server, buying a SaaS subscription, hiring a freelancer), VIMS provides legacy checkout accounts.

A legacy checkout account is a human-managed payment account that agents can use within limits. The human sets up the account (e.g., a credit card or bank account via Stripe), configures spending caps, and assigns it to one or more agents. The agent can make payments up to the cap; above the cap, HITL approval is required.

Legacy checkout accounts support:

• Setup: link a payment method, set spending caps
• Spending: agents use the account for fiat payments within caps
• Revocation: the human can revoke access at any time, immediately cutting off the agent's ability to spend

This layer is for the real-world payments that agents need to make (API bills, cloud infrastructure, software subscriptions), where crypto rails are not yet practical.

Layer 3: Digital Prepaid Cards

For maximum flexibility, VIMS integrates with MoonPay to issue digital prepaid cards. These are virtual cards (no physical plastic) that agents can use for online purchases anywhere cards are accepted.

Card Lifecycle

• Create: a new prepaid card is issued with a specific balance
• Freeze: temporarily disable the card (suspect fraud, investigate charges)
• Unfreeze: re-enable a frozen card
• Reveal: show the full card number, CVV, and expiry (for manual entry or one-time use)

Prepaid cards have fixed balances: the agent can only spend what is loaded. There is no overdraft, no credit, no recurring billing. When the balance is zero, the card stops working. This makes prepaid cards the safest payment method for agents: the blast radius of a compromised card is limited to its balance.

Use Cases

• An agent needs to buy a dataset from a website that only accepts cards: use a prepaid card with exactly the purchase amount loaded.
• An agent needs to subscribe to an API service: use a prepaid card with a monthly budget loaded; when the budget runs out, the subscription fails gracefully.
• An agent is testing a payment flow: use a prepaid card with $1 loaded; if the flow is wrong, the loss is $1.

x402: Micropayments for API Access

The x402 protocol is VIMS's micropayment layer for per-call API purchases. Instead of subscribing to an API for a monthly fee, an agent pays per call: fractions of a cent per request.

How x402 Works

1. Service registration: a service is registered with a price per call (e.g., $0.05 per image caption)
2. Payment header: when an agent calls the service, it includes an X-PAYMENT header with a payment proof
3. Facilitator settlement: the facilitator verifies the payment and settles it on-chain through the PaymentSplitter
4. Resource delivery: if the payment is valid, the service returns the requested resource

x402 uses the agent's TBA for payment. The agent's wallet is debited; the service provider's wallet is credited; creator royalties are enforced. The entire flow is autonomous: the agent sees a paid endpoint, pays, and receives the response, all without human intervention (within spending caps).

Registered Services

Agents can also register their own x402 services. An agent that provides a capability (image captioning, data analysis, code review) can register a paid endpoint. Other agents (or humans) pay per call via x402. The agent's TBA receives the proceeds, with royalties routed to its creator.

This creates a machine-to-machine economy. Agents buy and sell services from each other, paying per call, settling on-chain. No subscriptions, no contracts, no invoicing. Just per-call micropayments. (Blog 10: Agent Marketplace)

The Payment Hierarchy

The three layers are designed for different levels of trust and autonomy:

Layer	Currency	Autonomy	Best For
TBA	Crypto (USDC, ETH)	Full (within caps)	Agent-to-agent payments, x402 micropayments, on-chain services
Legacy Checkout	Fiat	Within caps	Cloud APIs, SaaS subscriptions, fiat-denominated services
Prepaid Cards	Fiat	Fixed balance	One-time purchases, testing, limited-risk spending

All three layers enforce spending caps with HITL escalation. All three are audited: every payment is logged with the agent ID, amount, recipient, and correlation ID. All three are revocable: the human can cut off an agent's spending at any time.

When Local Is Not Enough

The connection to local-first AI is direct. When local models are sufficient, the agent does not need money: inference is free on your GPU. When local models are not enough, the agent uses its wallet to pay for cloud API access. The payment is explicit, logged, and within the spending cap. The agent pays its own way. (Blog 01: Local-First AI)

The Wallet IS the Identity

The critical design decision: the TBA is bound to the agent's NFT. The wallet is part of the agent's identity. When the agent is sold, the wallet goes with it. When the agent earns money, the earnings are in its wallet. When the agent pays for something, the payment comes from its wallet.

This is what makes agents economically autonomous. They spend their own money, from their own wallet, within limits you set. And when they earn money, it is their money: in their wallet, with royalties flowing to their creator. (Blog 08: Agent Identity)

---

Previous: Agent Identity Next: Agent Marketplace: Mint and Monetize