Spontaneous Payment (Lightning)

What Is a Spontaneous Payment?

A spontaneous payment is a Lightning Network payment sent without a prior invoice from the recipient. In the standard Lightning flow, the recipient must first create a Lightning invoice containing a payment hash, which the sender then pays. This is sometimes called a "pull" model: the recipient pulls payment by presenting an invoice.

Spontaneous payments invert this pattern into a "push" model. The sender decides to pay a recipient identified only by their node's public key, without any prior communication. The sender generates the payment secret themselves and routes the payment through the network. This makes Lightning payments feel more like handing someone cash: you don't need to ask for a bill first.

The concept emerged because invoice-based payments require both parties to be online and interact before a payment can begin. For use cases like tips, donations, and streaming payments, this prerequisite creates unnecessary friction.

How It Works

The dominant spontaneous payment mechanism on Lightning is keysend, documented in bLIP-3. Understanding how it differs from a standard invoice-based payment clarifies the trade-offs.

Standard Invoice Flow

In a normal BOLT 11 invoice payment:

1. The recipient generates a random preimage and computes its SHA-256 hash
2. The recipient encodes the hash into an invoice and shares it with the sender
3. The sender routes an HTLC locked to that hash through the network
4. The recipient reveals the preimage to claim the payment
5. The preimage propagates back through each hop, settling the HTLCs

The recipient controls the secret, so revealing it serves as cryptographic proof that payment was received.

Keysend Flow

With keysend, the sender takes over the role of generating the secret:

1. The sender generates a cryptographically random 32-byte preimage
2. The sender computes the SHA-256 hash of this preimage to use as the payment hash
3. The sender embeds the preimage in a TLV (Type-Length-Value) record inside the onion-encrypted payload, using the registered TLV type 5482373484
4. The sender routes the HTLC through the network, locked to the payment hash
5. The recipient's node decrypts the final onion layer, extracts the preimage from the TLV record, verifies it matches the payment hash, and uses it to settle the HTLC

Because the preimage travels inside the onion payload, only the final recipient can read it. Intermediate routing nodes see the payment hash but never the preimage until settlement propagates back.

Enabling Keysend

Keysend is opt-in for both sender and receiver. In LND, the receiver must enable it in their configuration:

# lnd.conf
[Application Options]
accept-keysend=true

# To also accept AMP spontaneous payments
accept-amp=true

Sending a keysend payment in LND uses the sendpayment command with the --keysend flag:

# Send 1000 sats to a node by public key
lncli sendpayment \
  --dest=<recipient_pubkey> \
  --amt=1000 \
  --keysend

The sender does not need to manually generate a preimage: the node handles preimage generation internally when the keysend flag is set.

Custom Data Records

Keysend payments can carry additional TLV records alongside the preimage. This enables attaching arbitrary data to a payment, such as text messages or metadata. The Podcasting 2.0 standard uses this feature for "boostagrams," where listeners send sats with a comment attached to podcast creators.

# Send keysend with a custom message (TLV type 34349334)
lncli sendpayment \
  --dest=<recipient_pubkey> \
  --amt=100 \
  --keysend \
  --data 34349334=<hex_encoded_message>

Comparison with Other Payment Methods

Spontaneous payments are one of several Lightning payment mechanisms, each with different trade-offs:

BOLT 12 offers address many of the same friction points as keysend (no single-use invoice needed) while preserving proof of payment, since the recipient still generates the preimage. For a detailed comparison, see Lightning Invoices: BOLT 11, BOLT 12, and Beyond.

AMP: Another Spontaneous Payment Method

Atomic Multipath Payments (AMP) offer an alternative approach to spontaneous payments. With AMP, the sender generates a root preimage and splits it across multiple payment shards using XOR operations. The recipient can only reconstruct the original preimage once all shards arrive, ensuring atomicity across multiple paths.

