How we built non-custodial recurring billing on Base — 250 charges a second across 10 wallet shards.

Stripe has to hold your card. PayPal has to hold your account. Patreon has to hold both your money and your audience. The model that built modern internet payments is, at its core, a model where someone in the middle is always holding something that belongs to you.

DOLLA doesn't hold anything. Not the dollars, not the cards, not the relationship. When a follower commits to back a creator for one dollar a month, the money moves directly from the follower's wallet to the creator's wallet on the Base network — every month, automatically, with the follower's explicit on-chain permission and no platform standing in between as a middleman.

Building it was harder than I'd like to admit, and the parts that surprised me are the parts that don't usually show up in payments writing. Here's the honest field report.

The two-line problem

Recurring billing on the open internet has, until recently, required two compromises that everyone in the industry quietly accepted. First, somebody has to store the payment instrument — a card on file, a bank token, a saved wallet — because the user obviously isn't going to type their card in every month forever. Second, somebody has to push the button at billing time, which means somebody has to be authorized to move the user's money on the user's behalf without asking again.

Both of those compromises are why payment processors take two to four percent off the top, why creator platforms take eight to thirty percent on top of that, and why anyone building "peer-to-peer" anything at internet scale has historically had to become a money transmitter, an escrow agent, or a card-saving custodian. The middle is where the money is, and the middle is also where the regulation, the chargeback liability, and the trust burden live.

What changed is a quietly powerful primitive on the Base network called a spend permission. A spend permission is, in the simplest possible language, a signed promise that lives on chain — "this address may pull up to X dollars from my wallet every Ndays, until I revoke it, with no further signature required from me." The user signs once, in their own wallet, with their own keys. The signature is a normal Coinbase Smart Wallet signature — no special hardware, no seed phrase ceremony, just the same one-tap approval anyone with a Smart Wallet already knows. From that moment on, a designated charger address can move USDC from the user's wallet, but only within the cap, only on the cadence, and only until the user decides to walk away.

That's it. That's the whole thesis. The user retains custody of their own money for the entire life of the subscription, the platform never holds a token, the permission is revocable from the user's wallet at any time without our cooperation, and every charge settles peer-to-peer in stablecoin in under a second on a chain that costs fractions of a cent to move money on.

What surprised us when we built it

The version of this story that ends right there — "we used spend permissions, the end" — would be a great tweet but a misleading article. The honest version has three surprises in it.

Surprise one: nonces are the bottleneck, not the network.

A single Coinbase Smart Account can sign one transaction at a time, in strict sequence, because every transaction it sends consumes the next sequential nonce. If you have one subscription owner address pulling thousands of charges per billing cycle, every one of those charges has to wait its turn in a queue. The chain itself is fine — Base settles in two seconds and can absorb thousands of transactions per second across the network. The bottleneck is the single address sitting at the front of the line.

We solved this the boring way. We provisioned ten subscription owner wallets, each with its own address and its own nonce. Every new subscriber is deterministically routed to one of the ten using a fast hash of their user ID — a simple FNV-1a, modulo ten. The user signs the spend permission against whichever shard they were assigned, and the shard assignment is locked in at signature time so a future change to the shard count never affects existing subscribers. At billing time, ten worker processes run in parallel; each one pulls a batch of jobs from a Postgres queue, looks up which shard wallet to use, and fires off charges in its own nonce lane. The math is unromantic: ten lanes is roughly ten times the throughput. Our modeled ceiling is about 250 charges a second, which is enough to clear a million subscribers in well under an hour, which is more than we'll need in the foreseeable future and was straightforward to build.

Surprise two: Postgres is a queue, if you ask it nicely.

We do not run a dedicated job queue. We do not run Sidekiq. We do not run BullMQ. We run Postgres 17, the same database we use for everything else, and we use one feature of it called FOR UPDATE SKIP LOCKED. When a worker wants a batch of jobs, it asks Postgres for the next ten rows, locks them, and tells Postgres to skip any rows that another worker has already locked. Ten workers can run that query at the same instant and each one gets a disjoint slice of work. There is no race condition to manage, no broker to monitor, no second system to maintain. The queue is the database, and the database was already there.

