Keysend and Pubkey Payments

Welcome back! In our previous lesson, we learned about invoices — the standard way to request payments. But what if you want to send sats spontaneously, without the recipient creating an invoice first? That's where Keysend comes in.

What Is Keysend?

Keysend allows you to send Lightning payments to any node using just their public key — no invoice required. The sender generates the preimage themselves, enabling spontaneous payments.

Think of it like knowing someone's email address and sending them a message without them first requesting one.

How Traditional Invoices Work (Review)

Normal Lightning payments follow a specific sequence. The receiver generates a secret preimage, then creates an invoice with a payment hash (which is the hash of the preimage). The sender pays to that hash, and finally the receiver reveals the preimage to claim the payment. In this model, the receiver controls the preimage and must act first.

How Keysend Works

Keysend flips the traditional payment model. The sender generates their own preimage, then includes this preimage in an encrypted payload. The sender routes the payment to the recipient's public key, the recipient decrypts the payload to extract the preimage, and finally the recipient uses the preimage to claim the payment. The key difference is that the sender initiates everything without requiring any prior receiver action.

Requirements for Keysend

Both parties need specific capabilities for keysend to work. The sender needs a wallet or node that supports sending keysend payments. The receiver needs a node that accepts keysend payments, though most do by default. Not all Lightning software has keysend enabled by default, so it's important to check your implementation's settings.

Use Cases for Keysend

Keysend enables several important use cases. In Podcasting 2.0 and Value-for-Value models, listeners send streaming sats to podcasters automatically without invoices, just continuous micropayments to the podcaster's node. For spontaneous tips, you can send sats to any node you want to support without asking for an invoice. Donations to known addresses become simple by sending directly to a charity's or creator's node. For boosts and comments, podcast apps use keysend with attached messages to enable "boostagram" comments.

Sending with Keysend

The process varies by interface. Via a wallet that supports keysend, enter the recipient's public key (66 hex characters), enter the amount, optionally add a message, and send. Using command line with LND, you would run `lncli sendpayment --dest <pubkey> --amt <sats> --keysend`. Most implementations also support keysend through their payment APIs.

Attaching Messages to Keysend

Keysend payments can include custom data in the onion payload. The most common use is attaching text messages through TLV (Type-Length-Value) fields that carry custom data. Record type 7629169 is commonly used for text messages, though application-specific record types may vary. This capability enables "boostagrams" which are payments with attached messages in podcast apps.

Keysend Limitations

Keysend has several important limitations to consider. There's no standard proof of payment since the receiver didn't generate the invoice. The receiver must be reachable, meaning their node must be online and accepting keysend. Not all wallets support sending keysend, making it less universally available. Privacy considerations arise because the sender chooses the preimage, which has implications. Additionally, there's no amount negotiation as the sender decides the amount unilaterally.

AMP: Atomic Multi-Path Payments

A related technology, AMP (Atomic Multi-Path Payments), also enables spontaneous payments. It works by splitting a payment across multiple paths without the need for an invoice. Each part of the payment carries a unique payment hash, and the transaction settles atomically, meaning either the entire payment succeeds or none of it does. AMP is being adopted for spontaneous payment use cases alongside keysend.

Keysend vs Invoice: When to Use Each

So when should you use each? Use invoices for merchant payments where proof is needed, legal payments, or recurring subscriptions. Use Keysend for streaming payments in Podcasting 2.0, spontaneous donations, or one-time tips where asking for an invoice is impractical. Use either for personal transfers depending on your specific needs. Both have their place in the Lightning ecosystem.

Finding Node Public Keys

To send keysend, you need the recipient's node pubkey. You can obtain this from the recipient directly when they share their pubkey, from node explorer sites like Amboss, 1ML, or mempool.space, from applications that may display their node info, or sometimes from Lightning addresses that can be resolved to pubkeys. Public keys are 66 character hex strings starting with 02 or 03.

Enabling Keysend on Your Node

Different implementations handle keysend differently. LND has it enabled by default in recent versions, though you should check that `accept-keysend=true` is in your config. Core Lightning requires enabling it by installing the keysend plugin or using the `--accept-keysend` flag. For Eclair, check the documentation for current support status. Ensure keysend is enabled if you want to receive spontaneous payments.

Security Considerations

Receiving keysend is generally safe, but be aware of potential unsolicited payments (which are usually fine), possible spam with tiny amounts, and messages that may contain anything. When sending keysend, you're trusting the route for delivery without payment proof. For high-value payments where proof matters, invoices remain the preferred method.

In this lesson, we've learned about Keysend — the spontaneous payment method that enables sending without an invoice. It's essential for streaming payments, tips, and the Value-for-Value ecosystem.

In our next lesson, we'll explore Lightning Addresses and LNURL — technologies that make Lightning payments as easy as email.