Why on-chain recurring payments are broken — and how we fixed it.
Six months ago I didn't know Solidity. I had a day job in Switzerland, evenings and weekends, and a problem I couldn't stop thinking about: why is it still impossible to accept a recurring crypto payment without building custom infrastructure from scratch?
Stripe solved this for fiat in 2011. It's 2026. The stablecoin economy is real — Circle just reported $250B in USDC circulation, Meta is routing $3B a year in creator payouts through USDC. And yet if you're a SaaS founder who wants to accept monthly USDC subscriptions from your users, you have two options: build it yourself, or don't.
I chose a third option. I built AuthOnce. Here's what I learned along the way — and why the architecture of recurring payments matters more than most people realise.
The fundamental problem with push payments
Every crypto payment you've ever made is a push payment. You initiate it. You sign a transaction. You send. That's the entire model — and it works perfectly for one-time payments.
Subscriptions are pull payments. The merchant initiates the charge on a schedule. The customer doesn't need to do anything after the initial setup. This is how Stripe, your bank, your electricity company — every recurring billing system in the world — operates.
Blockchain, by design, doesn't have a native pull mechanism. Wallets can't be charged without the owner's active participation. This creates an enormous gap: the entire recurring revenue model of the modern software economy simply doesn't exist on-chain.
"The entire recurring revenue model of the modern software economy simply doesn't exist on-chain."
Every protocol that's tried to solve this has made the same mistake: they ask subscribers to lock funds into a custodial vault upfront. The protocol holds your money and releases it to merchants on schedule. It works — until it doesn't. Until a contract gets exploited. Until a regulatory change makes custody legally untenable. Until a merchant goes rogue and the protocol can't distinguish a legitimate charge from theft.
The custody trap
Here's what most on-chain subscription protocols get wrong. They require the subscriber to:
- Deposit funds into a protocol vault
- Trust the protocol with custody
- Wait for funds to be released
- Expose funds to smart contract risk
- Create regulatory liability for the protocol
- Sign a permit once, off-chain
- Funds stay in subscriber's wallet
- Protocol pulls exact amount per cycle
- No custody, no lock-up, no vault
- Non-custodial by design
The custody model isn't just technically inferior — it creates legal exposure. In most jurisdictions, holding customer funds on behalf of a merchant makes you a payment institution. You need licences. You need compliance infrastructure. You need a legal team.
AuthOnce never holds funds. Not for a millisecond. Every payment is a single atomic transaction: subscriber wallet → merchant wallet. The protocol collects its 0.5% fee in the same transaction. Done.
EIP-2612: the primitive that makes this possible
The technical foundation of AuthOnce is EIP-2612 — a permit standard that allows token holders to authorise a spending allowance via an off-chain signature, without an on-chain approval transaction.
In plain English: a subscriber signs a message in their wallet once. No gas. No transaction. No blockchain interaction at all. That signed message is stored by our keeper infrastructure. On each billing date, the keeper presents the permit on-chain and pulls exactly the subscription amount directly from the subscriber's wallet to the merchant's wallet.
// What happens on every billing cycle
function executePull(uint256 subscriptionId) external {
Subscription storage sub = subscriptions[subscriptionId];
// Verify permit and pull exact amount, atomically
IERC20Permit(sub.token).transferFrom(
sub.subscriber,
sub.merchant,
sub.amount
);
// Protocol fee: 0.5%, hardcoded, immutable
uint256 fee = (sub.amount * 50) / 10000;
IERC20(sub.token).transferFrom(sub.subscriber, treasury, fee);
sub.lastPull = block.timestamp;
sub.pullCount++;
}The subscriber's funds never leave their wallet until the exact moment a payment is due. If they revoke the permit, payments stop immediately. If their balance drops below the subscription amount, the payment fails gracefully and the grace period begins.
The grace period problem nobody talks about
Failed payments are the silent killer of subscription businesses. In traditional SaaS, Stripe reports that involuntary churn — customers who leave because their card failed, not because they wanted to cancel — accounts for up to 40% of total churn for some businesses.
On-chain, this problem is worse. A wallet might be temporarily underfunded. A permit might expire. Network conditions might cause a transaction to fail. Without a recovery mechanism, a single failed payment means a lost subscriber.
AuthOnce has a programmable grace period built directly into the protocol. When a payment fails, the subscription enters a grace state. The keeper retries daily for up to 30 days — configurable per subscription. During the grace period, the subscriber's access isn't revoked immediately. They get a window to top up their wallet. Most of them do.
This isn't a product feature. It's a designed behaviour of the smart contract itself, enforced on-chain, not by a backend system that can fail or be changed.
Why the fee is hardcoded at 0.5%
Stripe charges 2.9% + €0.30 per transaction. For a €10/month subscription, that's €3.48 per year in fees — 29% of the subscription value going to payment infrastructure.
AuthOnce charges 0.5%. Hardcoded. Immutable. The same for every merchant, every token, every transaction size.
I made this a constant in the smart contract deliberately. Not a parameter an admin can change. Not a fee that scales with volume tiers. A constant. Merchants building on AuthOnce can build their pricing models knowing the infrastructure cost will never change without them seeing it coming.
The protocol fee is set at 50 basis points in the contract. There is a hard ceiling of 200 basis points that can never be exceeded — enforced in the code, not in a terms of service document.
Stripe cannot offer this guarantee. No traditional payment processor can. We can, because the rule is in the contract, not in a policy.
The creator economy angle
While I was building this, Meta announced it would route $3B per year in creator payouts through USDC across 160+ countries. Millions of creators are about to receive stablecoins as their primary income.
Those creators need somewhere to spend it. Not through a CEX. Not through a fiat off-ramp. Directly — on the SaaS tools, AI subscriptions, and professional services they use every day.
AuthOnce is the spending layer for the creator economy. A creator holding USDC can subscribe to any merchant on AuthOnce with a single permit signature. The merchant gets reliable, predictable recurring revenue in stablecoins, settled instantly, with no chargebacks.
Where we are
AuthOnce is live on Base Sepolia. Both smart contracts — SubscriptionVault and MerchantRegistry — are deployed and running. The keeper bot processes test subscriptions 24/7. The merchant dashboard is live. The subscriber portal is live.
Mainnet launch is Q3 2026. We're currently accepting applications from founding merchants — the first 10 approved get 0% protocol fees for 3 months.
If you're building a SaaS product, a creator platform, or any business that runs on recurring revenue and wants to accept stablecoins — apply to be a founding merchant.
Questions or feedback? Find me on X at @VascoBuilds or email vasco@authonce.io.
Ready to accept USDC subscriptions?
Join the waitlist. First 10 merchants pay zero protocol fee for 3 months.
Apply as founding merchant →