A Funded Key Is Not a Budget. We Proved It on Arc Mainnet

x402 lets an AI agent pay for things in USDC. That part works. The part nobody ships is the one that matters to whoever holds the keys: if the agent holds a funded key, the only thing standing between your balance and a bad prompt, a bug or a compromised model is the agent itself. A funded key is not a budget. It is just money with a chatbot attached.

We built Agent Allowance to close that gap: an onchain USDC budget vault on Arc mainnet where the owner funds once, funds vest linearly Sablier-style, and the agent can only claim what has already vested, to allowlisted payees, inside a per-transaction cap. Every guard lives in the contract, not in a promise. The full lifecycle — deploy, deposit, allowlist, cap, claim — is a chain of real transactions you can open right now on explorer.arc.io.

This is C31 of the Arc Campaign series. C30 was about making our own docs machine-operable. This one is about the money side: how an agent's spending power gets encoded instead of hoped for.

What does "allowance" mean for an agent?

Give a human assistant a company card and the card network carries the policy: limits, categories, revocation. Give an AI agent a private key with USDC on it and none of that exists. The key can sign anything, pay anyone, any amount, forever. Most agent-payment setups today stop exactly there — the agent gets a funded wallet and an API key.

An allowance fixes the semantics the same way an employment contract fixes a handshake: the owner defines a funded vault, a vesting schedule, a list of allowed payees and a per-transaction cap. The agent's spending power is bounded by all four at once. If the agent's key leaks, the blast radius is the remaining vested amount toward one allowlisted address — not the whole treasury.

How does BudgetVault enforce it onchain?

The contract is deliberately small. One deposit starts a linear vest — the balance an agent can spend grows second by second, which is the same mental model Sablier Lockup uses for payroll streams. Claims go through claim(amount, payee), and the contract reverts unless four checks pass:

• payee allowlist — the owner added the address via addPayee; the agent cannot route funds to itself or anywhere new;
• per-tx cap — one claim can never exceed perTxCap, no matter how much has vested;
• vested − claimed — unvested USDC is unreachable even with a valid signature;
• pause flag — the owner can freeze claims instantly, and cancel() returns all unvested funds, the standard Sablier clawback semantics.

The lifecycle on Arc mainnet, transaction by transaction

Talk is cheap; the explorer is not. The demo vault went through its full lifecycle on Arc mainnet (chainId 5042). Each step is a real transaction — open them and verify the calls yourself:

The vendor's USDC balance moved 99,020 → 99,135 units over the three claims — +115 total, all onchain, all explainable line by line. The vault sits at 0x2860258CAf3e21c65517233aBa1e876D16D4Ff52, deployed through the factory at 0x5D1a014e1FFE3b777F0946C2dd75A7d3aecdacA4. 46 of 46 Foundry tests pass.

How is this different from existing allowance primitives?

We checked the obvious alternatives before writing a contract:

• Coinbase SpendPermissionManager (Base) gives recurring allowances bound to a spender account — it does not restrict which recipients the spender may pay.
• Safe's AllowanceModule handles delegate + amount + reset period, again without recipient restrictions.
• ZeroDev / Biconomy session-key policies come closest: spend limits plus a contract allowlist in one policy. That pattern — "policy in code" — is the de-facto industry reference for agent spending, and it is the model BudgetVault follows.
• Sablier Lockup contributes the vesting and the cancel() clawback semantics: keep what streamed, return what has not.

What we add is the combination in one small contract plus a vesting dimension those allowlist-only designs lack: the agent does not just have a cap, it has a schedule. Money that has not vested yet cannot be spent, stolen or argued about — cancel the stream and it goes back to the owner.

Three roles, one honest UI

The demo interface is not a mockup — it is a three-role board wired to the live vault. The owner view shows funding, payee management, the cap, pause and cancel. The agent view shows vested and claimable amounts ticking in real time, the vesting schedule and the ERC-8004 agent identity (id 2, 0xcdd23d…869d) bound to the vault. The vendor view scans its own payee address and finds incoming payments with block numbers — no trust in the agent required.

The whole walkthrough is recorded: a 3-minute EN/RU demo video runs the loop end to end, and the hackathon landing at agentbadge.xyz/hackathon/agent-allowance carries the animated architecture diagram and every explorer link from the table above.

What we are not claiming

• Amounts are demo-sized. Three claims, 115 units of USDC. The mechanics are mainnet-real; the scale is intentionally trivial.
• One payee, one agent, one vault. Multi-payee, multi-agent and operator-claim patterns (a SignedIntent handed to an orchestrator) are designed seams, not shipped features.
• The UI is a demo harness. It proves the contract is usable by three roles; it is not a production custody product.
• No audit. Foundry suite is green (46/46) and every write is on the explorer, but the contract has not seen an external audit. Do not point a treasury at it.

Try it yourself

• Walk the lifecycle: every row in the table links straight to a transaction
• Read the contract: vault on explorer.arc.io
• Watch the loop: the EN/RU demo video shows owner → agent → vendor end to end
• Clone the repo and run forge test — 46/46 should pass

This is C31 in the Arc Campaign series. Earlier: C30 the machine-readable docs loop, C15 the x402 bazaar, C4 agent wallet spending policies. Series index at agentbadge.xyz/blog.