LIGHTNING-KEYSEND(7)

📦
version 26.06.9 · 2 versions
, in nixpkgs unstable

💸 LIGHTNING-KEYSEND(7) 💸

okay so bestie, this is a lightning-keysend manual page — that's the 7 section of the man pages, iykyk. Sit down, grab a lil snack, we're learning how to yeet sats at someone with literally no invoice 💖

🌸 SYNOPSIS 🌸

keysend destination amount_msat [label] [maxfeepercent] [retry_for]
[maxdelay] [exemptfee] [routehints] [extratlvs] [maxfee]

that's it. that's the whole vibe ✨

🦋 DESCRIPTION 🦋

Command deprecated in v26.06, removed after v27.03.

⚠️ WARNING: deprecated — use xkeysend instead, which uses askrene for better route calculation (and learns from previous payments). fr fr, it's the upgrade.

So the keysend RPC command tries to find a route to the destination you give it and send the specified amount. Here's the iconic part: unlike the pay RPC command, keysend does not require an invoice. It just uses the destination node ID and the amount to find a route to that node. no invoice, no drama 🎀

Now for the part you need to know 👀 — for the destination to be able to claim the payment, the payment_key is randomly generated by the sender and stuffed into the encrypted payload for the destination. The consequence? There's no proof-of-payment — not like with an invoice, where the payment_key is generated on the destination side and the only way the sender could have it is by actually sending a payment. So please, pls, double-check that this matches your use-case when you use keysend. not me warning you twice 💅

When you're using $ lightning-cli, you can skip optional parameters by using null. Or, alternatively, use the -k option to provide parameters by name. slay.

  • destination (pubkey) — the 33 byte, hex-encoded, node ID of the node that the payment should go to.
  • amount_msat (msat) — a whole number, or a whole number with suffix msat or sat, or a three decimal point number with suffix sat, or a 1 to 11 decimal point number suffixed by btc. basically, you have options ✨
  • label (string, optional) — used to attach a label to payments, and it's returned in lightning-listpays(7) and lightning-listsendpays(7).
  • maxfeepercent (number, optional) — limits the money paid in fees as a percentage of the total amount that is to be transferred. The default is 0.5.
  • retry_for (u32, optional) — until retry_for seconds passes, the command will keep finding routes and retrying the payment. However, a payment may be delayed for up to maxdelay blocks by another node, so clients should be prepared for this worst case. The default is 60 seconds.
  • maxdelay (u32, optional) — number of blocks the payment may be delayed.
  • exemptfee (msat, optional) — used for tiny payments which would be dominated by the fee leveraged by forwarding nodes. Setting exemptfee allows the maxfeepercent check to be skipped on fees that are smaller than exemptfee. The default is 5000 millisatoshi.
  • routehints (array of arrays, optional):
    • (array of objects)
    • id (pubkey)
    • scid (short_channel_id)
    • feebase (msat)
    • feeprop (u32)
    • expirydelta (u16)
  • extratlvs (object, optional) — dictionary of additional fields to insert into the final tlv. The format is 'fieldnumber': 'hexstring'.:
  • maxfee (msat, optional) — maxfee overrides both maxfeepercent and exemptfee defaults (and if you specify maxfee you cannot specify either of those 😤), and creates an absolute limit on what fee we will pay. This allows you to implement your own heuristics rather than the primitive ones used here. (added v24.11)

🧚 RANDOMIZATION 🧚

To protect user privacy, the payment algorithm performs some randomization. yes bestie, it's doing the most for you 💜

1: Route Randomization

Route randomization means the payment algorithm does not always use the lowest-fee or shortest route. This prevents some highly-connected node from learning all of the user payments by reducing their fees below the network average. sneaky but make it protective 🎀

2: Shadow Route

Shadow route means the payment algorithm will virtually extend the route by adding delays and fees along it, making it appear to intermediate nodes that the route is longer than it actually is. This prevents intermediate nodes from reliably guessing their distance from the payee. it's giving illusion, it's giving smoke and mirrors ✨

Route randomization will never exceed maxfeepercent of the payment. Route randomization and shadow routing will not take routes that would exceed maxdelay.

👑 RETURN VALUE 👑

On success, an object is returned, containing:

  • payment_preimage (secret) — the proof of payment: SHA256 of this payment_hash.
  • payment_hash (hash) — the hash of the payment_preimage which will prove payment.
  • created_at (number) — the UNIX timestamp showing when this payment was initiated.
  • parts (u32) — how many attempts this took.
  • amount_msat (msat) — amount the recipient received.
  • amount_sent_msat (msat) — total amount we sent (including fees).
  • status (string) (always "complete") — status of payment.
  • destination (pubkey, optional) — the final destination of the payment.

The following warnings may also be returned:

  • warning_partial_completion — not all parts of a multi-part payment have completed. 😭

You can monitor the progress and retries of a payment using the lightning-paystatus(7) command.

💀 ERRORS 💀

