How protocols are billing in 2026 (and why it's not what you think)

Three years ago, the protocol playbook for revenue was: launch a token, capture fees in the token, use the token as the unit of governance and rewards. The financial model was elegant. The unit economics were chaotic. The regulatory exposure was unbounded.

In 2026, more and more protocols are doing something quieter and weirder: they bill their users in USDC, route the revenue to a multisig, and don't issue a token at all. The shift is happening across DeFi, infrastructure, and AI inference, and it's almost certainly under-covered — because it isn't photogenic. We thought it was worth writing about.

Three patterns we keep seeing

Pattern A: protocol earns fees in the rail asset (ETH on Ethereum, USDC if the product priced in dollars), splits between contributors and treasury, no token. It's the cleanest fit for RPC and indexer providers that already earn fees in the rail asset.

Pattern B: protocol earns fees in USDC, settles to merchant wallets directly via non-custodial billing, no central treasury. The "protocol" is more like a coordination layer than an entity that holds revenue. Common pattern in AI inference and oracle networks.

Pattern C: protocol issues a token but bills B2B customers (enterprise tier, API users) in USDC. The token is there for governance and incentives; the actual cash flow is in stablecoin. This is the hybrid path most legacy DeFi protocols are landing on.

All three skip the "we run a chain-wide fee splitter contract that distributes proceeds via tokenomics" model. All three are growing as a share of the protocol-revenue surface.

Why the shift

One: token-as-revenue-vehicle invites securities scrutiny that USDC-as-revenue-vehicle doesn't. Protocols that bill in USDC look like SaaS companies. Protocols that bill in a token they issued look like securities issuers. The legal advisors got more conservative over the last 24 months and the engineering teams listened.

Two: contributors want to be paid in something they can pay rent with. A protocol that earns in USDC and pays contributors in USDC has a tractable payroll problem. A protocol that earns in its native token has a "what does this volatility do to the team's runway" problem.

Three: treasury accounting is brutal when the unit of revenue and the unit of expense don't match. USDC in, USDC out is one cell in a spreadsheet. Token in, USDC out — through a DEX, with slippage, on a weekly cycle — is a quarterly audit pain point.

The infrastructure pattern

Protocols billing in USDC fall into two camps when you look at how the money moves:

• DIY: the protocol team writes their own permit-based pull contracts, runs their own renewal cron, hosts their own dashboard, deals with their own dunning. Fine for protocols where billing is a small fraction of the surface area. Expensive in engineering time for everyone else.
• Non-custodial billing rail: the protocol team uses a processor like OpenSettle as the billing layer, with the protocol's own settlement wallet on the receiving end. The processor handles permits, retries, reconciliation, webhooks. The protocol team focuses on the protocol.

Both work. The DIY path is more common at the very-early stage where the team has more engineering hours than billing complexity. The processor path becomes attractive as soon as the protocol crosses ~$10K MRR or has a second product that needs billing.

Why non-custodial matters specifically here

A protocol that uses a custodial processor for its USDC billing inherits the custodial properties of the processor. That means: a hold window, a payout schedule, an external entity holding the revenue, and a regulatory framing where the processor (not the protocol) is the legal recipient of customer funds at the moment of settlement.

For a protocol building toward the "no central entity" thesis, that framing is exactly wrong. The whole point of "the protocol earns revenue" is that the protocol — not a centralized custodian — is the legal endpoint.

Non-custodial settlement preserves this. USDC moves from the customer's wallet to the protocol's settlement wallet (which can be a multisig, a Safe, an L1 contract address — anything). The processor never holds. The legal frame stays clean. The protocol can describe itself as the recipient of revenue without that being a polite fiction.

The honest part

Not every protocol should go non-custodial-USDC. If your protocol is a consumer product with a million users paying $1 in micropayments, the fee economics of any per-transaction billing layer will eat you alive — you want a token, or subscriptions, or both. If your protocol is selling enterprise API access to a dozen customers for five figures each, non-custodial-USDC is exactly the right rail.

The general direction of travel is clear. Protocols earning meaningful B2B revenue are increasingly billing in stablecoins, routing to self-custodied wallets, and skipping the token-as-revenue-vehicle path entirely. The infrastructure to do this didn't exist three years ago. It exists now. And the protocols that adopt it early get the legal clarity, the accounting simplicity, and the brand signal of being honest about how the money moves. If that's the direction you're heading, the docs and the pricing page are the right places to start.