Bitcoin Lightning x402: Block joined the standard, and the spec makes the seller run a node

What Block announced on September 24, 2026

On Thursday, Block — the company behind Square, Cash App, Afterpay and the Bitkey wallet — announced it had joined the x402 Foundation, the Linux Foundation–hosted body that governs x402, the open standard that puts a payment inside an HTTP request. The post, signed by Steve Reis, Head of Product for the Block Financial Platform, came with a contribution attached: Bitcoin Lightning payments in x402.

Block framed the move as the next step in open agentic work it had already done. It open-sourced goose, its AI agent; it helped launch the Agentic AI Foundation; and it joined the Universal Commerce Protocol to bring agentic commerce to small businesses. The announcement lists three benefits: sellers reaching "new buyers and their agents", agents paying through a standard rather than bespoke plumbing, and "Bitcoin as everyday money".

Steve Lee, who leads Spiral, Block's open-source Bitcoin development team, made the case for the rail: "Agents will make billions of small payments, and those payments need rails that are instant, low-cost, and open to anyone. That's exactly what Lightning was built for." Erik Reppel, who created x402 and sits on the Foundation's Technical Steering Committee, welcomed it as proof of the design: "x402 was designed to be open and extensible. Any network should be able to plug in and any developer should be able to build on it."

What the announcement does not contain is a date for any Block product. The roadmap is three lines: keep contributing to Lightning support, take part in the Foundation's working groups, keep building open agentic-commerce tools. There is no timetable for Square, Cash App or Bitkey. If you're a Square seller expecting agents to pay you through your existing dashboard next month, nothing in this release says that will happen.

What the Bitcoin Lightning x402 spec actually says

The contribution landed in the x402 repository on September 23 as scheme_exact_lnbtc.md — a 760-line specification first proposed in July. Press coverage summarised it as "Lightning support". The document itself is where support turns into obligations, so it's worth reading the flow directly:

1. The seller's server creates a fresh BOLT11 invoice for every payment challenge and returns it inside the 402 response. An invoice can never be reused across clients or challenges.
2. The invoice commits to a hash of the exact request — method, URL and body for HTTP, or the tool call for MCP — so a payment for one request can't be replayed against another.
3. The agent pays the invoice over Lightning and sends back the preimage, the 32-byte secret that only becomes available once the payment has settled.
4. A facilitator checks the proof: that the preimage hashes to the invoice's payment hash, that the invoice was signed by the seller's node key, and that the hash hasn't been used before. It records the hash in a durable replay store. It never needs access to the seller's node.
5. Only then does the server run the request.

It's elegant cryptography, and it isn't new territory: Lightning's hash-and-preimage design has powered HTTP 402 paywalls for years, most visibly in Lightning Labs' L402 protocol. The x402 version inherits that property cleanly. It also inherits the limits. The scheme supports only exact pricing with an upfront flow — no metered upto payments, no sessions — and the asset must be BTC.

Five things the Lightning scheme asks of the seller

Every x402 announcement this year has been written for the developer building the buyer. Read this one from the other side of the request — as the business that has to receive the money — and five requirements stand out.

1. You price in satoshis, and your revenue floats

The wire amount is an integer number of millisatoshis. The spec goes further than most: user-facing SDKs must use explicit satoshi amounts by default, and prices written as $1 or 1 USD must be rejected unless the application registers its own conversion parser. A dollar price is therefore your problem to build and maintain. Either you set a price in sats and accept that your dollar revenue per call moves with the Bitcoin price, or you re-quote every invoice from a price feed you trust. Your cloud bill and your payroll are still in dollars.

2. You need a Lightning node that only you can invoice from

The payTo field is not a wallet address — it's the public key of the receiver node that signs your invoices. The spec requires the seller's server to have exclusive invoice-issuance authority for that key, and it spells out why: on a shared custodial node, one tenant could pay its own invoice and replay the preimage against another tenant's payment requirement. In the spec's words, "a shared custodial node is not compatible."

