From Keysend to Xkeysend: Lightning's Spontaneous Payment Protocol Upgrade

Core Lightning v26.06 deprecated the keysend command and introduced xkeysend as its replacement. The change is part of a broader overhaul that also replaced pay with xpay and getroute with getroutes, all built on a new routing engine called askrene. For wallets and services that rely on spontaneous payments (sending sats without the recipient generating an invoice first), this migration has real consequences: keysend is scheduled for removal in v27.03, and any application still calling the old RPC will break.

This article explains how keysend works, what its limitations are, what xkeysend changes, and how the broader landscape of invoice-less Lightning payments is evolving alongside BOLT12 offers and AMP.

What Are Spontaneous Payments?

Standard Lightning payments follow a pull model: the recipient creates an invoice containing a payment hash, the sender finds a route and locks HTLCs along that route, and the recipient reveals a preimage to claim the funds. The invoice is what makes this work: it commits both parties to a specific payment hash before any sats move.

Spontaneous payments flip this. The sender pushes sats to a destination node without any prior communication. There is no invoice exchange, no QR code to scan, no LNURL endpoint to query. All the sender needs is the recipient's node public key. This makes spontaneous payments useful for tipping, donations, streaming micropayments, and any context where asking the recipient to generate an invoice first would add friction or be impossible.

The tradeoff: Spontaneous payments sacrifice the cryptographic receipt that invoice-based payments provide. Since the sender creates the preimage, holding it does not prove the recipient was paid. For merchant payments where proof of payment matters, invoices (BOLT 11 or BOLT 12) remain the better tool.

How Keysend Works Under the Hood

Keysend was first implemented experimentally in LND v0.9 (2020) and later documented in bLIP-0003, a community specification written by Valentine Wallace. It was never incorporated into the core BOLT specifications, but became a de facto standard adopted by all major implementations.

The mechanism is straightforward. The sender generates a fresh, cryptographically random 32-byte preimage. It computes the SHA-256 hash of that preimage and uses it as the payment_hash in the update_add_htlc message. The preimage itself is placed inside the encrypted onion payload destined for the final hop, using TLV type 5482373484. When the recipient decrypts the onion, it finds the preimage, verifies it matches the payment hash, and settles the HTLC.

Nodes advertise keysend support using feature bit 55. A sender should check for this bit before attempting a keysend; otherwise, the recipient will reject the payment with an incorrect_or_unknown_payment_details error because it has no matching invoice to look up.

The Preimage Problem

In a normal invoice-based payment, the recipient generates the preimage and commits to its hash in the invoice. When the sender receives the preimage back (after the payment settles), it serves as cryptographic proof: only the invoice creator could have revealed it. Combined with the signed invoice, this constitutes a verifiable receipt.

Keysend inverts this. The sender creates the preimage, so possessing it proves nothing about whether the recipient actually received funds. A dishonest sender could claim to have paid by presenting a preimage it generated itself. The recipient also has no way to verify that the preimage is unique: in theory, a sender could reuse preimages across payments, although bLIP-0003 explicitly instructs senders to never reuse them.

This lack of proof of payment makes keysend unsuitable for commercial transactions where disputes might arise. It works well for tips and donations where the trust model is simpler: the sender wants to give money, and whether they can prove it later is secondary.

Why Core Lightning Deprecated Keysend

The deprecation of keysend was not about the wire protocol. The on-the-wire behavior of xkeysend is identical: it still uses TLV type 5482373484, still generates a sender-side preimage, and still requires feature bit 55 on the receiving node. What changed is entirely on the sender side: how routes are computed, how failures are handled, and how the command fits into Core Lightning's new payment architecture.

The legacy keysend (and pay) commands used a Dijkstra-based pathfinding algorithm that treated each payment attempt independently. It had no memory of previous failures, no way to split payments across multiple paths intelligently, and limited ability to optimize for both fees and success probability simultaneously.

