Keysend

Keysend is a Lightning Network feature that lets one node push a payment directly to another node's public key without the recipient first issuing an invoice. It inverts the normal request-then-pay flow: instead of the payee generating a payment hash and waiting to be paid, the payer generates the secret themselves and ships funds spontaneously to a known node ID. If you know a node's pubkey and a route exists, you can pay it — no coordination, no web server, no prior contact.

How it works

In a standard Lightning payment, the recipient creates a random preimage, hashes it into the payment hash embedded in a BOLT11 invoice, and reveals the preimage only when the payment arrives — that reveal is what settles the HTLCs along the route. Keysend reverses ownership of the secret: the sender generates the preimage, builds the HTLC around its hash as usual, and tucks the preimage itself into a custom TLV (type-length-value) record inside the encrypted onion payload destined for the final hop. When the payment lands, the recipient's node extracts the preimage from the payload and uses it to claim the funds. Every intermediate routing node sees a perfectly ordinary HTLC; only the destination learns that the payment carried its own key.

What it enables

Because no prior coordination is needed, keysend is the natural transport for streaming and push payments. It became the backbone of Podcasting 2.0 and the value-for-value model, where listeners stream sats to a creator's node minute by minute, and it suits tips, donations, and machine-to-machine micropayments where asking for an invoice per payment would be absurd. For a sovereign operator, there is something clarifying about it: a public key plus open channels is a complete, censorship-resistant payment endpoint. No platform account, no payment processor, no one to deplatform you — the same property that makes a self-hosted node worth running in the first place. Receiving still requires inbound liquidity and a reachable node, as with any Lightning payment.

Operationally, keysend is usually opt-in: node software exposes an accept-keysend setting, and a node that leaves it off simply fails the payment. Operators who enable it accept some housekeeping — spontaneous payments arrive with no invoice to reconcile against, so bookkeeping leans on whatever TLV metadata senders include, and an open endpoint that accepts unsolicited sats can also accept unsolicited dust. Most treat that as a fair trade for being permissionlessly payable.

One structural limit applies to everything in this family: Lightning recipients must be online to claim a payment, keysend included — the preimage in the onion does not help a node that is not there to unwrap it. Streaming sats therefore suits always-on nodes best, and research into asynchronous payments for mobile wallets continues precisely because spontaneous payments are only as spontaneous as the receiver's uptime.

Limitations and successors

Keysend's convenience costs it the receipt. Because the payer manufactures the preimage, possessing it proves nothing — a normal invoice makes the preimage a cryptographic proof-of-payment that only the payee could have revealed, and keysend gives that up. The receiver also gets no built-in record of what a payment was for, so metadata rides in ad-hoc TLV conventions rather than a signed request. Keysend was also never fully standardized across implementations — it spread as a de facto convention. BOLT12 Offers addresses these gaps properly, letting a recipient publish a static, reusable offer from which the wallet fetches a real, signed invoice on demand — spontaneous-feeling payments with proofs intact. Human-readable identifiers layered on top, like the Lightning Address, chase the same goal of frictionless receiving. Keysend remains the minimal, rough-edged original: point at a pubkey, push sats, done.