How We Built the Industry's First Real Crypto Subscription (When the Chain Has No 'Charge Later')

The short answer: card subscriptions exist because card networks have pull — after one authorization, the merchant can charge again later. Blockchains have no such primitive: every transfer requires the holder's signature, at that moment. The industry's workaround was to email the customer each cycle and hope — reminders wearing a subscription costume. Finality's subscriptions charge automatically, without custody, and the whole system rests on three design decisions: billing terms live in the vault's address (not in a database), the keeper can trigger but cannot decide (automation without authority), and the customer's exit is always open (withdraw, cancel, close — no permission needed). This is the story of those three decisions, including the parts that were uncomfortable.

The problem, stated honestly

We wanted the sentence "your subscription renews automatically" to be true, non-custodially. Walk the naive options and each one fails a different person:

• "Customer pays manually each month" fails the merchant: renewal rate = open rate × patience. That's structured churn, not billing.
• "Customer deposits a balance with us/the merchant" fails the customer: that's custody with a subscription UI — the exact thing this company exists to not do.
• "Customer grants unlimited spending approval" fails everyone eventually: an open-ended claim on a wallet is a breach headline waiting for its date.

The shape of a real answer: the customer pre-funds something they alone control, and that something is constrained in advance about what can ever leave it. A vault with rules. The three decisions are what made that shape real.

Decision one: the terms live in the address

The obvious build was: store plan terms — amount, cycle, recipient — in our database; have the on-chain program check "does this charge match the database?" It works, and it's wrong. A database row can be edited; whoever edits it can change what a vault will permit. The customer's guarantee would be our change-management process — a policy, wearing an architecture costume.

So the terms went into the address itself: a vault's on-chain address is derived from its billing terms. Amount, cycle, recipient — hash them differently and you get a different address. The vault the customer funded physically cannot be charged on other terms, because "other terms" describe a vault that doesn't exist. Nobody — us, the merchant, an attacker with our database — can move the goalposts, for the same reason nobody can redirect a payment.

The uncomfortable part we accepted: welded terms mean you can't edit a price. A plan change is a close-and-reopen, atomically, with proration recomputed on-chain. We took the friction; the friction is the guarantee.

Decision two: the keeper can trigger, but cannot decide

Something still has to initiate each renewal on schedule — the customer isn't awake at 3 a.m. on billing day, and "automatic" means nobody has to be. That something is our keeper process. And the second decision was about how much power it gets: none that matters.

The keeper says when; the vault's committed terms say whether, how much, and to whom — and the chain rejects anything off-terms. A compromised keeper could, at worst, charge on time, per the terms, to the committed recipient — which is to say, do its job. It cannot overcharge, re-route, or accelerate. Automation and authority are different things, and separating them is what lets a customer trust an automatic charge from a machine they've never met.

We call this shape out because it generalizes: the platform that can't hold funds, the merchant that can't withhold commissions, the keeper that can't decide — every trustworthy part of this system is trustworthy because of what it cannot do.

Decision three: the exit is always open

A pre-funded vault raises the question every customer silently asks: what if I want out? The third decision was that the answer had to be total, and had to require nobody's permission: withdraw the remaining balance anytime; cancel anytime; close the vault and everything comes back in one transaction — balance and the rent deposit too.

The counterintuitive result: making leaving effortless is what makes starting safe. A subscription you can exit in one signature, with every cent visible on-chain, removes the hesitation where crypto subscriptions actually died — not at renewal, but at the moment of first funding. Merchants worried we'd built a churn machine got the opposite: the industry's only recurring billing where the charge doesn't depend on the customer's inbox.

What we learned after it shipped

The features we thought were the product — automatic renewal, dollar-priced stablecoin billing — mattered. But the properties customers actually cite are the three constraints: the terms can't change under me; the machine can't take more than the deal; I can always get everything back. We set out to build recurring billing and ended up somewhere more specific: a way for two strangers to commit to a recurring deal that neither can break — the chain holds both ends.

That's also why this piece is a story and not a spec. The spec lives in the architecture article and the docs; what the spec can't show is that each constraint was a choice, made against an easier option, because the easier option quietly reintroduced trust.

FAQ

Why hasn't anyone else shipped this?

The custodial majority can't — automatic charging from custodied balances is just custody, and pull-approvals are a liability model most won't touch. The genuinely hard part is making constraint the product: terms-in-address, powerless keepers, total exits. That's an architecture bet, not a feature sprint.

What happens if the vault runs dry?

An insufficient-balance event fires before the charge fails — the merchant's retention lever, covered in the SaaS lifecycle piece. The customer tops up a vault they control; nobody's card expires.

Is the keeper a single point of failure?

Of liveness, not of safety — redundant keepers address the former, and the latter is the point of decision two: a keeper failure can delay a charge, never corrupt one.

How to cancel a crypto subscription built this way?

One transaction, no permission needed: canceling a crypto subscription here stops future charges and returns the remaining balance — closing refunds the rent deposit too. If a product makes "how to cancel" a support-ticket question, it failed decision three.

Can I subscribe without KYC?

Yes — a crypto subscription without KYC is the default here, for the same structural reason payments need no gatekeeper: nobody custodies your funds, so nobody needs to verify you first.

What exactly is welded into the vault's address?

Amount per cycle, cycle length, recipients and splits, promo terms, cycle cap. Change any one and the derivation yields a different address — which is why no database edit anywhere can alter your deal.

What happens if Finality disappears?

The vault is yours on-chain: balance withdrawable, close executable, funds recoverable — none of it requires our servers to exist. That's decision three doing its job in the worst case.

Can the keeper ever overcharge me?

No — the chain recomputes every charge against the welded terms and rejects mismatches. A compromised keeper can at worst charge on time, per the terms — that is, do its job.

Why not just use token approvals with a cap?

Capped approvals are better than unlimited ones, but the cap is per-approval, not per-schedule — nothing stops early or repeated pulls. Terms-in-address enforce when and how much per cycle, which is what billing actually means.

The three decisions fit in one demo: open the sandbox, fund a vault, watch a charge execute exactly on-terms, then close it and count what comes back. Everything — including the deposit. That last transfer is the whole philosophy, visible on-chain.