Agent spending, bounded
Give agents spending power.Never give them your treasury.
Agents get bounded USDC capabilities on Arc: a cap, an expiry, and approved payees. A post-quantum security key keeps the treasury. The connected wallet does not sign an open or a close.
Agents need money to act.
And they increasingly do pay — for compute, data, APIs, infrastructure. The traditional answer is dangerous: hand the agent a long-lived key with broad access to your funds.
Agents need money. They should not own the treasury.
The traditional model
A compromised key reaches the entire treasury.
No per-call limits. No expiry. No recipient control.
Authority and spending live in the same credential.
Separate authority from spending.
Root authority
Rare and deliberate. Signs opening a capability, closing one, and rotating the root key. The operator cannot recover a lost key. The live demo root cannot schedule a replacement. A new root can, and that change waits 7 days. Keep the device backup safe. Protected by SLH-DSA — a post-quantum signature scheme.
Used a few times a year
Day-to-day spending
Frequent and automated. Agents pay inside an open capability. They cannot change its cap or payee.
Used every day · bounded
One root. Many capabilities. Spending stays inside them.
The post-quantum root does not authorize each payment. It opens bounded spending capabilities — Barkeep tabs — that carry their own policy.
Authorize the root
A post-quantum security key signs an open, a close, and a key change. The connected wallet is only the registrar. It does not sign those actions, and it does not sign each payment.
Open a capability
Fund a capability with a cap, a per-payment maximum, an allowlist of payees, and an expiry. You set these values.
Agents spend within bounds
The agent signs the spend with a separate key and pays only an approved payee, within the cap. The relayer broadcasts it and pays the Arc gas. A payment the backend refuses is never signed or sent.
Expire and reclaim
The security key can close a capability early and return what remains. After expiry the agent can no longer spend, and anyone can return the remaining USDC to the root.
THE GUARANTEES
Every capability is a vault with an allowance.
Every capability carries its own cap, per-payment maximum, approved payees, and expiry.
Assume breach
Nothing is reachable beyond the open cap.
The post-quantum root opens every capability. The cap, per-payment maximum, payee, and expiry are set at opening — before an agent can spend.
0
Reachable beyond the cap
ALLOWLIST
Approved payees
Payments outside the approved list are refused before anything is signed.
TTL
Time-boxed access
Every capability expires on schedule. The agent can no longer spend, and the USDC stays until someone reclaims it.
SEPARATION
Isolated agent keys
Agent keys spend only inside open capabilities. They do not sign root actions.
RATE BOUND
Per-payment limits
A maximum on each payment, in addition to the capability's total cap.
What Arc included
Opens, payments, closes, and returns. A rejected attempt is not written into this ledger.
FULL LEDGER
Assume the agent is compromised.
Design for the day it happens. With PQTABS, a compromised agent reaches only its open capability: its cap, its payee, and its expiry.
How far can a compromised agent reach?
Adjust the capability you grant — the boundary recomputes.
Example model, not an account
95% protected
Maximum reachable
5%
Protected
95%
Outside the open capability, the rest of the treasury is out of the agent's reach.
Capability share 5%. Maximum reachable 5%, protected 95%, per payment inside 1%.
Post-quantum verification belongs at the root.
Arc makes post-quantum verification available at the application layer. A root authorization is heavy and rare. Agent payments stay light, frequent, and bounded.
Signature scheme
SLH-DSA (SPHINCS+)
A stateless, hash-based post-quantum signature standard. No structural assumptions that quantum computers break.
Verification
Arc precompile
Arc’s precompile checks PQ signatures natively onchain. The protocol’s root authority is enforced by the chain, not by an offchain service.
What it protects
Rare root actions
Opening a capability, closing one, and rotating the root key. Day-to-day payments run inside an open capability.
Bounded tabs, hardened above.
Barkeep established the constrained spending pattern: the agent gets a bounded tab, not the treasury. PQTABS composes with that pattern — and adds a post-quantum authority above it.
“The agent gets a bounded spending tab.”
— The Barkeep pattern
“The authority that creates those tabs is protected by a post-quantum root.”
— The PQTABS layer
PQTABS doesn’t reinvent constrained spending. It hardens the authority above it.
Create a bounded capability.
A few plain-language choices and one confirmation. The interface shows the policy, and the backend refuses out-of-policy spends.
The interface
Cap
Capability
This gives the agent you choose a cap, a per-payment limit, approved payees, and an expiry. You set each value.
Real protocol concepts. Real constraints.
No hand-waving. Every layer of PQTABS maps to a concrete mechanism.
- ROOT SCHEME
SLH-DSA (SPHINCS+)
Stateless hash-based signatures. Security rests only on hash functions — the family quantum computers don’t structurally break.
- VERIFICATION
Arc precompile
The root contract checks each SLH-DSA signature through Arc’s post-quantum verification precompile. An action without a valid signature reverts on chain.
- CAPABILITIES
Barkeep tabs
Bounded spending objects: funded cap, per-payment maximum, approved payees, and an expiry.
- SETTLEMENT
Arc-native USDC
Gas and the payment are USDC on Arc. The research quote offers a PQTABS authorization and a standard x402 exact row for the same price and payee.
- AGENT KEY
Separate from the root
Spends use an ECDSA key kept in this browser, or in the Windows local signer. That key cannot open a capability or move root cash.
- POLICY
Refused before signing
The interface shows the policy. The backend refuses an out-of-policy spend before anything is signed. Barkeep also checks the spend on chain. That bytecode is not source-verified.
- CUSTODY
No operator recovery
This device keeps an encrypted backup. The downloaded file is for a new device. A new root can schedule a 7-day key change. The live demo root cannot. If the key for that root is lost, the USDC stays there. The backend does not store the root key.
The three-layer truth
UI displays policy
WHAT YOU SEE
Backend relays activity
WHAT YOU WATCH
Arc records every settled payment
WHAT SETTLES IT
The receipts are on Arc.
The security key signs an open and a close. The agent signs a spend. The connected wallet does neither. The relayer pays the gas and broadcasts.
Limits that stay in force
- The live demo root is a clone of the original PQRoot. It cannot be upgraded, and it has no delayed recovery.
- PQRootNext can schedule a key change that waits 7 days. If both keys are lost, or both are stolen, that schedule does not help.
- The Galaxy USDC vault reported maxDeposit of 0 on 2026-10-14. No USDC has been deposited.
- Barkeep's factory and tab implementation have bytecode on Arc. Their source is not verified, and it is not in this repository.
- A live Circle signature has not been produced. Circle compatibility is not verified.
- Published pqtabs-mcp 0.1.2 stops before signing when a quote includes both the research price and an exact row. The SDK in this repository accepts a matching exact row.
- The research price is 360 raw USDC, a demo subsidy. The relayer pays the Arc gas, which costs more than that charge.
Contract addresses and Sourcify status are in the repository README. RootFactory and PQRoot match on Sourcify. Barkeep does not.
Give agents room to act.
Keep the treasury under control.
The capability exists when Arc includes it.