So a hosted Lightning account shared with other customers doesn't qualify. You need your own node, or a dedicated one somebody runs for you. We'll note, with some satisfaction, that the standard's own security model rules out the pooled custodial wallet — the same conclusion we reach about merchant payments in general in why a payment processor shouldn't hold your money.

3. Your node must be online, liquid and protected

A Lightning node can only receive if it's online and has inbound channel capacity — someone else's liquidity pointed at you. Neither is a problem for a team that already runs Lightning. Both are new operational work for a team that runs an API. The spec adds a third item: fresh invoices "consume receiver node resources", so servers should rate-limit or authorise invoice issuance. An unauthenticated flood of requests to a paid endpoint becomes load on the node that holds your money.

4. There's no refund path

The scheme "provides no refund path; any refund is a separate arrangement with the receiver", and an overpayment grants no extra credit. To be fair, that's also true of USDC settlement — it's the finality that makes chargebacks impossible, and we consider it a feature. But it means the case "the agent paid, then my upstream failed" needs a written policy, whichever rail you choose.

5. You won't know who paid

This is the requirement most sellers will miss. Lightning routing gives no stable payer identity, so the spec says facilitators must omit the payer from the settlement response. On EVM networks, the core x402 settlement response includes the paying address.

That address is how you — and every auditor of this market — tell real demand from noise. The independent x402 studies published this month separated genuine agent buyers from self-payments and single-payer volume precisely by looking at payer addresses; we walked through one of them in the first x402 audit. On Lightning, that analysis isn't available from the settlement data. Privacy is a real benefit for buyers. For a seller trying to count distinct customers, it's a blind spot.

The standard is network-agnostic. The buyers are not asset-agnostic.

Lightning is not an outlier. x402's exact scheme now has specifications for 17 network families — EVM chains, Solana, Stellar, the XRP Ledger, Cardano, Sui, Aptos, NEAR, TON, Hedera, Algorand, Starknet, Casper, Canton, Concordium, Keeta and now Lightning — alongside separate schemes for metered, auth-capture and batch settlement. The Foundation is doing exactly what Reppel described: letting any network plug in.

The chains that carry the traffic move quickly. On September 22, Solana's official account said it had handled 76% of all x402 transactions in the previous four weeks — 23.2 million, against 3.39 million for the next network — after passing Base in daily counts in late August. A day earlier, the Cardano Foundation said Cardano had been added to the official x402 SDK, so far with a test transaction only.

The asset does not move. Circle's second-quarter 2026 results put it plainly: 99.3% of x402 agent-payment volume settles in USDC. Agents are run by businesses that budget in dollars; sellers price in dollars; a stablecoin makes the per-call price a number you can put in a spreadsheet without a footnote. Even Block's own announcement talks about "investing in stablecoin and Bitcoin payments", not one instead of the other.

That's the frame for reading September 24. A new asset option widens the standard. It doesn't change the default — and a seller should adopt a non-default rail only when there's a reason specific to their business.

Who should actually test Lightning x402

There are sellers for whom this release is genuinely good news:

• You already run a Lightning node for your business, with inbound liquidity and someone who looks after it. Adding x402 is incremental work, not a new discipline.
• You want BTC on your balance sheet and are comfortable with dollar revenue per call floating with the price.
• Your buyers are Bitcoin-native — agents built on Lightning wallets and tooling — or payer privacy is part of what you sell.

For everyone else — most data APIs, MCP servers, inference endpoints and niche B2B services — Lightning x402 adds a node, a treasury decision and a measurement blind spot in order to reach buyers who pay in something other than USDC — 0.7% of x402 volume in Circle's second-quarter count. It may grow. It is worth watching. It is not the place to start.

Where Payzum fits — and where it doesn't

Payzum's x402 product is built for the default case, and we want to be exact about the role. Payzum is the middleware — a proxy that sits in front of your existing API. Payzum is not the facilitator. Settlement runs through an external facilitator (today, Coinbase's).

