Solana token delegation explained: what an approval lets someone take.

What is token delegation on Solana?

On Solana, tokens such as USDC sit in token accounts, one per wallet per token. Only the owner of a token account can move its tokens, unless the owner names a delegate. The SPL Token program's documentation puts it plainly: "Account owners may delegate authority over some or all of their token balance using the Approve instruction", and "Delegated authorities may transfer or burn up to the amount they've been delegated."

Three rules from the Solana documentation shape everything that follows:

1. One delegate at a time. A token account holds "one current delegate and one delegated amount at a time."
2. A new approval replaces the old one. "Approving a new delegate replaces the previous delegate and allowance on the account."
3. Revoking clears it. "Revoking a delegate clears the token account's current delegate and resets the delegated amount to zero." On the SPL Token program, the owner signs the revocation.

Delegation is how a wallet lets money move later without the owner signing each transfer. It is the building block under every pull payment on Solana, including stablecoin subscriptions on Solana. The question is what limits the delegate once the approval exists.

Why a plain approve is a poor fit for subscriptions

A merchant could ask a customer to approve the merchant's own key as delegate for, say, twelve months of a plan, then pull one month at a time. The SPL Token program would let that happen, but it would not enforce any of the things a subscriber actually agreed to.

• The amount is a total, not a rate. The delegated amount says how much in all, never how much per month. A delegate approved for twelve months can take all twelve today.
• There is no destination. The approval names who may move the tokens, not where they go.
• The key is the whole defence. Whoever holds the delegate's key can spend the full allowance. If that key leaks, the allowance goes with it.
• Only one subscription fits. Because a token account has one delegate, a second merchant's approval replaces the first. Two subscriptions paid in USDC from one wallet would overwrite each other.

None of this is a flaw in SPL Token: an approval is a simple, general allowance. A subscription needs rules on top of it, and those rules need to live somewhere the merchant cannot quietly change.

How the Subscriptions program manages delegations

The Solana Foundation's Subscriptions program describes itself as a "Solana program and clients for managed token delegations on SPL Token and Token-2022." It solves the one-delegate rule with a layer of its own. For each wallet and token pair it creates a program-controlled account, the Subscription Authority, and makes it the sole delegate on the wallet's token account, approved for the largest possible amount.

That authority is not a person and has no private key. Solana's documentation says it cannot move funds on its own: a transfer succeeds only when it matches one of the wallet's active authorisations, each kept in its own record. The program offers three kinds:

A plan holds an amount in base units, a period in hours, a list of destinations and a list of pullers. The plan documentation says "Only the merchant or a wallet listed in pullers can collect payments", and, when the plan uses a destination allowlist, the receiving account's owner "must be listed in destinations." Terms are fixed per subscriber: "Existing subscribers keep the terms they accepted, while new subscribers accept the current plan terms."

What the program checks before any USDC moves

Fianto runs its subscriptions on this program, at De1egAFMkMWZSN5rYXRj9CAdheBamobVNubTsi9avR44. Each recurring price that someone subscribes to gets a plan whose amount per period is the price plus the service fee and the network fee. The plan pays two kinds of wallet: the merchant's receiving wallet and, when a fee is above zero, Fianto's treasury. On Fianto the plan is created by Fianto's plan-owner key and the pullers are Fianto's charging keys. The amount, the token, the period and the destinations never change once the plan exists. What can change is the list of pullers, and a plan can be given an end date or sunset, which stops new subscriptions; so a charging key can be replaced without touching anyone's terms.

Before a collection moves anything, the program refuses:

• a signer that is not on the plan's puller list;
• a transfer to anywhere but the plan's destinations;
• more than the plan amount in one period;
• any charge after the subscription is cancelled or has expired, or on a plan that is past its end date or closed;
• terms that differ from the ones bound when the customer subscribed;
• an authority that is stale.

The program is public and its audits are published, each covering the commits it names. The Cantina reports sit in the program's audits folder. How Fianto handles keys and money is on the security page.

What does 'one authority per wallet and token' mean?

The Subscription Authority is created once per wallet and token, not once per subscription. A wallet that pays three subscriptions in USDC, from three different businesses, has one USDC authority, and all three subscriptions go through it. It does not matter whether the businesses use Fianto or another service built on the same program.

With Fianto, the wallet's first subscription creates that authority. The checkout calls it a one-time wallet setup and shows its rent, about 0.00163 SOL today, which is not returned when the subscription ends. Later subscriptions from the same wallet reuse it.

Two consequences follow:

1. Removing the approval affects every subscription at once. A wallet app or a "revoke approvals" tool that removes the USDC delegate takes it away from every Subscriptions-program subscription on that wallet. Each of them fails at its next charge.
2. A wallet may show it as unlimited. The approval is for the largest possible amount, so a wallet can list it with no amount limit. What limits a collection is each subscription's own terms, which the program checks on every transfer.

Can the merchant drain my wallet?

No. Here is precisely what a Fianto subscription on the Subscriptions program can and cannot take.

Two honest limits to that answer. First, the caps add up: a wallet with three subscriptions can be charged three capped amounts in a period, one per subscription. Second, the guarantee is only as strong as the program, which is why its source is public, its audits are published, and the build deployed on mainnet is verifiable against that source. The program is not frozen, either: its upgrade authority can still deploy a new version of it.

How to stop one subscription without breaking the others

Cancel the subscription itself, not the approval. A Fianto customer signs in to the customer portal at fianto.xyz/my with a signed message, which moves nothing, and cancels with one signature. The subscription runs to the end of the paid period and then stops. Every other subscription on the wallet keeps working.

If the approval was removed by mistake, the portal offers Re-authorise on the past-due subscription. That restores the shared approval, so every running subscription that uses it can be charged again. After a subscription ends, the portal's Reclaim rent returns that subscription account's rent, about 0.00197 SOL today; the wallet setup rent is not returned.

Developers who want the account-level detail can read the Subscriptions program page of the Fianto docs.