Subscriptions, settled in five seconds.
Customer signs once. The chain fires the recurring charges, every period, on schedule. No off-chain keeper to maintain, no failed-charge retry queue, no payment-provider lock-in. The Stripe-Recurring stack — replaced by a smart contract and a built-in cron registry.
The problem with how this works today.
Stripe Recurring is a multi-billion-dollar product inside Stripe alone. The thing it sells is essentially "an off-chain cron + a retry queue + a chargeback ladder." We can do the first two natively.
Card-on-file recurring billing has a 5-15% failure rate per cycle (expired cards, declined banks, fraud holds). You spend engineering on dunning emails, retry logic, and reconciliation.
On other chains, "subscription" smart contracts need a keeper bot (Chainlink Automation, Gelato) to fire the recurring charge. Extra cost, extra dependency, extra failure mode.
International payments through traditional rails: FX spread, 3-5 day settlement, intermediary banks. For a $10/month subscription this eats half the revenue.
How Asentum changes it.
Three primitives that make this category cheaper, faster, and impossible to censor.
Recurring fires from inside consensus
Every block, the chain itself walks due jobs. Your subscription contract's "chargeAll" runs deterministically on the schedule. No keeper bot, no second system.
Stripe-shaped, on-chain
Familiar API surface: charges, customers, checkout sessions, webhooks. Drop our SDK into any Node app and you're billing in minutes. The settlement is on-chain underneath.
A standard for recurring
ARC-21 defines the on-chain interface for scheduled execution and subscriptions. Wallets, indexers, and dashboards can all surface "your subscriptions" in a uniform way.
What the code looks like.
Plain JavaScript. No new language, no new mental model.
// A recurring-billing contract.
// The customer signs ONCE. The chain fires every monthly charge.
contract Subscription {
// The merchant deploys this. Customers call subscribe() with a
// signature granting permission to debit them every period.
subscribe(amount, periodSec) {
storage.set('sub:' + msg.sender, {
amount,
periodSec,
nextCharge: chain.timestamp + periodSec,
});
cron.schedule(this.address, 'chargeAll', '+' + periodSec + 's');
}
// Called by cron at every period boundary.
// Walks every active subscriber and debits them.
chargeAll() {
for (const [addr, sub] of storage.entries('sub:')) {
if (chain.timestamp >= sub.nextCharge) {
transferFrom(addr, this.merchant, sub.amount);
sub.nextCharge += sub.periodSec;
}
}
cron.schedule(this.address, 'chargeAll', '+1d');
}
}
What you can actually build.
- →A SaaS product offering "pay monthly in ASE." Customer signs once. You get paid every month forever, no card-on-file, no dunning, no Stripe 2.9% + 30¢.
- →A premium newsletter on a Substack-equivalent: 10 ASE / month, fires automatically, splits to the writer + the editor via a revenue-split contract.
- →A streaming subscription that auto-downgrades to free if the user's balance runs low — and auto-reactivates when they top up. State lives on-chain.
- →A per-API-call subscription (Stripe Metered Billing equivalent) where each call records a usage event and a monthly cron settles the bill.
- →A donation subscription for an NGO: supporters give $X/month, the contract enforces the schedule, donors can see every period's settlement on a public ledger.
- →A tip-jar subscription where viewers commit to $1/week to a creator they like. Cron fires the charge. Creators see predictable revenue, viewers can cancel any time on-chain.