Block has merged a Bitcoin Lightning Network payment specification into the x402 standard's repository, according to [The Defiant](https://thedefiant.io/news/infrastructure/block-adds-bitcoin-lightning-to-x402-standard). That's the whole announcement, and it's worth being precise about what it means: the spec merged. A Python implementation of it is still sitting in review, and hasn't been run against a real Lightning node yet.
That distinction is the story. x402 is the HTTP-402-based standard that lets a request carry its own payment — an agent hits an API, gets a 402, pays, gets the response, no subscription, no API key negotiation. It's become one of the default rails for agent-to-agent and agent-to-API payments this year, mostly settling in stablecoins over EVM chains through facilitators. Adding Lightning means x402 now has a spec for settling in Bitcoin over a payment-channel network instead of an account-based chain. Two very different trust and liquidity models, one request format.
What actually merged
Per the report, the Lightning payment spec is now part of x402's own repository — the protocol-level description of how a Lightning payment fits the 402 pattern. That's a real step: it means the standard's maintainers have a defined shape for a Lightning-settled request, not a fork or a side proposal.
What hasn't happened yet, per the same report: the Python implementation of that spec — the code an agent or a facilitator would actually run — is still awaiting code review and hasn't been tested against a real Lightning node. No production path exists today for an agent to pay over Lightning through x402. The spec describes the shape; nothing has proven the shape works against a live channel.
Why Lightning is a different kind of rail
Every other x402 lane in wide use settles on an account-based chain: a wallet holds a balance, a transaction moves it, the chain finalizes it. Lightning is a payment-channel network — value moves through a path of already-funded channels, settlement is near-instant and fees are small, but a payment can only route if there's live liquidity along that path. That's a different failure mode than a stablecoin transfer failing to confirm. A channel-routing failure isn't a chain congestion problem; it's a liquidity-topology problem, and it needs different monitoring and different facilitator logic to handle gracefully.
That's exactly the kind of thing real-node testing is supposed to surface before code like this reaches anything that moves real funds. A spec that looks clean on paper can still fail in ways that only show up when payments are actually routed through live channels with real liquidity constraints — stuck payments, partial routes, channels that closed since the last balance check. Merging the spec doesn't retire any of that; it just means the description everyone will build against is now fixed.
What to watch
Three things worth tracking from here: whether the Python implementation clears review and gets tested on a real node, whether any x402 facilitator actually adds Lightning as a settlement option once it does, and whether that changes what "agent-native payments" means beyond the stablecoin-on-EVM default that's dominated the standard so far. Until the implementation ships and gets proven against live infrastructure, this is a spec merge — not a new payment rail an agent can actually use.
### Sources - [Block Adds Bitcoin Lightning to x402 Standard — The Defiant](https://thedefiant.io/news/infrastructure/block-adds-bitcoin-lightning-to-x402-standard)