What is a Base Spend Permission?
A Base Spend Permission is a signed authorization that lets a designated spender move a supported token from a user’s smart account within defined limits. The permission records the account, spender, token, allowance, recurring period, start time, end time, and distinguishing data. (Coinbase, SpendPermissionManager source)
It is a technical payment control, not a company resolution, provider approval, or legal delegation by itself. Start with the Agent Business Readiness Scan, and see Controlled Payment Activation for a business and provider assessment.
What does the permission control?
The current Base contract structure includes these core fields:
| Field | Meaning |
|---|---|
account | Smart account whose assets may be spent |
spender | Address allowed to initiate the spend |
token | Native token or supported ERC-20 token |
allowance | Maximum amount available within each period |
period | Time interval after which the period allowance resets |
start | Earliest valid time |
end | Expiration time |
salt | Value that distinguishes otherwise identical permissions |
extraData | Optional data available to the spender’s implementation |
The account owner signs typed permission data. The spender later submits calls through the permission manager, which checks approval, time, token, and available allowance before transferring value. The account owner can revoke the permission onchain. (Coinbase Spend Permissions repository)
How should an agent business use it?
Bind each permission to one accountable business context:
- identify the legal organization and human controller;
- identify the exact agent and production environment;
- approve a written authority with allowed purposes and counterparties;
- create a dedicated spender rather than reuse a broad treasury address;
- choose the token, allowance, period, start, and end;
- record who requested and signed the permission;
- log every spend with the business purpose and resulting output;
- reconcile onchain transfers with invoices, receipts, or service results;
- revoke and test failure before treating the setup as production-ready.
The onchain permission enforces token movement. Application policy must enforce rules that the contract does not know, such as approved vendor, product category, invoice terms, or required human review.
Does the permission remove all approval prompts?
After the user signs and the permission is active, the designated spender can initiate transfers within the defined limits without a fresh user signature for each spend. That is the feature, and also the reason to keep the allowance and duration narrow.
Do not issue a large indefinite allowance merely to avoid prompts. Start with the smallest amount, shortest useful period, and one test use case. Increase only after the business can explain the transactions, reconcile them, and revoke the permission reliably.
Should every agent use a separate spender or subaccount?
Separate identities improve attribution and incident response. A dedicated spender address or separately controlled account can isolate budget, activity, and revocation for one agent or environment. Confirm the exact account model, supported tokens, and SDK behavior against the current implementation before use.
Isolation does not make the agent the owner of funds. The organization and controller remain responsible for the account, policy, provider terms, and accounting.
What risks remain outside the contract?
Spend limits do not answer every business question. The implementation still needs to address:
- whether the recipient is the intended counterparty;
- whether the purchased service matches the business purpose;
- whether the price and terms changed;
- whether the output was delivered;
- whether a duplicate request caused repeated payment;
- whether token price or network conditions changed the intended exposure;
- whether the transaction creates tax, sanctions, accounting, or provider obligations;
- whether the spender application or signing environment is compromised.
Use server-side validation, idempotency, counterparty rules, monitoring, and human approval for these layers.
What should a revocation drill prove?
A useful drill tests the real permission manager and application path:
- sign a small, short-lived permission;
- complete one expected transfer;
- verify the allowance and evidence record;
- revoke the permission from the controlling account;
- attempt the same transfer again;
- confirm failure at the onchain or provider control;
- confirm the application reports the revoked state;
- create a replacement only after review.
Do not count a dashboard toggle as proof unless the transaction path actually fails afterward.
Who should hold the keys?
The customer or its chosen wallet provider should control account keys. An activation service can help define the permission, observe configuration, and document the test, but should never request a seed phrase or private key.
If a vendor needs signing access, use a scoped, documented provider-controlled design and understand its custody, recovery, and incident model before funding it.
What is the next step?
Record the intended transaction, token, maximum amount, period, spender, counterparties, approval owner, and revocation owner. Use the readiness scan to identify organization and authority gaps. Then request a Controlled Payment Activation assessment to compare Base permissions with other provider-controlled options.
Last updated August 2026. Base contracts, SDKs, supported chains, tokens, and product availability can change. Confirm current official documentation before production use. This is not legal, tax, financial, investment, or security advice.
Primary sources:
