Glossary / Lightning & layer 2
Keysend
- What is Keysend?
- Keysend sends a Lightning payment with no invoice: the payer generates the 32 byte preimage, hashes it into the payment hash, and ships the secret inside the onion.
Keysend inverts the normal Lightning flow, where the receiver picks a secret and publishes its hash in an invoice. The sender's secret rides in custom TLV record 5482373484, an even number, which BOLT 1 makes a node that does not know keysend reject rather than ignore. You can pay a bare node pubkey with no round trip, and you give up the cryptographic receipt an invoice would have left.
How it works
Keysend rests on the harsher half of one BOLT 1 rule: a reader discards an unknown TLV record with an odd type and carries on, but must fail the whole stream on an unknown even one.
Type identifiers below 2^16 are reserved for the BOLTs and everything from 2^16 up is free for custom records, and BOLT 1 says to pick an odd number when ordinary nodes should ignore the data, an even one when they should reject it. bLIP-3 records that 5482373484 was chosen at random by the original lnd implementation, and it ends in a four, so keysend landed on the rejecting side. That is why it needs a feature bit: willing nodes advertise 54/55, named keysend, which depends on var_onion_optin, and bLIP-3 says senders should look for it rather than send blind and watch it fail.
The sender's job, set out in bLIP-3, is short. Generate a cryptographically secure random 32 byte value, put it in that record, and set the payment_hash in update_add_htlc to its SHA-256. Never reuse a preimage, and never reuse one from an invoice you already paid. The packet is obfuscated at each hop, so a hop recovers only the address of the next one and nobody in between sees the record. The final node hashes the value it finds, checks it against the hash it was asked to accept, and settles.
Refusal is deliberately quiet. BOLT 4 has a literal answer for a payload a node did not understand, PERM|22 invalid_onion_payload, which may even name the offending TLV type. bLIP-3 asks receivers to return PERM|15 incorrect_or_unknown_payment_details instead, so a refused keysend is indistinguishable from a payment hash the node never issued.
Where you see it
Keysend is the plumbing under podcast boosts.
bLIP-10 defines a second record, type 7629169, originally chosen by Breez, carrying a flat JSON blob attached to the keysend payment: the podcast title, the episode, ts for the playback position in seconds, action set to boost or stream, and an optional message, which is what makes a boostagram. Per-minute streaming sets seconds_back to 60. That record is odd, which is why bLIP-10 waves off backwards compatibility: a host who ignores the metadata still keeps the sats. It exists because a keysend on its own tells the recipient nothing, so an app has to name the show itself.
The same gap keeps keysend out of the buying path. An exchange withdrawal either hands you an invoice or asks you for one, because the platform has to bind the payment to your account, and the word appears in none of the 63 exchange records or 41 wallet reviews on this site. bLIP-3 states the trade honestly: it expects keysend to give way to a better designed spontaneous payment, naming offers and AMP, and lists what you forfeit meanwhile, proof of payment and any say by the payee over the final CLTV expiry.
Keysend vs Lightning address
Keysend and a Lightning address both let you pay someone who never handed you an invoice, and only one of them truly skips the invoice. Typing user@example.com sends your wallet on an HTTPS lookup that returns a fresh BOLT11 invoice, so the receiver still chose the preimage and you end up holding a receipt backed by their signature. Keysend needs no web request and no server, only the 33 byte node pubkey and a route to it, and it leaves you nothing to prove afterwards, because the secret was yours from the start. If you might ever need to show that you paid, take the invoice.