Core Lightning's new payment stack, built around xpay and askrene, replaces this with a minimum-cost flow (MCF) solver based on the Pickhardt-Richter research. This solver treats the entire Lightning graph as a flow network and computes the optimal way to split a payment across multiple channels simultaneously, balancing success probability against routing fees.

What xkeysend Changes

The xkeysend command accepts a 33-byte hex node ID as the destination and an amount in millisatoshis. Its full synopsis is: xkeysend destination amount_msat [label] [maxfee] [layers] [retry_for] [maxdelay] [extratlvs]. The official documentation confirms it was added in v26.06.

Askrene-Powered Routing

The most significant change is under the hood. Where the old keysend called getroute for a single path, xkeysend delegates to askrene, which models channel liquidity as probability distributions and solves for the minimum-cost flow across the entire graph. The solver assigns a cost function that blends success probability and fees, controlled by an internal parameter that can weight one over the other.

Crucially, askrene learns from each payment attempt. When a route fails at a specific hop, askrene updates its internal model of that channel's available liquidity and uses that information for subsequent attempts. This feedback loop makes retries progressively smarter rather than randomly trying different paths. The solver also penalizes longer routes with a per-hop failure probability (roughly 1% per additional hop), naturally preferring shorter paths when fees are comparable.

The layers parameter lets advanced users overlay custom constraints on askrene's routing decisions, such as excluding specific channels or adjusting capacity assumptions. The retry_for parameter replaces the old fixed retry count with a time-based window: xkeysend will keep attempting routes for the specified duration before giving up.

The Migration Timeline

Core Lightning follows a deprecation cycle where commands are marked deprecated in one release and removed two releases later. The deprecated features page lists the following schedule:

• v26.06: keysend, pay, and getroute are deprecated. Calling them produces a warning but still works.
• v27.03: these commands are removed entirely. Applications must use xkeysend, xpay, and getroutes instead.

Developers running Core Lightning should begin migrating now. The wire protocol is unchanged, so the migration is purely an API-level change: update your RPC calls and adjust parameter names. The v26.06 release post from Blockstream recommends that developers move their applications to xkeysend, xpay, listpays, and getroutes.

Important for LND and LDK users: This deprecation is specific to Core Lightning. LND, Eclair, and LDK have their own keysend implementations that remain active. However, the broader trend toward better routing engines and BOLT12 means all implementations are evolving away from the original keysend design.

Who Depends on Keysend Today

Keysend's simplicity made it the default choice for several important Lightning use cases. Any application that sends sats without first requesting an invoice from the recipient likely uses keysend or a keysend-derived protocol.

Nostr Zaps

Nostr zaps use LNURL and NIP-57 to coordinate Lightning payments between Nostr clients and wallets. While the zap flow itself uses BOLT 11 invoices (the LNURL server generates one), many Nostr wallets also support direct keysend payments to node keys published in user profiles. The shift to Nostr Wallet Connect (NIP-47) is reducing direct keysend usage in the Nostr ecosystem, but keysend remains a fallback for clients that want to tip without an LNURL endpoint.

Podcasting 2.0 and Value4Value

The Podcasting 2.0 ecosystem built its streaming payment infrastructure on keysend. Apps like Fountain and Podverse use keysend to stream satoshis to podcast hosts per minute of listening, with custom TLV records (type 7629169) carrying metadata about which podcast, episode, and timestamp the payment corresponds to. This is perhaps the most keysend-dependent use case in the Lightning ecosystem.

The migration path for these apps is straightforward on Core Lightning: replace keysend calls with xkeysend and update parameter handling. The extratlvs parameter works the same way in both commands, so custom TLV metadata for podcast streaming payments transfers directly.

General Tipping and Donations

Services like Stacker News and various Lightning-powered tip bots use keysend for one-off payments where the simplicity of a push model outweighs the lack of proof of payment. These applications typically use LND rather than Core Lightning, so they are not directly affected by the deprecation timeline, but should plan for the eventual ecosystem-wide shift toward BOLT12 offers or Nostr-based payment flows.

Alternative Approaches to Invoice-Less Payments

