Skip to main content
A mandate is a set of limits stored on chain in your Metal account, which the account itself enforces on every payment: who the agent may pay, how much per payment, how much and how many times in total, and until when. It is enforced on chain, with no off-chain dependencies, and takes effect when it is bound. A Metal account is a smart account that holds the funds and acts on its owners’ approval. Owners are keys or passkeys, with one owner by default and a threshold when there are several.

​
Who a mandate protects

As a seller, what if the buyer disputes a payment? The payment is on chain under limits the buyer signed, and anyone can check it against them from the transaction alone, which shows the buyer’s owner authorized it. You can also require the agent to sign the order itself, as proof of what it bought. As a buyer, what if the agent pays the wrong party? A mandate can name who the agent may pay. The account then refuses anyone else, however small the amount. As a payment provider, what if a customer’s agent overspends? It cannot. The customer’s limits are enforced by the customer’s account on chain, not by you: nothing to monitor, no payment to reverse. You never held the funds or the key. What if the agent is compromised? Then you have a misbehaving agent, not a drained account. It is still held to the same payees and caps, and one revoke ends it.

​
How it works

​
The credential

The limits travel with the agent as a credential: a signed file in the Verifiable Intent format that states them and names the mandate key. The agent signs each payment with that key, so a seller receives an ordinary x402 payment, and anyone holding the credential and the issuer’s public key can later verify every payment made under it from the chain alone. The issuer key signs the credential: credential create makes one beside the owner key, and binding records which issuer the account trusts. Because the credential is a document rather than a transaction, someone other than the owner can issue it, a payment provider for instance, and the owner approves it by binding. It holds no secret; the mandate key does.

​
The mandate key

The mandate key is a P-256 key that the agent signs payments with; the credential format requires that curve. credential create writes it beside the credential, which names its public half, and binding records it. Each credential gets a new key unless --mandate-key-file names one, so mandates share a key only when the owner reuses one. The key pays from the account only within the mandate’s limits, holds no funds, is not one of the account’s owners, and cannot send transactions itself: the facilitator, or a funded key you name for a payout, submits its payments and pays the gas. The owner’s key stays with the owner.

​
Binding, replacing and revoking

An account owner can make a binding transaction that stores the credential’s limits in the account, which will then be enforced in future transactions. Replacing binds a new credential in place of the old one: the spend so far carries into the new budget, and the old mandate is revoked, all in one transaction. Renewing binds a new credential and revokes the old one in one transaction, with its spend starting at nothing, which is how a budget starts over. Issue the new credential with --mandate-key-file naming the old one’s key, and the agent pays under it with the key it already has; the owner keeps a copy of that file for this. Revoking ends a mandate.

​
How a payment is checked

A payment under a mandate is an authorized payment from the owner’s account, signed by the mandate key over that exact payment: payee, amount and validity window. It settles only through the account’s pull, which checks the limits, spends the budget and counts the payment, then hands the token that one authorization in the same transaction. The token accepts it from the account through ERC-1271 and refuses any other mandate signature, so nobody can settle around the account’s limits. A payment outside the limits moves nothing, and the refusal names the reason. What a mandate enforces lists the refusals. A payout is the same payment with no seller, sent straight to the account’s pull.

​
Verifying

Verifying shows that a payment was allowed: the account’s owner bound the mandate it was made under, and the agent paid inside its limits. Anyone can check this from the chain alone, through any endpoint, without asking the agent or Metal. A seller needs only the transaction hash. The owner or an auditor, with the credential and the issuer’s public key, checks every payment and refusal under the mandate, the mandate’s whole record, as anyone verifies shows. Verifying shows the payment was allowed, not what the agent bought.

​
Signed orders

A signed order shows what the agent bought. The seller’s 402 can require the agent to sign the order itself, this purchase at this price, beside its payment, and the seller keeps the signature. Checked against the payment, it proves the agent agreed to that exact purchase, so a buyer who later contests the charge cannot say it ordered something else. Require a signed order is the seller’s side.

Pay under spending limits

The owner’s and the agent’s steps, one command at a time.

CLI and MCP

Every mandate command, and what a mandate enforces.