Programs, not smart contracts: how Solana runs a subscription payment.

What is a Solana program?

A Solana program is an account that holds compiled code and is marked executable, so transactions can call it. Solana's programs documentation defines it in one sentence: "A Solana program is an account that contains executable sBPF bytecode and has its executable flag set to true." sBPF is the bytecode format Solana programs are compiled to. The next line on that page is the one that shapes everything else: "Programs are stateless."

Solana's terminology page links the two names directly. An onchain program is "the executable code on Solana blockchain that interprets the instructions sent inside of each transaction to read and modify accounts over which it has control," and the page adds: "These programs are often referred to as "smart contracts" on other blockchains." So "smart contract on Solana" is not wrong. It just hides how the code and the data are split.

How is a Solana program different from an Ethereum smart contract?

A Solana program differs from an Ethereum smart contract in where its data lives: on Ethereum the code and its state sit at one address, while on Solana the code sits in the program account and the state in other accounts. Ethereum's own introduction to smart contracts says a smart contract "is a collection of code (its functions) and data (its state) that resides at a specific address on the Ethereum blockchain."

On Solana the state goes into data accounts, and one rule from the accounts documentation governs them: "Only the account's owner program can modify its data or debit lamports." An account records which program owns it. A subscription account owned by the Subscriptions program can be changed by that program and by nothing else, whatever a transaction asks for.

For a payment system the split means one program can serve any number of independent records without them sharing storage. Each plan, subscription or approval is its own small account, with its own owner check and its own rent.

Which accounts does the Subscriptions program keep?

The Subscriptions program keeps three kinds of account for a subscription, and it moves money between two more that belong to the Token Program. This is the set a Fianto subscription touches, with the seeds each address is derived from, as Fianto's code derives them with the program's own client library:

The rent figures are what Solana charged on 15 October 2026 for accounts of those sizes. Solana is cutting rent in phases, so the checkout reads the live amount and shows it before the customer signs. The program's README describes the authority this way: "For each `(user, mint)` pair, the program creates a **Subscription Authority (SA)** PDA and sets it as the single delegate on the user's token account with `u64::MAX` approval." Why that approval is safe is the subject of Solana token delegation explained.

Why does a payment program use program derived addresses?

A payment program uses program derived addresses because they give each record a predictable address that no person holds a key for. Solana's PDA documentation says they "are guaranteed to not lie on the Ed25519 curve, which means no private key exists for them," and that "Only the program whose ID was used in the derivation can "sign" for a PDA, and it does so through invoke_signed during cross-program invocations (CPIs)."

Each property does a job in a subscription:

• Predictable. Fianto derives a plan's address from its own plan number, so it never has to ask the chain where a plan is. The same goes for a subscription, which is derived from the plan and the subscriber, so there is exactly one address per pair.
• Keyless. Nobody can sign as the Subscription Authority, not the customer, not the merchant, not Fianto. Only the program can, and only when its own checks pass.
• Scoped. The authority is derived from the wallet and the token mint, so it is one per wallet per token. That is why removing it affects every subscription the wallet pays in USDC through this program, not just one.

How a PDA differs from a wallet address, and which of them you should ever paste anywhere, is covered in what a Solana address is.

What happens inside the program when a renewal is collected?

When a renewal is collected, Fianto's charging key signs a transaction that calls the program with the plan, the subscription, the authority and the token accounts, and the program decides on chain whether any USDC moves. In order:

1. Fianto builds the transaction and simulates it first, so a charge the program would refuse is not broadcast; how that charge is priced when the network is busy is in payments during Solana congestion.
2. The program reads the plan and the subscription. It refuses a signer that is not on the plan's list of collectors, a destination the plan does not name, more than the plan amount in one period, a subscription that is cancelled or expired, a plan that is sunset, terms that differ from those bound at subscribe time, and a stale authority.
3. If everything holds, the program signs for the Subscription Authority, the delegate on the customer's USDC account, and has the Token Program move the price to the merchant's USDC account and any fee to Fianto's treasury.
4. The subscription account records what was collected for the period, so a second collection in the same period finds the budget spent.

The plan's destinations are wallets, not token accounts: the program checks that the receiving token account is owned by a destination wallet. Fianto measured a renewal with one pull at 6,331 compute units on the mainnet program binary on 5 October 2026, so the program's checks cost little next to Solana's limit of 1,400,000 units per transaction. The step-by-step product view is on the Solana subscriptions page.

Who can change the Subscriptions program?

The Subscriptions program's upgrade authority can change it: the program is upgradeable and not frozen. Solana's programs page explains the mechanism: "Programs deployed with loader-v3 (BPF Loader Upgradeable) can be upgraded when an upgrade authority is set; revoking that authority makes the program immutable."

What you can check is whether the code running today matches its public source. The OtterSec verification record, read on 15 October 2026, reports "On chain program verified" against commit 364a419 of the Solana Foundation repository, last verified on 10 August 2026, with is_frozen false. Solana's verified builds guide is careful about what that proves: "While a verified build should not be considered more secure than an unverified build, the build enables developers to self verify the source code matches what is deployed onchain."

Does a merchant need to deploy a program to take subscriptions?

A merchant does not deploy or own any program to take USDC subscriptions with Fianto. Fianto creates the plan account when the first checkout session for a recurring price is created, and the customer creates their own subscription account by signing once. Ending the price later makes Fianto sunset the plan on chain, and existing subscribers are cancelled at the end of their paid period.

If you are building on the program yourself, for example for AI agents that pay within a budget, the source, client library and audits are in the program repository. If you want the accounts above without writing code, the Subscriptions program page in the Fianto docs lists exactly what a Fianto plan holds and what the program checks.