RSS Amplifier

coincept · Jun 24, 2026

Subscriptions Are the Surface. Permission Is the Primitive.

0
Sign in to vote or save

Ray · coincept

Most payment apps give users two imperfect choices.

Either you leave your card on file and trust the company to charge you correctly, or you approve every transaction one by one.

The first option is convenient but requires trust. The second option is safer, but quickly becomes annoying.

Wallet approvals are useful because they make user intent explicit. For recurring payments, small charges, API requests, and AI agent actions, the same habit can become friction.

On June 2, 2026, the @SolanaFndn announced Subscriptions & Allowances, a Solana payments feature for recurring payments and delegated spending.

Subscriptions are the headline. Permissioned spending is the bigger idea. Solana already works well for fast, low-cost payments. Subscriptions & Allowances adds a shared way for apps to handle payment rules: how much can be spent, who can spend it, and when permission ends.

The feature supports three main models.

Each solves a different payment problem, but together they point toward something broader: programmable payment permissions that applications can share instead of rebuilding from scratch.

Allowances let a user pre-authorize a one-time spending limit, with an optional expiration. The approved party can draw down from that allowance until the cap is reached or the time window closes.

For AI agents, this creates a cleaner control model.

An agent should not need full access to a user’s wallet. Asking a user to manually approve every small action also defeats the point of automation.

A better model is scoped permission.

You could approve an agent to spend up to $100 this week. The agent can then pay for things like API access automatically, in stablecoins, within the budget you allowed. If it reaches the $100 cap, it stops pulling under that allowance. No extra spend happens under that approval unless you create a new one.

The same wallet can also grant separate permissions to different services at once, like a subscription plan alongside a card program, without those approvals getting in each other’s way.


pay.sh, Solana’s pay-as-you-go layer for APIs, is a natural fit here. With Subscriptions & Allowances, pay.sh can now offer recurring flat-fee API access alongside its existing model.

A provider can offer recurring access, and an agent can pay for API use in stablecoins without turning every request into a separate human approval.

The same idea also works for human behavior. A reader could set a monthly cap for a publication and pay only for the pieces they actually open. The publication draws from the allowance per article, and the reader never commits to an unlimited charge.

Recurring delegations allow a user to authorize repeat payments on a schedule, with the spending cap resetting each cycle. This fits payroll, contractor payouts, and ongoing payment relationships where terms are agreed in advance.

The key difference is that recurring delegations reset. An allowance is drawn down until it is exhausted. A recurring delegation gives the payment relationship a rhythm: every week, every month, or every billing cycle.

A freelancer could agree to get paid $2,000 every two weeks. The payer sets the terms once, the cap resets each cycle, and every pay period does not need to become a fresh manual approval.

Subscription plans let merchants publish fixed billing tiers. A customer subscribes, and funds can be pulled automatically each billing cycle. The customer accepts the plan’s terms when they subscribe, so existing subscribers keep the pricing they agreed to. If the merchant wants to change pricing later, they create a new plan instead of quietly changing the old terms.

A SaaS tool could publish a Basic plan and a Pro plan. A customer chooses one and subscribes. If the company later changes pricing, the new price sits in a new plan the customer can choose to accept.

In most subscription apps, the billing rules live inside the company’s own systems. You trust each app separately to manage your billing relationship and payment permissions correctly.

With this model, payment permissions become part of a shared onchain program rather than existing entirely inside a company’s own billing system. The user can control what is allowed, how much can be spent, and when that permission ends.

Infrastructure providers like Helius, Confirmo, and Dynamic are already integrating it into API billing, stablecoin invoice collection, and embedded wallets. Subscriptions & Allowances is a shared payments infrastructure.

The program was built by Moonsong Labs with the Solana Foundation. It is open source, live on mainnet, and independently audited, so this is something teams can build on today.

The protocol can define the payment rule. The interface decides whether people actually understand it.

A good wallet or app should show active permissions, remaining caps, renewal timing, and cancellation controls in plain language. If a cap resets next week, the user should be able to see that before it happens. If an app still has permission to pull funds, the user should not have to search through menus to find it.

Clear permission screens turn the primitive into a product people can trust.

Serious payments products are built around rules.

Pay this bill every month. Let this employee spend up to this amount. Let this app charge me within this limit. Stop the permission when I revoke it.

Subscriptions & Allowances brings those rules into a shared Solana payments layer.

The strongest part of it is the move toward wallet-level permissioned spending. Users can give limited permission without giving up full control.

Spend this much, for this long, under these conditions. That is the part worth watching.

Once payment permissions become programmable, subscriptions are just one application. The same primitive can power AI agents, enterprise spending controls, API billing, payroll, and entirely new payment flows built on rules the user sets.

No posts

Read the original on coincept.substack.com

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.