The keysend RPC command attempts to find a route to the given destination,
and send the specified amount to it. Unlike the pay RPC command the
keysend command does not require an invoice, instead it uses the
destination node ID, and amount to find a route to the specified node.
In order for the destination to be able to claim the payment, the
payment_key is randomly generated by the sender and included in the
encrypted payload for the destination. As a consequence there is not
proof-of-payment, like there is with an invoice where the payment_key is
generated on the destination, and the only way sender could have it is by
sending a payment. Please ensure that this matches your use-case when using
keysend.
destination is the 33 byte, hex-encoded, node ID of the node that the payment should go to.
msatoshi is in millisatoshi precision; it can be a whole number, or a whole number with suffix msat or sat, or a three decimal point number with suffix sat, or an 1 to 11 decimal point number suffixed by btc.
The label field is used to attach a label to payments, and is returned in lightning-listpays(7) and lightning-listsendpays(7).
The maxfeepercent limits the money paid in fees as percentage of the total amount that is to be transferred, and defaults to 0.5.
The exemptfee option can be 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 (default: 5000 millisatoshi).
The response will occur when the payment fails or succeeds.
Unlike lightning-pay(7), issuing the same keysend commands multiple times will result in multiple payments being sent.
Until retry_for seconds passes (default: 60), the command will keep finding routes and retrying the payment.
However, a payment may be delayed for up to maxdelay blocks by another node; clients should be prepared for this worst case.
When using lightning-cli, you may skip optional parameters by using
null. Alternatively, use -k option to provide parameters by name.
To protect user privacy, the payment algorithm performs some randomization.
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.
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.
Route randomization will never exceed maxfeepercent of the payment.
Route randomization and shadow routing will not take routes that would
exceed maxdelay.
The keysend RPC command attempts to find a route to the given destination, and send the specified amount to it. Unlike the
pay
RPC command thekeysend
command does not require an invoice, instead it uses thedestination
node ID, andamount
to find a route to the specified node.In order for the destination to be able to claim the payment, the
payment_key
is randomly generated by the sender and included in the encrypted payload for the destination. As a consequence there is not proof-of-payment, like there is with an invoice where thepayment_key
is generated on the destination, and the only way sender could have it is by sending a payment. Please ensure that this matches your use-case when usingkeysend
.destination
is the 33 byte, hex-encoded, node ID of the node that the payment should go to.msatoshi
is in millisatoshi precision; it can be a whole number, or a whole number with suffixmsat
orsat
, or a three decimal point number with suffixsat
, or an 1 to 11 decimal point number suffixed bybtc
.The
label
field is used to attach a label to payments, and is returned in lightning-listpays(7) and lightning-listsendpays(7). Themaxfeepercent
limits the money paid in fees as percentage of the total amount that is to be transferred, and defaults to 0.5. Theexemptfee
option can be used for tiny payments which would be dominated by the fee leveraged by forwarding nodes. Settingexemptfee
allows themaxfeepercent
check to be skipped on fees that are smaller than exemptfee (default: 5000 millisatoshi).The response will occur when the payment fails or succeeds. Unlike lightning-pay(7), issuing the same
keysend
commands multiple times will result in multiple payments being sent.Until retry_for seconds passes (default: 60), the command will keep finding routes and retrying the payment. However, a payment may be delayed for up to
maxdelay
blocks by another node; clients should be prepared for this worst case.When using lightning-cli, you may skip optional parameters by using null. Alternatively, use -k option to provide parameters by name.
RANDOMIZATION
To protect user privacy, the payment algorithm performs some randomization.
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.
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.
Route randomization will never exceed maxfeepercent of the payment. Route randomization and shadow routing will not take routes that would exceed maxdelay.