Wallet-Native Recurring Payments on Solana

The commercial problem

Subscription billing is the highest-leverage revenue model in software, media, and consumer services — and it is structurally hostile to crypto-native businesses.

The reason: traditional recurring billing depends on the merchant having a one-way pull authorization against the customer's account. Stripe holds the card on file, charges it monthly, and absorbs the failure modes (declines, expirations, chargebacks) inside its own platform. A wallet has no equivalent primitive. Sending SOL or USDC is push-only; the customer has to remember to pay every period, and they will not.

Existing attempts to bridge this gap fall into two camps. Custodial wallets with embedded scheduling solve the UX but recreate the platform-dependency the customer left crypto to escape. Smart-contract subscription protocols on slow chains hit gas-cost and confirmation-time walls that make sub-$10 monthly tiers economically dead.

What was missing: a fast-chain, fully self-custodial subscription primitive where the customer pre-authorizes a vault, the merchant pulls on schedule, and neither party trusts a platform to honor the contract.

The system shipped

A Solana-native recurring-payment protocol with two surfaces.

Customer-side vault

The user deposits a balance and grants the protocol authority to release scheduled debits to a specified merchant address, on a specified cadence, up to a specified cap. The customer can revoke at any moment from the same wallet UI; no support ticket, no 30-day cancellation window, no dark patterns.

Merchant-side subscription manager

For sellers, an interface to define plans (price, period, trial windows), watch active subscribers, and reconcile cash flow. The merchant never holds the customer's funds; the vault holds them, and the protocol enforces the schedule.

Why Solana, specifically

Three properties matter for this use case, and Solana has all three.

Equivalent designs on Ethereum L1 are economically broken below ~$50/month tiers. Designs on most L2s introduce bridge dependencies that recreate platform risk. Solana removes both objections in one move.

Architecture choices that mattered

Pre-authorized vault, not a long-lived signature. The customer signs once to establish the vault and its terms (recipient, amount, cadence, total cap). Future debits do not require fresh signatures — the vault enforces the agreed schedule on-chain. This is the on-chain equivalent of a card-on-file authorization, but the authorization lives in code the customer can audit, not in the merchant's database.

Cap-bounded authority. The vault includes a maximum total drawable amount. Even if the merchant's keys are compromised, the loss is bounded by the cap, not by the customer's full wallet. This is the single most important design choice for institutional acceptance — it makes the primitive insurable.

Revocation is a single transaction. No support flow, no human in the loop. The customer ends a subscription by signing a revoke instruction; the vault stops authorizing further debits the same block.

Asset-agnostic by construction. A merchant can price a plan in USDC, USDT, or SOL. Stablecoin-priced plans give the merchant predictable revenue; SOL-priced plans give the merchant exposure to the asset. Both are valid, and neither requires a separate code path.

What this proves about the firm

We ship payment primitives, not just integrations. A recurring-payments vault is a category of system most advisory firms will not build because it requires real on-chain engineering. We built one to demonstrate the pattern.

We choose the chain to fit the use case. The Solana decision here is technical, not tribal. Different client mandates land on different chains; the case study demonstrates the architectural reasoning, not a chain preference.

We design for institutional acceptance from day one. Cap-bounded authority and single-transaction revocation are not consumer features — they are the controls a treasury or compliance team will ask for in week two of diligence. Building them in upfront is faster than retrofitting.

What we extract for client work

For SaaS companies, media businesses, membership platforms, and any operator with a recurring-revenue model considering crypto-native billing, this reference establishes the production pattern. A typical client engagement extends this with:

• ·Plan management UI integrated with the client's existing customer portal
• ·Dunning and retry logic for failed debits with configurable grace periods
• ·Revenue reporting into the client's BI stack (Looker, Metabase, in-house warehouses)
• ·Multi-jurisdiction tax handling — VAT collection in EU, sales tax in the US, GST in MENA
• ·Integration with an existing payment stack for hybrid card-and-wallet acceptance

Engagement type: Pilot Launch (Package B) for a single subscription product, Transformation Program (Package C) for a full billing migration.