Get desktop application:
View/edit binary Protocol Buffers messages
Router is a service that offers advanced interaction with the router subsystem of the daemon.
SendPaymentV2 attempts to route a payment described by the passed PaymentRequest to the final destination. The call returns a stream of payment updates.
TrackPaymentV2 returns an update stream for the payment identified by the payment hash.
EstimateRouteFee allows callers to obtain a lower bound w.r.t how much it may cost to send an HTLC to the target end destination.
The destination once wishes to obtain a routing fee quote to.
The amount one wishes to send to the target destination.
A lower bound of the estimated fee to the target destination within the network, expressed in milli-satoshis.
An estimate of the worst case time delay that can occur. Note that callers will still need to factor in the final CLTV delta of the last hop into this value.
Deprecated, use SendToRouteV2. SendToRoute attempts to make a payment via the specified route. This method differs from SendPayment in that it allows users to specify a full route manually. This can be used for things like rebalancing, and atomic swaps. It differs from the newer SendToRouteV2 in that it doesn't return the full HTLC information.
The preimage obtained by making the payment.
The failure message in case the payment failed.
SendToRouteV2 attempts to make a payment via the specified route. This method differs from SendPayment in that it allows users to specify a full route manually. This can be used for things like rebalancing, and atomic swaps.
ResetMissionControl clears all mission control state and starts with a clean slate.
(message has no fields)
(message has no fields)
QueryMissionControl exposes the internal mission control state to callers. It is a development feature.
(message has no fields)
QueryMissionControlResponse contains mission control state.
Node pair-level mission control state.
QueryProbability returns the current success probability estimate for a given node pair and amount.
The source node pubkey of the pair.
The destination node pubkey of the pair.
The amount for which to calculate a probability.
The success probability for the requested pair.
The historical data for the requested pair.
BuildRoute builds a fully specified route based on a list of hop public keys. It retrieves the relevant channel policies from the graph in order to calculate the correct fees and time locks.
The amount to send expressed in msat. If set to zero, the minimum routable amount is used.
CLTV delta from the current height that should be used for the timelock of the final hop
The channel id of the channel that must be taken to the first hop. If zero, any channel may be used.
A list of hops that defines the route. This does not include the source hop pubkey.
Fully specified route that can be used to execute the payment.
SubscribeHtlcEvents creates a uni-directional stream from the server to the client which delivers a stream of htlc events.
(message has no fields)
HtlcEvent contains the htlc event that was processed. These are served on a best-effort basis; events are not persisted, delivery is not guaranteed (in the event of a crash in the switch, forward events may be lost) and some events may be replayed upon restart. Events consumed from this package should be de-duplicated by the htlc's unique combination of incoming and outgoing channel id and htlc id. [EXPERIMENTAL]
The short channel id that the incoming htlc arrived at our node on. This value is zero for sends.
The short channel id that the outgoing htlc left our node on. This value is zero for receives.
Incoming id is the index of the incoming htlc in the incoming channel. This value is zero for sends.
Outgoing id is the index of the outgoing htlc in the outgoing channel. This value is zero for receives.
The time in unix nanoseconds that the event occurred.
The event type indicates whether the htlc was part of a send, receive or forward.
Deprecated, use SendPaymentV2. SendPayment attempts to route a payment described by the passed PaymentRequest to the final destination. The call returns a stream of payment status updates.
Deprecated, use TrackPaymentV2. TrackPayment returns an update stream for the payment identified by the payment hash.
* HtlcInterceptor dispatches a bi-directional streaming RPC in which Forwarded HTLC requests are sent to the client and the client responds with a boolean that tells LND if this htlc should be intercepted. In case of interception, the htlc can be either settled, cancelled or resumed later by using the ResolveHoldForward endpoint.
* ForwardHtlcInterceptResponse enables the caller to resolve a previously hold forward. The caller can choose either to: - `Resume`: Execute the default behavior (usually forward). - `Reject`: Fail the htlc backwards. - `Settle`: Settle this htlc with a given preimage.
* The key of this forwarded htlc. It defines the incoming channel id and the index in this channel.
The resolve action for this intercepted htlc.
The preimage in case the resolve action is Settle.
The key of this forwarded htlc. It defines the incoming channel id and the index in this channel.
The incoming htlc amount.
The incoming htlc expiry.
The htlc payment hash. This value is not guaranteed to be unique per request.
The requested outgoing channel id for this forwarded htlc. Because of non-strict forwarding, this isn't necessarily the channel over which the packet will be forwarded eventually. A different channel to the same peer may be selected as well.
The outgoing htlc amount.
The outgoing htlc expiry.
Any custom records that were present in the payload.
Used in:
,/ The id of the channel that the is part of this circuit.
/ The index of the incoming htlc in the incoming channel.
Used in:
Used in:
Info contains details about the htlc that was forwarded.
Used in:
(message has no fields)
Used in:
Used in:
,The timelock on the incoming htlc.
The timelock on the outgoing htlc.
The amount of the incoming htlc.
The amount of the outgoing htlc.
Used in:
Info contains details about the htlc that we failed.
FailureCode is the BOLT error code for the failure.
FailureDetail provides additional information about the reason for the failure. This detail enriches the information provided by the wire message and may be 'no detail' if the wire message requires no additional metadata.
A string representation of the link failure.
Used in:
,Time of last failure.
Lowest amount that failed to forward rounded to whole sats. This may be set to zero if the failure is independent of amount.
Lowest amount that failed to forward in millisats. This may be set to zero if the failure is independent of amount.
Time of last success.
Highest amount that we could successfully forward rounded to whole sats.
Highest amount that we could successfully forward in millisats.
PairHistory contains the mission control state for a particular node pair.
Used in:
The source node pubkey of the pair.
The destination node pubkey of the pair.
Used in:
Payment is still in flight.
Payment completed successfully.
There are more routes to try, but the payment timeout was exceeded.
All possible routes were tried and failed permanently. Or were no routes to the destination at all.
A non-recoverable error has occured.
Payment details incorrect (unknown hash, invalid amt or invalid final cltv delta)
Insufficient local balance.
Used as response type in: Router.SendPayment, Router.TrackPayment
Current state the payment is in.
The pre-image of the payment when state is SUCCEEDED.
The HTLCs made in attempt to settle the payment [EXPERIMENTAL].
Used in:
Used as request type in: Router.SendPayment, Router.SendPaymentV2
The identity pubkey of the payment recipient
Number of satoshis to send. The fields amt and amt_msat are mutually exclusive.
Number of millisatoshis to send. The fields amt and amt_msat are mutually exclusive.
The hash to use within the payment's HTLC
The CLTV delta from the current height that should be used to set the timelock for the final hop.
A bare-bones invoice for a payment within the Lightning Network. With the details of the invoice, the sender has all the data necessary to send a payment to the recipient. The amount in the payment request may be zero. In that case it is required to set the amt field as well. If no payment request is specified, the following fields are required: dest, amt and payment_hash.
An upper limit on the amount of time we should spend when attempting to fulfill the payment. This is expressed in seconds. If we cannot make a successful payment within this time frame, an error will be returned. This field must be non-zero.
The maximum number of satoshis that will be paid as a fee of the payment. If this field is left to the default value of 0, only zero-fee routes will be considered. This usually means single hop routes connecting directly to the destination. To send the payment without a fee limit, use max int here. The fields fee_limit_sat and fee_limit_msat are mutually exclusive.
The maximum number of millisatoshis that will be paid as a fee of the payment. If this field is left to the default value of 0, only zero-fee routes will be considered. This usually means single hop routes connecting directly to the destination. To send the payment without a fee limit, use max int here. The fields fee_limit_sat and fee_limit_msat are mutually exclusive.
Deprecated, use outgoing_chan_ids. The channel id of the channel that must be taken to the first hop. If zero, any channel may be used (unless outgoing_chan_ids are set).
The channel ids of the channels are allowed for the first hop. If empty, any channel may be used.
The pubkey of the last hop of the route. If empty, any hop may be used.
An optional maximum total time lock for the route. This should not exceed lnd's `--max-cltv-expiry` setting. If zero, then the value of `--max-cltv-expiry` is enforced.
Optional route hints to reach the destination through private channels.
An optional field that can be used to pass an arbitrary set of TLV records to a peer which understands the new records. This can be used to pass application specific data during the payment attempt. Record types are required to be in the custom range >= 65536. When using REST, the values must be encoded as base64.
If set, circular payments to self are permitted.
Features assumed to be supported by the final node. All transitive feature dependencies must also be set properly. For a given feature bit pair, either optional or remote may be set, but not both. If this field is nil or empty, the router will try to load destination features from the graph as a fallback.
The maximum number of partial payments that may be use to complete the full amount.
If set, only the final payment update is streamed back. Intermediate updates that show which htlcs are still in flight are suppressed.
Used as request type in: Router.SendToRoute, Router.SendToRouteV2
The payment hash to use for the HTLC.
Route that should be used to attempt to complete the payment.
Used in:
(message has no fields)
Used as request type in: Router.TrackPayment, Router.TrackPaymentV2
The hash of the payment to look up.
If set, only the final payment update is streamed back. Intermediate updates that show which htlcs are still in flight are suppressed.