L402 vs x402: Two Rails for the Machine Economy, Compared
Two answers to the same question
Both L402 and x402 answer the same HTTP status code: 402 Payment Required. A machine asks for a resource, the server says pay first, the machine pays, and the server hands over the resource. No accounts, no API keys, no human in the loop. That shared shape is why the two get compared so often.
The difference is what happens underneath. L402 settles over the Lightning Network in bitcoin. x402 settles USDC on an EVM chain, usually Base, through a facilitator. We built both rails at bolthub and measured them against the workload we actually care about. This post is the honest write-up.
How each rail works
L402 pairs an HTTP 402 with a Lightning invoice and a macaroon. The invoice is the charge. The macaroon is a capability-scoped token that proves payment and grants access. The buyer pays the invoice over Lightning, presents the preimage as proof, and the server lets them in. Settlement is off-chain: the payment hops across Lightning channels and lands in your wallet in well under a second.
x402 pairs an HTTP 402 with a set of payment requirements: an asset (USDC), a chain (Base), an amount, and a facilitator URL. The buyer signs an EIP-3009 authorization, the facilitator submits it on-chain and pays the gas, and once the transfer confirms the server grants access. Settlement is on-chain: a real transaction, mined into a block.
Same envelope. Very different plumbing.
The comparison
| Property | L402 (Lightning) | x402 (USDC on Base) |
|---|---|---|
| Settlement | Off-chain, Lightning | On-chain, EVM |
| Unit of account | Bitcoin (sats) | US dollars (USDC) |
| Cost per payment | A fraction of a sat to a few sats | Gas per settlement, plus any facilitator fee |
| Smallest viable payment | About 1 sat (≈ $0.001) | Bounded by gas, effectively cents |
| Settlement latency | Sub-second | Seconds (submit and confirm) |
| Custody | Non-custodial, buyer to your wallet | Non-custodial, buyer to your address |
| Operating requirement | A Lightning node with liquidity | An EVM address |
| Volatility exposure | Bitcoin price | None (dollar-pegged) |
Where x402 genuinely wins
x402 is a real, well-designed rail, and it has advantages we take seriously.
- •Dollar accounting. USDC is pegged to the dollar, so a receiver prices and books revenue in dollars with no bitcoin volatility to hedge. For a business that thinks in USD, that is a genuine convenience.
- •No node to run. You settle to an EVM address. There is no channel liquidity to manage and nothing to keep online. Your wallet is a keypair.
- •EVM-native reach. If your buyers already hold stablecoins in EVM wallets, x402 meets them where they are, on top of deep stablecoin liquidity.
- •Larger payments. When a single payment is a dollar or more, on-chain gas is a rounding error. At that size the economics stop mattering.
If your payments are dollars rather than fractions of a cent, x402 is a reasonable choice. We are not here to strawman it.
Where Lightning wins for micropayments
The catch is the size of the payment. bolthub exists for the machine economy, where an agent pays per tool call, per API request, per kilobyte. Those payments are tiny and constant. Card networks cannot go below about $0.50. A sat is about $0.001, roughly 500× below the card floor. That is the regime we design for, and it is where the two rails diverge sharply.
Here is the core of it. On-chain gas is a roughly fixed cost per settlement. It does not shrink when your payment shrinks. So when the payment is $0.001 and the settlement costs even a fraction of a cent, the fee is a large share of the payment, sometimes larger than the payment itself. Batching can amortize gas, but batching means holding balances, adding a custodian or a contract, and giving up the per-call finality that made the rail simple in the first place.
Lightning fees work the other way. A routing fee is a small base plus a proportional part measured in parts per million. For a sub-cent payment that is a fraction of a sat. The fee scales down with the payment instead of sitting on top of it as a fixed floor.
- •A fee that scales with the payment. Proportional routing fees stay tiny as the payment gets tiny, so the rail stays viable all the way down.
- •Sub-second finality. There is no block to wait for, which matters when the payment gates a single response an agent is blocked on.
- •True sub-cent payments. One sat is economical. That makes per-KB, metered, and token-bucket pricing practical, which a cents-floored rail cannot express.
The honest catch on the Lightning side
Lightning's advantage comes with a real cost: you need a Lightning node with inbound liquidity, and it has to stay online. A phone wallet will not do, because buyers pay you while you sleep and your invoicing wallet has to be up 24/7. Running a node means channels, liquidity, and uptime. That is the genuine tax on the Lightning side, and it is exactly the thing x402 lets you skip.
We think that tax is worth paying for the economics, and we spend a lot of effort making it small. That is what our Node Launcher is for, and it is the subject of the companion post.
Our take
For dollar-sized, EVM-native payments, x402 is defensible. For the sub-cent, high-frequency, pay-per-call traffic that agents actually generate, Lightning is cheaper and faster, and the gap widens the smaller the payment gets. bolthub is built for the small end, so we build on Lightning.
The next post covers the other half of the decision: the node requirement, and how we make it painless.