Keysend and xkeysend are not the only ways to send Lightning payments without a traditional invoice. Two other protocols address the same problem with different tradeoffs: Atomic Multi-Path Payments (AMP) and BOLT12 offers.

AMP: Multipath Spontaneous Payments

AMP, specified in LND's documentation, extends the spontaneous payment concept to multiple paths. Instead of sending a single preimage, the sender generates a root secret and splits it into per-shard shares using XOR. The recipient can only reconstruct the root secret (and thus claim the payment) once all shards arrive. This makes AMP payments atomic: they settle in full or not at all.

AMP's main advantage over keysend is that it can exceed any single channel's capacity by splitting across multiple routes. Its main limitation is that it remains an LND-only feature: Core Lightning, Eclair, and LDK support base MPP and keysend but have not implemented AMP.

BOLT12 Offers: The Specification-Level Solution

BOLT12 takes a fundamentally different approach. Instead of pushing sats without any prior exchange, a recipient publishes a static offer (a reusable payment code). When a sender wants to pay, their node uses onion messages to request a fresh invoice from the recipient's node. That invoice has a unique payment hash, restoring the proof-of-payment guarantee that keysend lacks.

BOLT12 was formally merged into the Lightning specification in September 2024. By mid-2026, Core Lightning, Eclair, and LDK support it in production. LND, the most widely deployed implementation, does not yet have native BOLT12 support, though third-party plugins exist. BOLT12 also supports blinded paths, which hide the recipient's node identity and channel structure from the sender, offering a significant privacy improvement over keysend (which requires knowing the recipient's public node key).

Wallet and Implementation Support

The practical impact of the keysend-to-xkeysend migration depends on which Lightning implementation a wallet or service runs. The following table summarizes spontaneous payment support across implementations as of late 2026.

Wallets built on LND (such as ZEUS) are unaffected by Core Lightning's deprecation cycle. However, wallets built on CLN or using CLN as a backend need to update their RPC calls before v27.03. The wire protocol is identical, so a keysend sent from an xkeysend-powered CLN node arrives at an LND node exactly the same way a legacy keysend would.

What This Means for Developers

If you maintain a CLN-based application that calls keysend, the migration checklist is short:

1. Replace keysend RPC calls with xkeysend.
2. Replace maxfeepercent and exemptfee parameters with a single maxfee absolute cap.
3. Replace fixed retry counts with retry_for (a time-based retry window).
4. Keep extratlvs usage unchanged: the format is the same.
5. Test against the v26.06 release with allow-deprecated-apis=false to verify your code does not call any deprecated commands.

For the broader ecosystem, the strategic question is whether to invest in keysend compatibility at all or move toward BOLT12 offers. If your use case needs proof of payment, BOLT12 is the clear choice. If you need to reach LND nodes without any prior offer exchange, keysend (via bLIP-0003) remains the only cross-implementation option. The two approaches serve different niches and will likely coexist for years.

Beyond Lightning: Spontaneous Transfers on Spark

The complexity of keysend, xkeysend, AMP, and BOLT12 reflects a fundamental challenge in Lightning's architecture: payment channels require coordination between sender and recipient to route funds through the network. Spontaneous payments are a workaround for that coordination requirement, and each workaround introduces its own tradeoffs.

Spark sidesteps the problem entirely. Because Spark uses statechains rather than payment channels, transfers do not require routing through intermediate nodes. A sender can push Bitcoin or USDB to any Spark address without the recipient generating an invoice, publishing an offer, or even being online. The recipient's Spark Service Provider holds the payment conditionally until they come back online.

This means no protocol debate over keysend vs. xkeysend vs. AMP vs. BOLT12. Spontaneous transfers are the default behavior, not a bolt-on protocol extension. For developers building wallets or payment applications, the Spark SDK provides a single API for sending to any Spark user, and General Bread demonstrates what this looks like in a consumer wallet: instant transfers with no invoice management, channel balancing, or routing configuration.

To compare how Spark's approach differs from Lightning's channel-based model, see the Spark vs. Lightning comparison or explore the SDK integration guide for hands-on documentation.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.