AMP shares the same "push" model as keysend and likewise sacrifices proof of payment. However, AMP provides built-in support for multipath payments, making it better suited for larger amounts that need to be split across multiple channels. LND has supported AMP as a first-class feature since v0.13.0.

Use Cases

Tips and Donations

Spontaneous payments are ideal for tipping content creators, open-source developers, or anyone who publishes their node's public key. The sender can tip any amount at any time without the recipient needing to generate a unique invoice for each payment. This is especially useful for streaming platforms and social media integrations where generating an invoice for every micro-tip would be impractical.

Podcast Streaming Payments

The Podcasting 2.0 ecosystem relies heavily on keysend for value-for-value streaming. Podcast apps send small keysend payments (often a few sats per minute) to creators as listeners tune in. Custom TLV records carry metadata like the podcast name, episode, and timestamp, allowing creators to see exactly which content earned revenue.

Messaging and Data Transfer

By attaching custom TLV records, keysend payments can carry short messages alongside value. This has enabled experimental chat applications built on top of the Lightning Network, where each message includes a small payment. While onion messages provide a more efficient path for data-only communication, keysend remains popular for combined value-plus-message use cases.

Machine-to-Machine Payments

Automated systems that need to pay other systems benefit from spontaneous payments because there is no invoice negotiation step. An IoT device, API gateway, or AI agent can push payment to a known node without waiting for an invoice response, reducing latency and complexity in automated payment workflows.

Why It Matters

Spontaneous payments remove a fundamental friction point in Lightning: the requirement for recipient interaction before a payment can begin. This "push" capability makes Lightning more versatile, enabling payment patterns that mirror how physical cash works.

For developers building on Lightning, spontaneous payments simplify application architecture by eliminating the invoice exchange step. Instead of managing invoice generation, distribution, and expiry, an application can simply push funds to a known public key. Layer 2 solutions like Spark further reduce payment friction by eliminating the need for channel management entirely, making bitcoin payments accessible without the complexity of running a Lightning node.

For a deeper look at how Lightning finds paths to deliver these payments, see Lightning Network Routing Deep Dive.

Risks and Considerations

No Proof of Payment

The most significant trade-off of spontaneous payments is the loss of proof of payment. In invoice-based payments, the sender receives the preimage only after the recipient claims funds. This preimage, combined with the invoice signature, serves as cryptographic proof that the specific recipient was paid.

With keysend, the sender generated the preimage themselves, so possessing it proves nothing. The sender cannot demonstrate to a third party that payment was actually received. This makes spontaneous payments unsuitable for scenarios requiring payment receipts, dispute resolution, or regulatory compliance.

Recipient Must Be Online

Spontaneous payments require the recipient's node to be online and reachable at the time of payment. There is no invoice that can be cached or queued: if the recipient is offline, the payment fails immediately. This limitation is shared with standard Lightning payments but is more pronounced for keysend because there is no coordination step where the recipient's availability is confirmed.

Async payments, still under development in the Lightning protocol, aim to solve this limitation by allowing payments to be held until the recipient comes online.

Spam and Unsolicited Payments

Because anyone can send a spontaneous payment to any public node, there is a risk of unsolicited payments. While receiving free sats might seem harmless, dust-sized payments can clutter a node's payment history, and attached messages could contain unwanted content. Some node operators disable keysend to avoid this.

Standardization Status

Keysend is not part of the core BOLT specification. It is documented in bLIP-3 as a de facto standard, meaning implementations may vary. The Lightning development community has indicated that keysend may be deprecated in favor of more robust spontaneous payment solutions like BOLT 12 offers, which preserve proof of payment while still supporting reusable payment endpoints.

No Amount Negotiation

In an invoice-based flow, the recipient specifies the amount. With spontaneous payments, the sender chooses the amount unilaterally. This means the recipient has no way to request a specific payment amount or reject a payment for being too small before it arrives. For commerce, this makes invoices or offers the better choice.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.