• You configure three things in a dashboard: your existing endpoint URL, your API key or bearer token, and a price. No SDK, no 402 handling, no wallet library in your codebase.
• Payzum publishes an x402 URL, returns the 402 with the payment requirements, settles through the external facilitator, then proxies the paid call to your real endpoint with your key.
• You're paid in USDC on Base, to a wallet you control. Non-custodial: there's no Payzum balance and no payout schedule. The payment is the settlement, typically confirmed in about two seconds.
• Your price is in dollars, because the asset is a dollar. Every payment is an on-chain USDC transfer on Base, so the paying address is on the public record — the raw material for counting distinct buyers.
• Pricing: roughly the first 1,000 transactions a month are free, then about $0.001 per transaction plus gas.

The honest boundary:

• Payzum does not support Lightning x402. Our agentic product is x402 per call, in USDC on Base.
• Payzum is not an x402 facilitator. Becoming one is a future goal, not a claim about today.
• No metered upto payments, sessions or channels. One request, one price, one settlement.
• Crypto-only. We accept crypto and settle in crypto, with optional auto-conversion to USDC or USDT. We don't settle to bank accounts.
• Bitcoin is supported for ordinary payments. If you want to take BTC from human customers — payment links, hosted checkout, invoices or the point of sale — Payzum accepts on-chain Bitcoin today, alongside Ethereum, Solana, Polygon, Base, Arbitrum, Optimism, BNB Chain and Avalanche.
• We have no commercial relationship with Block or Circle. We write about their releases because they matter to the sellers we serve.

How to become payable by agents this week, step by step

1. Pick one endpoint. The one with a clear unit of value — a lookup, a scrape, a score, a generation. Price it in one sentence, in dollars.
2. Own the destination wallet. Create or connect the address where USDC on Base should land, and turn on 2FA. That address is your account; everything downstream inherits its custody model.
3. Configure the proxy. In the Payzum dashboard: endpoint, API key or bearer, price per call. Payzum publishes the x402 URL — see how it works on the x402 page.
4. Test it like an agent would. Call the URL, receive the 402, pay, retry, and check the proxied response matches your origin. Signed webhooks wire each payment into the systems you already run.
5. Measure for a month. Track distinct paying addresses and revenue per payer. If those numbers move and your buyers turn out to be Bitcoin-native, that's the moment to cost out a Lightning node — with data instead of a press release.

Who this is for, concretely

• A data or scraping API whose human users sign up, burn the free tier and leave. Agents pay per call with no signup and no card — the economics are in x402 vs API-key billing.
• An MCP server that assistants already call and that earns nothing. Charging per tool call is the same configuration as charging per API call; see monetising an MCP server with x402.
• A Bitcoin-native service that already runs Lightning. You may well add Lightning x402 — and still want a USDC endpoint for the 99% of agent volume that arrives in dollars.

Lightning x402 vs USDC x402 via Payzum — what a seller is choosing

Common objections

"Bitcoin is the most open network. Shouldn't I support it on principle?"

Openness at the protocol level is real, and x402 is better for having Lightning in it. But a seller's question is narrower: what does it cost me to receive on this rail, and who will pay me on it? Today the cost is a node and a floating price, and the payers are overwhelmingly in USDC. Support it when your buyers ask for it — the standard will still be open.

"Lightning fees are tiny."

They are, and under this spec the payer covers routing fees on top of the invoice amount. But fees were never the seller's problem on either rail: at API-call sizes, USDC settlement on Base costs fractions of a cent too. The seller-side cost that matters is operational — running the node — and financial — holding the asset. Neither shows up in a fee comparison.

"Won't Square eventually bring this to every seller?"

Possibly — Block has the merchant base to make that meaningful. But nothing has been announced, and when something is, read the custody model before the fee schedule: where the sats land, who holds them, and when you can move them. The spec's own rule against shared custodial nodes suggests the answer matters.