The regulator is not in this story. The program is.

According to The Defiant, the Solana Foundation has shipped a native onchain subscriptions and allowances primitive on Solana mainnet. The point, per The Defiant, is to give teams building on Solana a shared program for recurring billing, delegated spending caps, and merchant-published billing tiers.

A shared billing primitive, not a bespoke setup

The Defiant frames the delivery as infrastructure that other teams can reuse instead of building their own custody and billing plumbing. The Solana Foundation’s primitive is designed to support subscription payments and “allowances” using native onchain components.

That matters because billing systems tend to sprawl. The moment you make it custom, every integration becomes a new risk surface and a new maintenance job. The Defiant’s description implies Solana Foundation is trying to standardize the parts that usually get re-implemented.

The Defiant also says the primitive targets recurring billing and capped delegated spending. In other words, it is not just about paying once.

Delegated spending caps shift who holds the leash

Allowances onchain sound simple until you ask who can spend and how much. The Defiant says Solana’s primitive includes “capped delegated spending.” That language points to a permissions model where a third party can move funds, but within limits.

For builders, the upside is operational. They can issue billing tiers and recurring permissions without standing up their own custody, billing systems, or related backend scaffolding, as The Defiant puts it.

For users and merchants, the upside is tighter control than a fully open spending approval pattern. A capped allowance also creates a natural boundary for what a subscription or service can take at each billing cycle.

Merchant-published billing tiers

The Defiant adds that the primitive supports merchant-published billing tiers. That means a merchant can define the tiers onchain and let the subscription logic reference those published tiers rather than re-encoding them across clients.

It is a small phrase in the article, but it hints at a broader shift. When pricing and tiers live in a common onchain format, integrations can converge. And when integrations converge, users spend less time guessing which app behaves which way.

What “native” changes

“Native” gets used as a marketing word. Here, The Defiant’s framing is more concrete. The primitive ships on Solana mainnet and is meant as a shared program that teams can call.

The risk is still real. Any shared billing rail becomes a dependency. If a bug lands in the primitive or if teams misunderstand how the allowance caps and tiers are enforced, the blast radius can be wider than a one-off integration.

What to watch next

The Defiant’s piece emphasizes that teams building on Solana now have a shared onchain program for subscriptions and allowances. The next question for the ecosystem is whether developers adopt it quickly, and how wallets and apps represent the recurring billing and capped delegated spending mechanics to end users.

Adoption is not automatic. But the groundwork is now on mainnet, which is the only place infrastructure can actually prove it works.