The familiar recurring-revenue pattern creators already know, rebuilt as a Move-native primitive.
Subscriptions are not going away. Creators want predictable recurring revenue, buyers want "set it and forget it" access to the services they rely on, and the monthly mental model is a deeply learned consumer pattern that doesn't need rebuilding from scratch. What needs rebuilding is the infrastructure underneath: today's subscriptions live in Stripe's database as brittle, platform-locked, off-chain billing records. Onchain subscriptions live in Move as verifiable, composable, portable objects.
This is one more tool in the creator's monetization chest, alongside streaming payments for usage-aligned relationships and consumption pricing for pay-per-use unlocks. Different creators, different audiences, different products benefit from different models. Onchain subscriptions are for the ones where monthly recurring is the right fit.
What Changes When a Subscription Is Onchain
| Traditional (Stripe, etc.) | Onchain (Whop) | |
|---|---|---|
| Storage | Row in a processor's database | Move object on Aptos |
| Renewal | Off-chain cron job, flaky retries | Smart contract call, deterministic |
| Rev splits | Quarterly reconciliation, manual payouts | Atomic, encoded in the subscription |
| Cancellation | Dark-pattern flows, "are you sure" loops | One transaction, immediate |
| Portability | Platform-locked, not transferable | Transferable, composable with other products |
| Privacy | Processor sees every transaction amount | CA-confidential amounts (AIP-143) |
| Disputes | Chargebacks, 60-day review windows | Onchain record, verifiable by both parties |
| Refunds | Customer service ticket queues, slow and inconsistent case by case | Deterministic refund policy encoded in the subscription, programmatic post-purchase logic, brand consistency preserved |
The Subscription Object
Every onchain subscription is a Move object owned by the subscriber. It carries:
- ›The creator's
.whopname (the beneficiary for payouts) - ›The price, cadence (monthly, annual, custom), and renewal terms
- ›Revenue split logic, if the subscription pays multiple recipients
- ›Access credentials, which ACE domains, signal groups, Terminal feeds, or Indicator licenses the subscription grants
- ›Start date, next renewal date, and cancellation condition
- ›Optional: confidentiality flags (AIP-143 Zone 1) hiding the price from third parties
Because the subscription is an object the subscriber holds, it's composable. A subscription can be bundled with others, referenced by other Move modules, transferred (if the creator allows), or used as proof-of-access across Whop products without re-authentication.
Fully Onchain Auto-Renewals
Traditional subscription renewals are brittle infrastructure: a processor's billing cron fires, tries to charge the card, fails sometimes (expired card, insufficient funds, fraud flag), retries with backoff, eventually drops the subscription. Every failure is customer-support overhead. Every off-chain scheduler is a centralization point and a liability.
Aptos replaces this with native primitives. Event-Driven Transactions (AIP-125) let a Subscription Object schedule its own next renewal directly onchain, no external cron, no off-chain billing service, no processor retry logic. A subscription can specify a next_schedule_delta_time of 30 days and automatically reschedule itself after each successful renewal, drawing from a delegated resource account the subscriber pre-funded. Aptos Labs explicitly called out subscription and billing systems as a target use case for this primitive, noting that "recurring payments can be scheduled with grace periods, notifications, and service access rules", all as native onchain logic.
Practically, this means:
- ›The renewal is a deterministic onchain event, not a cron job that could miss-fire.
- ›Grace periods and retry logic are encoded in the subscription module itself: "try again in 24 hours, pause after three failures, send event emission at each step."
- ›The subscriber knows exactly when their next charge will hit, verifiable onchain, with no processor opacity.
- ›The creator's revenue schedule is a pure function of the subscription state, no payment-processor outage can delay payouts.
The upcoming Scheduled Transactions upgrade pushes this further, letting subscriptions compose multi-step workflows at renewal, pull funds, execute splits, emit access events, update creator dashboards, all in one scheduled transaction.
Group Memberships for Signal Groups and Communities
The most natural on-ramp for existing Whop creators. A signal group with 1,000 Discord members today charges $50/month off-platform. Moving that subscription onchain:
- ›Revenue is recorded transparently on Aptos, making creator earnings verifiable for legal, tax, and lending purposes.
- ›Members can see (if the creator opts to show it) historical group revenue, retention, and engagement, a trust signal that replaces the manufactured-review system.
- ›Cancellation is one transaction, no "email support to cancel" dark pattern.
- ›Renewals are deterministic via Event-Driven Transactions, no "my card got declined and I lost access" edge case.
- ›Optional CA-confidentiality hides the price from the broader market while keeping it visible to tax authorities and the member themselves.
Portable and Bundled Subscriptions
Because the subscription lives in the subscriber's wallet rather than a processor's database, a single subscription can grant access across multiple creators' products if those creators opt in. The same primitive supports bundling: one subscription fans out to multiple creators atomically, one decision for the buyer, one line item, one renewal. Behind the scenes the BundleSubscription Move module routes the incoming payment proportionally to each contributor in a single atomic transaction with the splits enforced onchain. None of this is possible on Stripe, where each creator has their own customer record, their own billing relationship, and their own account.
Why this matters for creators: conversion. Asking a user to make three separate subscription decisions is three separate friction points. Asking them to make one, at a discount to buying each separately, is one. The bundled product is priced to be the obvious choice, the creators share revenue according to a pre-agreed split, and the reconciliation that would normally be a spreadsheet happens inside a single contract call.
Where bundling fits
Creator pack: community + course + live coaching. A creator's full offering as one package, with each component's revenue share baked in.
Rotating content tier. A group of creators (writers, researchers, analysts) pool their audiences into a shared subscription. Each subscriber gets access to every feed in the tier, and revenue splits adjust at each renewal based on the prior period's measured engagement. If one creator drives 40% of the reads, they earn 40% of the pool that period.
Trading community + vault access. A portion of the subscription funds a shared vault, and vault profits flow back via streaming payments.
When to Use Subscriptions vs. Streaming vs. Consumption
Three questions decide:
Is the buyer's usage continuous or intermittent? Continuous but predictable → subscription. Continuous and variable → streaming. Intermittent → consumption.
Does the creator want predictable revenue or revenue aligned to value delivered? Predictable → subscription. Aligned → streaming or consumption.
How sensitive is the buyer to commitment? Low → subscription is fine. High (they want out easily) → streaming is the right call.
A creator doesn't have to choose one. A signal group might offer a monthly subscription for the majority of members who want simplicity, a per-second copy trading stream for active traders, and per-paragraph Feed unlocks for non-members who want occasional access. All three are available on the same stack.
Related: Streaming Payments for usage-aligned relationships. Consumption-Based Pricing for pay-per-unit. Royalties for the attribution layer that routes revenue across contributors.