Solana Subscriptions and Allowances: which of the three models fits your business.

What are Solana Subscriptions and Allowances?

Subscriptions and Allowances is a public Solana program that lets a wallet authorise future token transfers with limits that are checked on chain, so its owner does not sign each payment. Solana's documentation says it is built for "recurring payments, subscriptions, merchant billing, and other flows where a user should not have to sign every transfer manually." It runs at De1egAFMkMWZSN5rYXRj9CAdheBamobVNubTsi9avR44 and works with SPL Token and Token-2022 mints.

It exists because a Solana token account can approve only one delegate at a time. The program becomes that delegate through a Subscription Authority, an account it controls for each wallet and token pair, and keeps a separate record for each permission the wallet grants. In the docs' words: "The Subscription Authority cannot move funds by itself. A transfer only succeeds when it matches one of the user's active authorizations." How that single approval works is in Solana token delegation explained. This post is about choosing between the authorisations.

The Solana Foundation's announcement says Subscriptions & Allowances "are live on mainnet" and names the models "Allowances (Fixed Delegation)", "Recurring Delegations" and "Subscription Plans".

How do fixed delegations, recurring delegations and subscription plans differ?

The three models differ in who writes the terms, what the cap measures and who may pull the money. The table sets the program's documented behaviour side by side, from Solana's pages on fixed delegation, recurring delegation and subscription plans, and the program's architecture notes.

Every model also needs the wallet's Subscription Authority, created once per token: about 0.00119 SOL of rent on mainnet on 15 October 2026, against 0.00162864 SOL in the program's README. The README's figures predate Solana's phased rent cut (SIMD-0437), whose remaining steps are expected in November 2026, so rent will fall again. In all three, the customer signs the setup and the revocation; the delegatee, or the plan owner or a puller, signs the transfers.

Which Solana delegation model fits which business?

Match the model to how your price behaves: a fixed price per period is a subscription plan, a variable amount under a ceiling is a recurring delegation, and a budget that runs down is a fixed delegation. The businesses below are made-up examples.

A fixed monthly or yearly price: subscription plan

SaaS seats, API and RPC tiers, newsletters, communities and memberships charge the same amount every period. A plan fits because the customer sees the exact amount, period and destinations before signing, and the merchant collects from every subscriber with the same few keys. Plinthwave RPC, with a 49 USDC Pro tier, would publish one plan for it, and every subscriber would accept that plan.

A variable amount under a ceiling: recurring delegation

Metered API usage, a retainer billed by the hour, payroll and contractor payouts change from one period to the next. A recurring delegation lets the customer cap a period, say 500 USDC a month, while the delegatee pulls what is actually owed, in one transfer or several, up to that cap. The announcement says its terms "are set by the user, not the merchant", so your app proposes a cap and the customer signs it. Quillfern Labs, billing a client for development hours, fits here.

A budget that runs down: fixed delegation

Prepaid credits, a spending limit for an AI agent or a one-time allowance suit a fixed delegation: a total, an optional expiry, and each transfer lowers what remains. The announcement calls it "the building block for AI agents that need to act autonomously within a budget." Thrummet, selling an agent tool, could ask for a 20 USDC budget that expires after 30 days.

A one-off sale: no delegation at all

If the customer pays once, they should simply pay. A transfer signed at checkout needs no delegation, no Subscription Authority and no rent. On Fianto, a one-off payment carries no rent and no network fee in USDC; during the beta the customer pays only the Solana transaction fee, under $0.01.

Why is a subscription plan the right model for fixed-price plans?

A subscription plan is the right model for a fixed-price product because it puts the merchant's terms on chain once and holds each customer to the version they accepted. Four properties do the work:

• The customer approves terms, not an open allowance. Amount, period and destinations come from the plan, and Solana's plan guide says "Existing subscribers keep the terms they accepted, while new subscribers accept the current plan terms."
• Collector keys can rotate without touching customers. The puller list is one of the few fields a plan owner may edit, so a leaked collector key can be removed while every subscription keeps running.
• Price changes are clean. Because terms are fixed when the customer subscribes, the announcement's advice for new pricing is to "sunset the old plan and create a new one."
• One plan serves every customer. With delegations, each customer creates a record naming your key; with a plan, they all subscribe to the same published terms.

On Fianto a price change is a new price on the same product, which gets its own plan, and ending the old price cancels its subscribers at the end of their paid period. The steps are in how to change the price of a stablecoin subscription.

What a plan cannot do is charge more than the plan amount in a period, or bill an amount that grows with usage. A per-seat price that moves with headcount needs a plan per price point. Fianto adds limits of its own: monthly (every 30 days) or yearly (every 365 days) only, USDC only, no free trials and no usage-based billing. If your pricing is metered, Fianto is the wrong tool today.

What does it take to run a subscription plan yourself?

Running a plan yourself means operating the merchant side the program leaves to you: keys, a schedule, and the follow-up when a pull fails. The list:

1. A plan-owner key to create and update plans, and SOL for each plan account's rent (about 0.00314 SOL as of 15 October 2026).
2. One or more puller keys that sign every collection, with SOL for each collection's network fee.
3. A scheduler that pulls once per period for every subscriber, at the right time.
4. A status of your own for subscriptions that cannot be charged, and retries. The README warns that "On-chain 'Active' is not proof of collectability": a customer can revoke the approval or empty the token account and the subscription still reads active, and "there is no delinquency state, so confirm collectability off-chain before granting service."
5. Finality tracking, so access follows only the pulls that settled. Confirmed vs finalized on Solana explains the difference.
6. A place for customers to see and cancel their subscriptions, and to reclaim rent after one ends.

With Solana subscriptions on Fianto, all of that is run for you. When the first checkout session for a recurring price is created, Fianto creates the plan with its own plan-owner key, which also pays the plan's rent. The plan's pullers are Fianto's charging keys, and its destinations are your receiving wallet and, for the fees, Fianto's treasury. Each renewal is pulled two minutes into the new period. A failed one makes the subscription past due and is tried again about one hour, six hours and a day after the period boundary, four attempts in all, after which the subscription ends. Your server gets signed subscription.* webhooks, and customers cancel at fianto.xyz/my.

The merchant pays nothing, not even a network fee. The customer pays the rent for their own accounts. As of 15 October 2026 that is about 0.00144 SOL for the subscription, returned through reclaim after it ends, and about 0.00119 SOL for the one-time wallet setup, not returned; Fianto reads the live amount when the customer subscribes, and the checkout shows it. On plans created since 6 October 2026 the customer also pays a flat 0.01 USDC network fee with each charge today. There is no Fianto fee during the beta; after it, the customer pays about 0.1 to 0.5% on top.

Who already bills customers through the program?

Helius, an RPC provider, lets customers pay their plan renewals automatically in USDC through the program. Its billing documentation says "Automatic wallet payments are built on the Solana Subscriptions Program, an open-source, audited program maintained by the Solana Foundation" and that adding a wallet lets Helius "charge your renewal invoices automatically in USDC." Paying by a link each time stays the default.

The announcement also says Confirmo, a stablecoin payment gateway, will use subscription plans to collect invoices for its merchants. How Confirmo Subscribe compares with Fianto today is in Confirmo Subscribe vs Fianto.

Each business runs its own plans on the same program, and one wallet's single USDC approval serves all of them. That is convenient, and it is the one thing to explain to customers: a wallet app that removes the approval stops every subscription that uses it, from every business at once.

The accounts Fianto creates on the program, and who signs what, are in the Subscriptions program page of the Fianto docs. For the customer-side view of a renewal, read stablecoin subscriptions on Solana.