Spendkit gives AI Agents bounded spending authority without giving them unrestricted control of the user's money.
MCP authorizes. Arbitrum enforces. The user keeps custody.
Why use Spendkit?
Spendkit adds a payment control layer between an existing Agent and a user-controlled Payment Wallet. Its value is the combination of day-to-day usability and verifiable payment rules:
No Spendkit deposit or custodial balance. The bound Payment Wallet submits each Router payment and supplies the USDG.
Agents can share a wallet while retaining separate onchain daily and per-payment Policies, visible in one dashboard.
The onchain daily budget renews at 00:00 UTC. Ongoing Router token permission does not require a new wallet approval every day and can be revoked.
OAuth + MCP gives an Agent access to exact, short-lived payment authorization; the Router checks the live Policy, and Payment Activity reconciles the result.
These rules protect payments made through Spendkit. A direct transfer made with a compromised Payment Wallet key remains outside this Router's Policy checks.
1. The problem
AI Agents can increasingly purchase APIs, services, data, and workflow outputs. Spendkit keeps the Payment Wallet key in a user-controlled local signing process, outside the LLM context and Spendkit Server, then routes authorized payments through the onchain Policy checks.
An offchain budget service alone is not a hard boundary. A compromised local Runtime or key store can use its Payment Wallet key for a direct token transfer outside the Router, so that host remains a trusted boundary. Router limits apply to payments sent through the Router.
Spendkit separates policy decision, transaction submission, fund custody, and hard enforcement.
2. Architecture
Local AI Agent
│ OAuth + MCP
▼
Spendkit Server
│ Policy lookup + preview + EIP-712 authorization
▼
Agent Payment Wallet
│ submits transaction and pays gas
▼
SpendkitPolicyRouter · Arbitrum
│ requires msg.sender = authorization.paymentWallet
▼
Payment Wallet ─────────────→ Demo Recipient
USDG
Spendkit Server never broadcasts payment or pays gas. The bound Payment Wallet is both the Router transaction sender and the USDG source; the Router transfers directly to the recipient.
3. Roles and trust boundaries
| Role | Responsibility | Does not control |
|---|---|---|
| Spendkit Admin + Authorization Signer | Router administration, Policy management, pause control, and authorization signing. | Agent payment transactions and gas. |
| Agent Payment Wallet | Holds USDG and gas, submits Router transactions, and provides the payment tokens. | Spendkit authorization signing. |
| Demo Recipient | Receives USDG after Router validation. | Policy control. |
| Runtime Agent | Calls Spendkit through OAuth + MCP and coordinates the payment. | Policy mutation through MCP. |
| Spendkit Server | Evaluates requests and signs exact short-lived authorizations. | Payment submission and gas payment. |
| SpendkitPolicyRouter | Requires Payment Wallet caller and enforces Agent, Policy, token, recipient, amount, limits, expiry and replay. | Custody of transferred funds. |
4. Two security gates
Read Policy, preview ALLOW/DENY, validate readiness, and request an authorization for one exact payment before spending gas.
Independently rejects a different Payment Wallet sender, tampered amount/recipient, expired or replayed authorization, paused/revoked Policy, or limit violations.
5. Arbitrum + USDG integration
| Item | Current demo value |
|---|---|
| Network | Arbitrum Sepolia |
| Chain ID | 421614 |
| Payment asset | Paxos Test USDG |
| USDG address | 0xFFC95faa3d63Cde504a05B567C600B78C0b41892 |
| Decimals | 6 |
| Current Router | 0xe388644B4115fbE029FA4acC3b20a47600c4bA16 |
| Historical evidence Router | 0x7F3c2c570122501B276680148B0C88AAe0550153 |
| Source Router architecture | signed-authorization-v3 |
| MCP tools | 7 public data-plane tools |
USDG is the configured Sepolia asset. Previously recorded live evidence used the older Router deployment and does not verify the Payment Wallet sender refactor. This page does not imply endorsement of Spendkit by Paxos or Global Dollar Network.
6. Evidence judges can verify
Latest production-regression transaction: 0xa0b16825347b8749a27df7f2048cacd8a25a88f71479d7c17fbfe4fd89cabd43
| Evidence | Verified result |
|---|---|
| Amount | 0.01 USDG |
| Receipt | SUCCESS · block 312101737 |
| Payment Wallet delta | −0.01 USDG |
| Merchant delta | +0.01 USDG |
| Router balance delta | 0 USDG |
| Reconciliation | CONFIRMED · PaymentExecuted matched · authorizationUsed=true |
| Over-limit DENY | 0.11 USDG rejected by per-transaction limit |
Automated regression: server, Local Agent, and contract suites are tracked in dated regression reports. This live page intentionally avoids hard-coded test counts so it cannot become stale when coverage grows.
MCP interoperability: 36/36 production probes passed with the official TypeScript MCP SDK across auto negotiation, modern pin, and legacy mode. Spendkit does not claim full official MCP conformance; its current public surface is intentionally tools-only.
7. Recommended 3-minute demo
- Problem: explain why an unrestricted wallet key is unsafe for an autonomous Agent.
- Control plane: show the Agent, bound Payment Wallet, Policy limits, Router allowance, and Runtime Access.
- Agent connection: show OAuth + MCP discovery and the seven tools.
- ALLOW: preview a small USDG payment and request an exact authorization.
- Execution: the bound Agent Payment Wallet submits the returned Router transaction and pays gas.
- Proof: show the Arbitrum Sepolia receipt and confirmed Spendkit reconciliation.
- DENY: preview an over-limit payment and show the structured reason.
- Close: “MCP authorizes. Arbitrum enforces. The user keeps custody.”
8. Current scope and explicit boundaries
This Buildathon version is a testnet/developer product. It does not claim audited smart-contract security, production mainnet readiness, fiat rails, cross-chain bridging, custody, arbitrary transaction execution, or protection against compromise of the local Runtime / key store.