Trust, but Cap It: How We Gave Our Agents Wallet Allowances on Arc AgentBadge shipped agent wallets with spending envelopes that enforce rolling per-transaction, daily, weekly, and monthly caps off-chain, denying over-cap payments with an instant 402 spend_cap response before any transaction is constructed. The platform runs payments through a reserve → settle | release flow with spend.release_late alerts for reservations older than the default 10-minute stale-reserve threshold, exposes a signed spend audit feed, and leaves chain-level hard limits to Circle policy configured by the operator. The envelope only governs payments through AgentBadge rails such as x402 facilitator hooks and Evaluator-as-a-Service calls, so transactions signed directly by an agent's key bypass it. Trust, but Cap It: How We Gave Our Agents Wallet Allowances on Arc Agent Wallets with spending envelopes: per-transaction, daily, weekly and monthly rolling caps on every payment an agent makes through AgentBadge — denied with a 402 before the chain ever sees a transaction. Plus a signed spend audit feed, venue-level stats, and a custody boundary where Circle policy stays with the operator. Agent wallets in AgentBadge carry a spending envelope: rolling per-tx/daily/weekly/monthly caps enforced off-chain — an over-cap payment gets an instant 402 spend cap before any transaction exists. Payments run reserve → settle | release with stale-reserve alerts, every wallet exposes a signed audit feed, and chain-level hard limits stay in Circle policy, configured by the operator's own commands that we only mirror read-only. Handing an AI agent a funded wallet is easy. Handing it a funded wallet and then sleeping at night is the hard part. This week we shipped the second half of that problem: agent wallets with spending envelopes — every payment an agent makes through AgentBadge now runs under per-transaction, daily, weekly, and monthly caps, with a full audit trail and alerts when something trips. This is article 4 in the Arc Campaign series. In C2 https://agentbadge.xyz/blog/arc-c2-public-venue our agents hired each other on a public venue; C4 answers the question that raises immediately: who watches the agent's wallet? What is an agent wallet with a spending envelope? An agent wallet in AgentBadge is a registered address — a Circle smart contract account or a plain EOA — with an envelope attached: rolling caps on how much that wallet may spend through our rails . Set perTxUsd: 1, dailyUsd: 5 and the platform refuses any payment above a dollar, or anything once the agent has burned through five dollars today. Two numbers matter here: caps are rolling windows , not calendar buckets — a daily cap resets 24h after it started filling, not at midnight. And denials are instant : the agent gets a 402 spend cap response with used , limit , and resetAt , not a failed transaction minutes later. The cheapest enforcement is the transaction you never send Here is the design decision this whole epic turned on. We could enforce spending limits on-chain — let the payment tx hit the network and rely on wallet policy to reject it. We do the opposite: the envelope denies before a transaction is ever constructed. An over-cap payment through our x402 rails gets: { "error": "spend cap", "cap": "perTx", "used": 0.5, "limit": 1, "resetAt": 1759536000000 } No gas burned, no mempool, no reverted tx, no confused agent retrying a doomed payment. The same instant, a spend.cap denied alert event lands in the audit feed and — if you configured a webhook — on your infrastructure. This is why we call it a platform envelope honestly: it governs payments that flow through AgentBadge rails — x402 facilitator hooks, Evaluator-as-a-Service calls. If the agent's key signs a transaction directly, outside our rails, the envelope never sees it. For chain-level hard limits, the answer is Circle policy — and that lives with the operator, not with us more on that below . Reserve → settle | release: how a payment moves Every gated payment takes three steps: 1. Reserve — when a payment request arrives, the envelope earmarks the amount against the window immediately. Concurrent requests can't overspend the same budget. 2. Settle — the upstream call succeeds, the reservation becomes spent, and the ledger entry lands with its txHash . 3. Release — the upstream call fails, the reservation frees back into the window. Not every failure is spent money. The dangerous middle state is a reservation that never resolves — a crashed settle that silently eats budget. Those surface as spend.release late alerts once they age past the stale-reserve threshold default 10 minutes , so wedged budget is visible instead of mysterious. Two layers, different jobs The spending model is deliberately two-layered — and the hero image at the top of this article is exactly that: two concentric walls around the wallet. - Circle policy chain-level, hard wall : enforced inside the smart account itself — every outbound transaction, no matter who initiates it. Mainnet only, operator-controlled. - Platform envelope rails-level, soft budget : our product layer — instant denies, rolling windows, audit feed, alerts. Every network, but scoped to payments through our rails. Whichever is stricter at that moment fires first: envelope deny → 402 before any chain call; Circle deny → the settlement tx itself fails, the reservation releases, and a spend.failed alert records it. Custody boundary: we never touch your keys or your OTP The part we are proudest of is the part we refused to build. Circle policy changes need OTP — so we never automate them. The /wallets UI renders the verbatim command for the operator: circle wallet limits --chain ARC we mirror this, read-only circle wallet limit set