The following error codes may occur:

  • -1 — catchall nonspecific error.
  • 203 — permanent failure at destination. The data field of the error will be a routing failure object.
  • 205 — unable to find a route.
  • 206 — route too expensive. Either the fee or the needed total locktime for the route exceeds your maxfeepercent or maxdelay settings, respectively. The data field of the error will indicate the actual fee as well as the feepercent percentage that the fee has of the destination payment amount. It will also indicate the actual delay along the route.
  • 210 — payment timed out without a payment in progress.

A routing failure object has the fields below:

  • erring_index — the index of the node along the route that reported the error. 0 for the local node, 1 for the first hop, and so on.
  • erring_node — the hex string of the pubkey id of the node that reported the error.
  • erring_channel — the short channel ID of the channel that has the error, or 0:0:0 if the destination node raised the error.
  • failcode — the failure code, as per BOLT #4.
  • channel_update — the hex string of the channel_update message received from the remote node. Only present if error is from the remote node and the failcode has the UPDATE bit set, as per BOLT #4.

🫶 AUTHOR 🫶

Christian Decker decker@blockstream.com is mainly responsible. legend behavior, honestly 👑

🌈 SEE ALSO 🌈

lightning-xkeysend(7), lightning-listpays(7), lightning-decode(7), lightning-listinvoices(7), lightning-delinvoice(7), lightning-getroute(7), lightning-invoice(7)

⭐ RESOURCES ⭐

Main web site: https://github.com/ElementsProject/lightning

🍓 EXAMPLES 🍓

Example 1:

Request:

$ lightning-cli keysend -k "destination"="nodeid030303030303030303030303030303030303030303030303030303030303" "amount_msat"=10000

{
  "id": "example:keysend#1",
  "method": "keysend",
  "params": {
    "destination": "nodeid030303030303030303030303030303030303030303030303030303030303",
    "amount_msat": 10000
  }
}

Response:

{
  "destination": "nodeid030303030303030303030303030303030303030303030303030303030303",
  "payment_hash": "paymenthashkey01k101k101k101k101k101k101k101k101k101k101k101k101",
  "created_at": 1738000000,
  "parts": 1,
  "amount_msat": 10000,
  "amount_sent_msat": 10001,
  "payment_preimage": "paymentpreimage1010101010101010101010101010101010101010101010101",
  "status": "complete"
}

Example 2:

Request:

$ lightning-cli keysend -k "destination"="nodeid040404040404040404040404040404040404040404040404040404040404" "amount_msat"=10000000 "extratlvs"='{"133773310": "68656c6c6f776f726c64", "133773312": "66696c7465726d65"}'

{
  "id": "example:keysend#2",
  "method": "keysend",
  "params": {
    "destination": "nodeid040404040404040404040404040404040404040404040404040404040404",
    "amount_msat": 10000000,
    "extratlvs": {
      "133773310": "68656c6c6f776f726c64",
      "133773312": "66696c7465726d65"
    }
  }
}

Response:

{
  "destination": "nodeid040404040404040404040404040404040404040404040404040404040404",
  "payment_hash": "paymenthashkey02k201k201k201k201k201k201k201k201k201k201k201k201",
  "created_at": 1738000000,
  "parts": 1,
  "amount_msat": 10000000,
  "amount_sent_msat": 10000202,
  "payment_preimage": "paymentpreimage2020202020202020202020202020202020202020202020202",
  "status": "complete"
}

Example 3:

Request:

$ lightning-cli keysend -k "destination"="nodeid030303030303030303030303030303030303030303030303030303030303" "amount_msat"=10000 "routehints"='[[{"scid": "111x1x1", "id": "nodeid020202020202020202020202020202020202020202020202020202020202", "feebase": "1msat", "feeprop": 10, "expirydelta": 9}]]'

{
  "id": "example:keysend#3",
  "method": "keysend",
  "params": {
    "destination": "nodeid030303030303030303030303030303030303030303030303030303030303",
    "amount_msat": 10000,
    "routehints": [
      [
        {
          "scid": "111x1x1",
          "id": "nodeid020202020202020202020202020202020202020202020202020202020202",
          "feebase": "1msat",
          "feeprop": 10,
          "expirydelta": 9
        }
      ]
    ]
  }
}

Response:

{
  "destination": "nodeid030303030303030303030303030303030303030303030303030303030303",
  "payment_hash": "paymenthashkey03k301k301k301k301k301k301k301k301k301k301k301k301",
  "created_at": 1738000000,
  "parts": 2,
  "amount_msat": 10000,
  "amount_sent_msat": 10001,
  "payment_preimage": "paymentpreimage3030303030303030303030303030303030303030303030303",
  "status": "complete"
}

and that's the page, bestie!! this one came from Core Lightning v26.06.9 and it's the LIGHTNING-KEYSEND(7) manual — go forth and keysend responsibly (or, like, use xkeysend instead, since this one's deprecated 🙈) 💖✨

📦 where this page comes from