On-chain spending controls for AI agents

Give an AI agent a wallet without trusting it.

Spend limits are enforced by a contract on Celo, not by a sentence in a prompt. Most funds stay protected; the agent receives only permission to spend within policy, plus a small balance of its own for transaction fees and for x402 — the pay-per-request standard an agent uses to buy an API call.

  • Celo mainnet
  • · Open source
  • · No custody
  • · Any MCP agent

Live account, real money

Policy, balance and recent activity, read straight from a deployed account on Celo mainnet. No wallet connection is required.

Live on Celo mainnet0xBE38…1C3d↗
Maximum next direct payment— USDC

Reading the chain…

Daily allowance used—
Remaining today— / — USDC
Account holds— USDC
Per-transaction cap— USDC
Reading recent activity from the chain…

Use cases

Built for agents that need to spend, not hold unlimited funds

Use Leash when an automated workflow needs real payment capability and you need a hard ceiling on the damage it can cause.

Metered services

Buy APIs and compute over x402

Let an agent quote and pay for a metered resource while every draw still counts against its daily budget.

Automated payouts

Pay known vendors or contributors

Use per-payment limits and an optional recipient allowlist for direct USDC transfers from the protected account.

Long-running agents

Give automation a fixed spending envelope

Run workflows without keeping the full budget beside the agent key. Pause the operator without locking the owner out.

Protection model

Keep the budget and the hot key separate

Most funds stay in a contract you own. The agent gets permission to request bounded spends plus only a small operating balance.

Protected account

Most USDC

Held by the contract. Per-payment and daily limits are enforced before funds can move.

  • Per-payment cap
  • Daily cap
  • Optional payees
capped top-up
Agent wallet

Small USDC float

A hot operator key for gas and x402. Anything already here is outside the contract's protections.

Keep only what the next few tasks need.

Owner walletCreates the account, sets policy, authorizes operators, pauses activity and recovers funds.
Agent operatorRequests payments or a bounded top-up. It cannot change limits, unpause itself or sweep the protected balance.

Core capabilities

The controls a production agent wallet actually needs

Spending policy

Two hard limits

Set a maximum for one payment and a separate maximum for each UTC day.

Recipients

Optional direct-pay allowlist

Restrict execute payments to known addresses when the workflow has a fixed recipient set.

Owner controls

Pause, sweep, hand over

Stop every operator path and sweep funds without the agent policy blocking you. Ownership moves in two steps — nominate, then accept — so it never lands on an address that cannot use it.

Operations

Separate gas health

Track the protected budget and the agent’s small USDC gas reserve as two different balances.

Agent tools

Pay, check and fetch

Expose status, direct payment and x402 purchasing through the MCP server or TypeScript SDK.

Observability

Public, verifiable activity

Read limits, remaining allowance, balance and recent events without connecting a wallet.

Setup

From owner wallet to ready agent in four stages

Provisioning stays focused on the on-chain account. Connect MCP or the SDK afterwards, when the protected agent is already ready.

1

Create the account

You deploy and own the protected account outright. It holds the agent’s budget.

2

Set protection

Choose a cap per payment, a cap per UTC day, and optional approved recipients.

3

Authorize and fund

Fund the protected budget, then give a separate agent wallet limited access and a small USDC gas balance.

4

Review and monitor

Verify readiness, watch activity, and stop the agent whenever needed. Connect the owner wallet on any machine and its accounts are found again, so there is no address to write down.

Agent tools

Three tools, and nothing else the agent can call

The MCP server is published on npm. Point any MCP client at it and the agent gets these three — every one of them bounded by the policy on your account.

Published on npm
npx -y leash-agentpay

Node.js 20 or newer, and any MCP client — Claude Code, Cursor and Codex all speak it. The server is stdio MCP and nothing else, so naming one client would turn away the rest for no reason.

leash_status

Check the allowance

What is left today, what the caps are, and when the allowance resets.

leash_pay

Pay a recipient

Pay a Celo address. Refused past the caps, and the refusal explains itself.

leash_fetch

Buy a metered resource

Call an API that charges per request over x402 and pay for it. Quote first, against a ceiling you set.

That is the whole surface. Nothing here raises a limit, moves the money out, or authorises another agent — those live on the contract, behind the owner's key.

Security boundary

Know exactly what is—and is not—protected

Leash limits an operator; it does not make a hot key safe. The boundary below is part of the product, not fine print.

Protected by Leash
  • Every operator draw is bounded by the per-payment and daily caps.
  • Only the owner can change policy, authorize operators, pause or sweep.
  • The deployed rules are not a proxy and cannot be upgraded behind you.
  • The top-up path is closed at deployment; only the owner can open it.
Outside the boundary
  • USDC already in the agent wallet is outside the contract.
  • The payee allowlist cannot constrain top-ups used for x402.
  • A lost owner key cannot be replaced — ownership only moves while you still hold it — and the contract has not been audited.
On-chain evidence

Six claims over five transactions, each one open to inspect. Some name the same hash, because one spend can prove more than one thing.

The policy gates a real spendThe cap governed the transfer rather than merely coexisting with it: remainingToday, the account and the payee each moved by exactly 10000 — one hundredth of a USDC — read at the block before against the block itself.0x11cc0100…c8246fc ↗The attribution tag round-tripsThe tag survives the trip to the chain and back, rather than being taken on trust from what the sender says it sent: that same spend decodes to celo_3dec652cd977 straight from raw chain data.0x11cc0100…c8246fc ↗An agent spent through the policy, with no human naming the amountNo human typed an amount or a payee: an agent in a separate session, handed the account and nothing else, called leash_pay. remainingToday, the account and the payee each moved by exactly 100000.0x3cb307a4…8148704 ↗x402 paid with money drawn through the policyA purchase is bounded like any other spend: the agent paid 16753 for a metered resource, drew 17330 to afford it, and remainingToday and the account both fell by exactly the draw.0xd03c3b26…2baa807 ↗The facilitator settled it, and the agent held zero CELO throughoutThe agent never needed the chain’s own coin: it held 0 CELO throughout and paid its fees in USDC. This one was submitted by the facilitator rather than by us.0xedd104e3…15865ef ↗The contract is deployed and source-verifiedThe rules cannot be changed behind you: not a proxy, and not upgradeable. solc 0.8.24, with verification confirmed by forge verify-check rather than inferred from the submission returning OK.0xad28ee0d…22e7449 ↗

Ready to give your agent a hard spending limit?

Create an account you own, choose the limits, and verify every readiness condition before the agent starts working.