This is a borrowed idea, not a new one — the technique has been quietly powering serious payment systems at companies like Lyft and Expedia for years. What's worth saying out loud is how much complexity it removed for us. A small team building on a clean stack should not be running a queue server in 2026 unless they have a specific reason. We didn't. We don't.

Surprise three: the gas math is constant.

The conventional wisdom about crypto-native business models is that they look great at small scale and fall apart when you try to model real volume, because gas costs scale unpredictably. So the first thing I did, before writing serious code, was build a sliders-everywhere economic model that lets you dial up users, premium conversion rates, operations per user, and the per-operation gas cost, and watch the gas-to-revenue ratio change.

What I expected was a curve — pleasant at low volume, painful at high volume, with a clear break-even point I'd need to hit before the business worked. What I actually got was a line that stays flat at roughly nine percent from a thousand users all the way out to ten million. The reason it stays flat is structurally simple in retrospect: the Coinbase Paymaster sponsors gas at a cost that scales linearly with users, and our revenue scales linearly with paying users, so the same denominator sits underneath both numerators. The ratio is what it is. The model has only one failure mode — very low premium conversion combined with heavy gas burn from free users — and that failure mode is visible on the slider before it becomes a problem, and fixable on the slider too: throttle free-user sponsorship at a budget cap.

You can move the sliders yourself. That's the part of the math investors should be able to verify, not take on faith.

What we are not doing, on purpose

A non-custodial billing system is a strict subset of what a regulated payment processor does, and being honest about the subset is part of being trustworthy. We do not hold money for our users. We do not move money on their behalf into accounts we control. We do not have the ability to claw back a charge unilaterally, and we do not have the ability to push a charge to a user who hasn't given us a fresh, current spend permission. The user is the custodian. The contract on chain is the rulebook. The platform's role is to coordinate and to publish — nothing more.

That subset is also the reason creators on DOLLA keep one hundred percent of every dollar a follower spends on them. We don't take a cut because there's no cut to take and no balance to clip from. The money never sits with us long enough to be sliced. Our revenue comes from people who choose to upgrade to a premium tier — a verified badge, an inner-circle weekly rate, a custom donation tool — and the majority of that revenue is committed to charitable causes through partnered nonprofits. The product was built to give, not to extract, and the architecture had to support that or the mission was a marketing claim.

Why this matters beyond a creator app

The same primitive that lets a follower back a creator for a dollar a month also lets a small business pay a vendor on recurring terms without handing over a card. It lets a nonprofit accept committed monthly giving without paying three percent to a processor. It lets a software company bill a customer for usage without becoming the custodian of the customer's payment method. The unlock isn't creator economics. The unlock is a generation of internet businesses that don't need to put themselves in the middle of every transaction in order to participate.

This is the part where I'm supposed to make a sweeping claim about how everything is going to change. I'm not going to. The realistic version is narrower and more useful: for any business where the value being exchanged is small enough that processor fees were already a meaningful drag, the spend-permission model removes the drag entirely. For everyone else, it's an option that didn't exist twelve months ago and exists now. Some businesses will adopt it. Many won't. The ones that do will look, structurally, more like cooperatives than like rent-extracting intermediaries, because the architecture won't allow them to be anything else.

That's the part I find genuinely exciting. The technology forces a particular shape of business, and the shape it forces is the shape we needed it to be all along.

Closing notes for the curious

Everything described in this piece is live in production at justadolla.com today. The first peer-to-peer USDC follow on Base mainnet is on chain and verifiable. The sharded charger and the Postgres queue are running every cycle. The economic model is publicly inspectable. The full architecture write-up, with smart-contract addresses and code references, lives at /breakdown.

If you're a journalist, an engineer, or an operator thinking about a similar problem, I'd genuinely like to hear from you. The honest stretch goal of this entire project is to make a few of the trade-offs that the payments industry has accepted as permanent feel suddenly negotiable, and the only way that happens is if other builders look at what works and decide they want to try it themselves.

Evan Estremera is the founder of DOLLA, a creator economy built on Base where every dollar a follower spends reaches the creator and the majority of platform revenue is committed to charitable causes. DOLLA is a venture of Kingdom Portfolios LLC, a faith-led parent company; the product itself is built for creators of every background, faith, and walk of life. He can be reached at affluenceer [at] gmail.