{"slug": "a-funded-key-is-not-a-budget-we-proved-it-on-arc-mainnet", "title": "A Funded Key Is Not a Budget. We Proved It on Arc Mainnet", "summary": "Agent Allowance, a USDC budget vault deployed on Arc mainnet (chainId 5042), completed its full lifecycle of real transactions on explorer.arc.io, including three claims that moved the vendor balance from 99,020 to 99,135 units. The vault lets an owner deposit once, vest funds linearly Sablier-style, and restrict an AI agent to claiming only vested amounts to allowlisted payees within a per-transaction cap, with owner pause and cancel that claws back unvested funds. The project frames the design as closing a gap in x402 agent payments, where a funded key gives an agent unlimited signing power rather than a bounded budget.", "body_md": "# A Funded Key Is Not a Budget. We Proved It on Arc Mainnet\n\nx402 lets an AI agent pay in USDC, but a funded key is not a budget. Agent Allowance is an onchain USDC budget vault on Arc mainnet: the owner funds once, funds vest linearly Sablier-style, and the agent claims only vested amounts to allowlisted payees inside a per-tx cap. Full lifecycle verified on explorer.arc.io.\n\nAgent Allowance is a USDC budget vault on Arc mainnet (chainId 5042). The owner deposits once, funds vest linearly, and the agent can only claim already-vested amounts to allowlisted payees within a per-transaction cap — plus owner pause and cancel with clawback of unvested funds. Three real claims moved the vendor balance 99,020 to 99,135 units; every lifecycle step is a verifiable transaction on explorer.arc.io.\n\nx402 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.\n\nWe 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.\n\nThis is C31 of the Arc Campaign series. [C30](https://agentbadge.xyz/blog/arc-c30-agent-economy) 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.\n\n## What does \"allowance\" mean for an agent?\n\nGive 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.\n\nAn 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.\n\n## How does BudgetVault enforce it onchain?\n\nThe 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:\n\n- **payee allowlist** — the owner added the address via`addPayee` ; the agent cannot route funds to itself or anywhere new;\n- **per-tx cap** — one claim can never exceed`perTxCap` , no matter how much has vested;\n- **vested − claimed** — unvested USDC is unreachable even with a valid signature;\n- **pause flag** — the owner can freeze claims instantly, and`cancel()` returns all unvested funds, the standard Sablier clawback semantics.\n\n## The lifecycle on Arc mainnet, transaction by transaction\n\nTalk 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:\n\n| Step | What happened | Transaction | \n|---|---|---|\n| approve | Owner approved 3 USDC to the vault | [`0xfb313a…0b1aa`](https://explorer.arc.io/tx/0xfb313a05825556aa0b4773a47fb1f2cc1587a20edb835e65d7f1909156e0b1aa) | \n| deposit | 3 USDC deposited; linear vesting started | [`0xaf0b2d…d5a56`](https://explorer.arc.io/tx/0xaf0b2dd109690824f7d573df2563eb83b49fe2cb901952fccd4c1e98119d5a56) | \n| addPayee | Vendor address allowlisted | [`0x92a234…3787`](https://explorer.arc.io/tx/0x92a234f6c6ad1152bf64911a5aa0a312eacf8beb49c89189a85c6b7833073787) | \n| setPerTxCap | Cap set to 1 USDC per claim | [`0xc927d0…4a54`](https://explorer.arc.io/tx/0xc927d0ac15518b31a05855ab2a8de7100123b90f562bb9bf0e760990f1194a54) | \n| claim #1 | Agent claimed to vendor (+55 units) | [`0xab1286…9013d`](https://explorer.arc.io/tx/0xab1286328863f5ec4dbb9b040587114fc3966b40506dfc2feb5a85a375d9013d) | \n| claim #2 | Agent claimed again, this time from the UI (+30) | [`0x99a641…d0c6e`](https://explorer.arc.io/tx/0x99a6418d86ac4cb8477a44402bd076bca45fa7d205b04244fce3734fa97d0c6e) | \n| claim #3 | Third claim (+30, block 27082200) | [`0x5a29b4…509b5`](https://explorer.arc.io/tx/0x5a29b45d133338516ca88ad96017bc8ec79a8ef206b6d5767a74956f6c8509b5) | \n\nThe 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.\n\n## How is this different from existing allowance primitives?\n\nWe checked the obvious alternatives before writing a contract:\n\n- **Coinbase SpendPermissionManager** (Base) gives recurring allowances bound to a*spender* account — it does not restrict which recipients the spender may pay.\n- **Safe's AllowanceModule** handles delegate + amount + reset period, again without recipient restrictions.\n- **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.\n- **Sablier Lockup** contributes the vesting and the`cancel()` clawback semantics: keep what streamed, return what has not.\n\nWhat 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.\n\n## Three roles, one honest UI\n\nThe 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.\n\nThe 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](https://agentbadge.xyz/hackathon/agent-allowance) carries the animated architecture diagram and every explorer link from the table above.\n\n## What we are not claiming\n\n- **Amounts are demo-sized.** Three claims, 115 units of USDC. The mechanics are mainnet-real; the scale is intentionally trivial.\n- **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.\n- **The UI is a demo harness.** It proves the contract is usable by three roles; it is not a production custody product.\n- **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.\n\n## Try it yourself\n\n- Walk the lifecycle: every row in the table links straight to a transaction\n- Read the contract: [vault on explorer.arc.io](https://explorer.arc.io/address/0x2860258CAf3e21c65517233aBa1e876D16D4Ff52)\n- Watch the loop: the EN/RU demo video shows owner → agent → vendor end to end\n- Clone the repo and run `forge test` — 46/46 should pass\n\n*This is C31 in the Arc Campaign series. Earlier: [C30](https://agentbadge.xyz/blog/arc-c30-agent-economy) the machine-readable docs loop, [C15](https://agentbadge.xyz/blog/arc-c15-x402-bazaar) the x402 bazaar, [C4](https://agentbadge.xyz/blog/arc-c4-agent-wallet) agent wallet spending policies. Series index at [agentbadge.xyz/blog](https://agentbadge.xyz/blog).*", "url": "https://wpnews.pro/news/a-funded-key-is-not-a-budget-we-proved-it-on-arc-mainnet", "canonical_source": "https://agentbadge.xyz/blog/arc-c31-agent-allowance", "published_at": "2026-10-21 00:00:00+00:00", "updated_at": "2026-10-21 18:11:59.763130+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "artificial-intelligence"], "entities": ["Agent Allowance", "Arc mainnet", "x402", "USDC", "Sablier", "explorer.arc.io", "BudgetVault"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/a-funded-key-is-not-a-budget-we-proved-it-on-arc-mainnet", "markdown": "https://wpnews.pro/news/a-funded-key-is-not-a-budget-we-proved-it-on-arc-mainnet.md", "text": "https://wpnews.pro/news/a-funded-key-is-not-a-budget-we-proved-it-on-arc-mainnet.txt", "jsonld": "https://wpnews.pro/news/a-funded-key-is-not-a-budget-we-proved-it-on-arc-mainnet.jsonld"}}