If you have ever paid for a subscription with a card, you know the pattern: you authorize it once, and the merchant charges it automatically every month until you cancel. Doing the same thing with a crypto wallet used to be awkward. Either you signed a new transaction every billing cycle, or you handed an app a broad, unlimited approval and trusted it to only take what it should. Spend permissions are a more recent piece of smart wallet infrastructure on Base built specifically to close that gap.
What a spend permission actually is
A spend permission is a signed, onchain rule that lets a specific app, called the spender, pull a limited amount of a specific token from your smart account on a recurring basis, without asking you to sign again each time. You set the token, the amount allowed per period, and how long a period lasts. The app can then charge up to that amount once the period starts, and nothing more.
This only works with a smart contract wallet, the kind of account covered in our ERC-4337 explainer. A traditional externally owned account has no built in concept of a recurring, capped allowance that resets on a schedule. A smart account can enforce that logic directly in the wallet itself, which is what makes the feature possible.
How it differs from a token approval
It is easy to mix this up with the token approvals you already grant to swap and lending apps, but the two solve different problems.
A standard ERC-20 approval gives a contract permission to move up to a set amount of a token, whenever it wants, until you revoke it or it runs out. There is no concept of a billing period built into the token itself. A spend permission adds that missing piece: a cap that applies per period, for example a fixed amount of USDC per month, with the allowance resetting at the start of the next period rather than accumulating. If an app does not use its full allowance one month, that unused amount does not roll over or stack on top of the next period's cap.
The two mechanisms can also sit side by side. A spend permission typically still moves tokens using an approval style mechanism under the hood, but the periodic cap and reset logic is enforced by the permission itself, not by the token contract.
How it differs from a session key
Spend permissions are also easy to confuse with session keys, another smart account feature we have covered before. The two overlap in spirit, both let an app act without a fresh signature every time, but they are aimed at different jobs.
A session key is usually built for high frequency actions inside a single app session, like a game or a trading interface making many small calls in a short window. A spend permission is built for low frequency, long running billing: one charge per day, week, or month, running for as long as a subscription stays active. A session key typically expires in hours; a spend permission is designed to stay valid across many billing cycles until you cancel it.
What this looks like in practice
The flow a user actually sees is meant to resemble a normal checkout. You connect to an app offering a subscription, it asks you to approve a spend permission instead of a one time payment, and the approval screen shows the token, the amount per period, and the period length. You sign that once. From then on, the app's backend can request a charge when payment is due, up to the agreed cap, without another popup appearing on your device.
Settlement for this kind of recurring payment on Base is commonly done in a stablecoin like USDC, which keeps the billing amount predictable in dollar terms rather than fluctuating with the price of a volatile token.
Staying in control
The safety habits here are the same ones that apply to any approval, just pointed at a different kind of permission:
- Check the cap and the period. A reasonable spend permission shows a specific amount and a specific interval, for example a defined amount of USDC per month. If an interface does not show both clearly, treat that as a reason to pause.
- Match it to what you are actually buying. The cap should be in the neighborhood of the advertised subscription price, not dramatically higher.
- Know that you can revoke it. A spend permission is meant to be cancellable at any time from your wallet, which stops all future charges even if the app's backend keeps trying.
- Treat the request like any other signature. The general guidance in our piece on wallet signature requests still applies: read what you are signing before you approve it, rather than clicking through on habit.
Why this matters beyond convenience
Before mechanisms like this existed, recurring onchain billing mostly meant one of two bad options for users: manually resigning a transaction every cycle, which most people simply would not do, or granting an unlimited, indefinite approval and hoping the app behaved responsibly forever. A capped, time boxed, revocable allowance is a meaningful improvement on both, since the most an app can ever take in one period is fixed in advance, and the permission can be shut off the moment you decide you no longer want the service.
As more everyday services, from media subscriptions to software tools, experiment with accepting stablecoins directly, expect spend permissions and similar periodic allowance designs to show up more often on Base. The underlying idea is simple even if the name is unfamiliar: a subscription, enforced by your own wallet, with limits you set and can take back whenever you choose.