Skip to main content

v0.1.0 on Solana devnet

One deposit. Two billing models.

Recurring subscriptions and x402 micropayments share a single on-chain escrow on Solana. One signature funds both flows.

Get early devnet access How it works
  • Single signature
  • USDC on devnet
  • Subs + per-call
Built on Solanax402Anchor

Early access

Get early devnet access

Tell us what you are building. We share devnet endpoints, the IDL, and integration notes as 0.1.0 lands.

  • Devnet endpoints + IDL
  • Anchor 1.0.1 integration notes
  • Direct line to the protocol team

How it works

The protocol in three steps.

What an outside reviewer needs to see first, before the on-chain mechanics.

  1. Subscriber prefunds once

    The subscriber deposits stablecoins (USDC on devnet) into a single on-chain escrow called the Subscription PDA. That deposit is the only signature they ever sign for the relationship.

  2. Two flows debit the same balance

    A streaming subscription draws the monthly portion continuously. In parallel, an x402 facilitator settles per-call charges against the same escrow.

  3. One on-chain invariant keeps them honest

    Every debit checks withdrawn ≤ deposited atomically, so a streamed period and a per-call settlement cannot double-spend the same funds. Pro-rata refund on cancel reads the same fields.

Architecture detail for developers

Two writers share one balance, bound by a single invariant.

Subscribers prefund one Subscription PDA. Two writers debit from that balance, both bound by withdrawn ≤ deposited , so a session reservation and a streaming charge cannot double-spend the same funds.

Streaming subscription
keeper, continuous monthly portion
x402 settlement
facilitator, discrete per-call
On-chain invariant: withdrawn ≤ deposited
Token deposit prefund N periods Subscription PDA one escrow · token-agnostic 0 withdrawn deposited Streaming subscription keeper · monthly portion x402 settlement facilitator · per-call Merchant · single revenue source

Implementation runs on USDC on devnet. The protocol itself is token-agnostic; any SPL-token mint can be configured by the merchant at PDA creation.

The problem

Fragmented systems create fragmented experiences.

Merchants who need both monthly subscriptions and per-call usage charges run two contracts, two wallet approvals, and an off-chain reconciler to keep the books straight. Subscribers see two debits, two cancel buttons, two refund flows. Credits sit in a third silo, and a fourth wallet stores the rest.

Subscriptions

Streaming-payment contracts hold one escrow and cannot bill per request.

Usage billing

x402 facilitators settle per-call payments. They have no concept of a subscription.

Credits

Prepaid balances live in a custodial database. They are off-chain by default, and they do not move when the user migrates wallets.

Mini wallets

Embedded balances need a separate approval. They never settle against the main escrow.

Without Nakama, vs. with Nakama

Without Nakama

  • Two contracts, two wallet approvals, two cancel buttons.
  • Off-chain reconciler to keep subscriptions and usage in sync.
  • Refunds depend on a custodial backend honoring the math.
  • Credits and embedded balances live outside the main escrow.

With Nakama

  • One Subscription PDA, one signature, one source of truth.
  • Streaming charges and x402 settlements share one withdrawn_amount field on-chain.
  • Pro-rata refunds computed from elapsed time on cancel — no custodian in the loop.
  • Session reservations cap facilitator authority without moving funds.

Questions we keep getting.

Deeper context on the protocol, security model, and integration. Have something else? info@nakamapay.dev

Classical streaming contracts hold one escrow and emit a continuous payout. Nakama keeps that streaming behavior but adds a second writer — an x402 facilitator — that can settle per-call charges against the same balance. Both paths share one withdrawn_amount field on-chain, so a streamed period and a per-call settlement cannot double-spend the same funds.

A single invariant — withdrawn ≤ deposited — is enforced atomically by the on-chain program on every debit. Session reservations cap facilitator authority for x402 paths without moving funds. The keeper streams under the same constraint.

The implementation runs on USDC on devnet. The protocol itself is token-agnostic; any SPL-token mint can be configured by the merchant at PDA creation.

Pro-rata refund is computed from elapsed time on cancel. No custodian is in the loop — refund math runs against the same deposited / withdrawn fields the live debits touch.

0.1.0 is on devnet, intended for partner integration and review. A formal audit lands before mainnet. The repository is open source and includes the full test suite.

No. The settlement writer is a permissioned program path; any x402-compatible facilitator can be authorized by a merchant. Switching facilitators does not migrate balances.

One protocol. One balance.

Subscriptions and usage payments stop being two products to integrate and start being one balance to draw from.

Get early devnet access