The Solana Subscriptions program, explained
All facts below come from the program deployed on mainnet, build 364a419.
In June 2026 the Solana Foundation released an open-source program for recurring payments. A customer approves a plan once: a fixed amount, every period. The merchant can then collect up to that amount each period, without asking again.
This page explains how it works, one account at a time, and ends with what the program does not do for you.
Why a token approval is not enough
Before this program, there were two ways to charge someone on Solana every month.
The first was to ask them to pay again, by hand, every month.
The second was a token approval. A token account on Solana can name one delegate, an address allowed to move tokens out of it, up to an approved amount. A merchant could ask the customer to approve them, then pull the price each month. It works, but it breaks in three ways:
- The limit is a total, not a rate. An approval of 120 USDC lets the merchant take 120 USDC today. Nothing says "10 a month".
- There is only one delegate per token account. If the customer approves a second app, the first one loses its approval. Two subscriptions paid in USDC cannot live on the same account.
- The customer sees an approval, not a plan. Nothing on chain records the price, the period, or who receives the money.
The Subscriptions program keeps the delegate, and puts rules in front of it.
One authority, many permissions
For each pair of a wallet and a token, the program creates a Subscription Authority. It becomes the single delegate of the customer's token account, with an unlimited approval. But the authority moves tokens only when a separate account, a delegation, allows it, and only within that delegation's limits.
One authority can serve many delegations. That is how a wallet holds several subscriptions in the same token.
The program offers three kinds of delegation:
| Kind | What it allows |
|---|---|
| Fixed | Spend up to a total amount, optionally until a date |
| Recurring | Spend up to an amount that resets every period |
| Subscription | Collect a merchant's published plan, period after period |
The rest of this page follows the third kind.
What a plan holds
A merchant starts by publishing a Plan account. It holds:
- the token it charges, such as USDC;
- the amount per period, and the period, in hours. Neither can change after creation;
- an optional end date, after which nobody can be charged;
- up to four destinations, the wallets that may receive the money (empty means any);
- up to four pullers, the addresses allowed to collect, besides the merchant who always can;
- a link to its metadata, such as a name and a logo.
To change the price, a merchant does not edit the plan. They give it an end date and close it to new customers (its status becomes Sunset; existing subscriptions keep paying until that date), then publish a new one.
What a subscription holds
When a customer subscribes, they sign a transaction that creates a SubscriptionDelegation account. It copies the plan's price and period at that moment. The merchant can later shorten the plan's end date or change who collects, but never the price or the period. It also counts:
- how much has been collected in the current period;
- when the current period started;
- when the subscription ends, if it was cancelled (zero while it runs).
How a subscription runs, step by step
| Moment | Who signs | What changes |
|---|---|---|
| Subscribe | The customer | The subscription account is created with a copy of the terms |
| Collect a payment | The merchant or a listed puller | Tokens move to a wallet the plan allows, up to the amount for this period |
| The period ends | Nobody | Nothing yet. The counters move at the next payment |
| Cancel | The customer alone | The subscription ends when the current period ends |
| Cancel now | The customer and the merchant | The subscription ends at once |
| Resume | The customer, before the end | The cancellation is lifted, the period is kept |
| Close | The customer, after the end | The account is closed and its rent goes back to whoever paid it |
Periods move only when money moves. The program does not watch the clock. When a payment arrives after a period has ended, the program moves the period forward by whole periods and resets the counter. A month nobody collected is skipped: at any moment, a merchant can collect at most one period's amount.
The customer can cancel alone, at any time. No new period starts after that; the current one can still be collected until it ends, if it was not already. Only an immediate cancellation needs both sides. To see what a wallet has signed and whether each one can still charge, paste it into the subscription permissions checker.
Closing returns the deposit. Every account holds a small amount of SOL as rent, which goes back to whoever paid it when the account is closed.
Who collects each payment?
Nobody, unless someone sends a transaction.
The program never runs on a timer. Each payment is a transaction that the merchant, or one of the plan's four pullers, must build, sign and send, and its network fee is paid by whoever sends it. A service that is not on the plan's puller list cannot do it for you: the program refuses its signature.
So something has to wake up when each payment is due.
What the program does not do
The program guarantees that a customer is never charged more than the plan's amount in a period. If the plan lists destinations, the money can only go to them; with an empty list, whoever collects picks the wallet. Everything else is left to whoever runs the plan:
- Sending each payment on time. A scheduler, a key allowed to collect, and SOL to pay the network fees.
- Noticing a payment that failed. A subscription reads as active even when the customer's wallet is empty, or when they removed the approval. The program's own README says it plainly: "On-chain 'Active' is not proof of collectability... there is no delinquency state."
- Retrying, and telling the customer. When a payment fails, the program records nothing. Whether to try again, when, and whether to email the customer is up to you.
- Deciding who has access. Your app needs an answer such as "this customer paid for this month". The subscription account alone cannot give it.
- Keeping the history. The program emits an event for each payment, and when a subscription starts, is cancelled or resumes, or a plan changes. Someone has to collect them, store them and show them to the merchant and to support.
Two more limits come from Solana itself:
- One delegate per token account still applies to other apps. If the customer approves another app on the same token account, that approval replaces the Subscription Authority, and every subscription in that token stops being collectable until the wallet approves the authority again.
- Removing the approval is not final. A wallet that removes the approval by hand can bring it back by signing the authority's setup again, and every old subscription becomes collectable again.
What does it cost?
The program charges no fee of its own. You pay Solana's rent and network fees.
Each account holds rent, in SOL, paid by whoever creates it and returned to them when it is closed:
| Account | Created when | Paid by | Rent comes back when |
|---|---|---|---|
| Subscription Authority | The customer's first subscription in a token | The customer | The authority is closed |
| Plan | The merchant publishes a plan | The merchant | The plan is deleted |
| Subscription | The customer subscribes | The customer, or a sponsor | The subscription is closed |
Every transaction also pays Solana's network fee, in SOL, charged to whoever sends it: the customer when they subscribe, the collector for each payment. The program's README lists the current rent of each account.
Can you trust it?
The program is open source under the MIT license, at github.com/solana-foundation/subscriptions. Cantina audited it several times, most recently in a report dated July 30, 2026. Its address is De1egAFMkMWZSN5rYXRj9CAdheBamobVNubTsi9avR44, on mainnet and devnet.
Where Mesub fits
Mesub runs the five jobs above on top of this program: it sends each payment, retries the ones that fail (on its paid tiers), emails the customer when a coming renewal cannot pay and their email is known, keeps every attempt, and answers your server with whether a customer has access. The plans stay on chain, owned by your wallet, and Mesub holds no funds.
- To decide whether to build those jobs yourself: Mesub or build it yourself.
- To charge your first subscriber: Accept USDC subscriptions in your app.
Sources: the program's README and its architecture notes (ADR-001 and ADR-002) at build 364a419; the Solana Foundation's announcement, June 2026.