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. When using this RPC, make sure to set a fee limit, as the default routing fee limit is 0 sats. Without a non-zero fee limit only routes without fees will be attempted which often fails with FAILURE_REASON_NO_ROUTE.
lncli: `trackpayment` TrackPaymentV2 returns an update stream for the payment identified by the payment hash.
TrackPayments returns an update stream for every payment that is not in a terminal state. Note that if payments are in-flight while starting a new subscription, the start of the payment stream could produce out-of-order and/or duplicate events. In order to get updates for every in-flight payment attempt make sure to subscribe to this method before initiating any payments.
If set, only the final payment updates are streamed back. Intermediate updates that show which htlcs are still in flight are suppressed.
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 one wishes to obtain a routing fee quote to. If set, this parameter requires the amt_sat parameter also to be set. This parameter combination triggers a graph based routing fee estimation as opposed to a payment probe based estimate in case a payment request is provided. The graph based estimation is an algorithm that is executed on the in memory graph. Hence its runtime is significantly shorter than a payment probe estimation that sends out actual payments to the network.
The amount one wishes to send to the target destination. It is only to be used in combination with the dest parameter.
A payment request of the target node that the route fee request is intended for. Its parameters are input to probe payments that estimate routing fees. The timeout parameter can be specified to set a maximum time on the probing attempt. Cannot be used in combination with dest and amt_sat.
A user preference of how long a probe payment should maximally be allowed to take, denoted in seconds. The probing payment loop is aborted if this timeout is reached. Note that the probing process itself can take longer than the timeout if the HTLC becomes delayed or stuck. Canceling the context of this call will not cancel the payment loop, the duration is only controlled by the timeout parameter.
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.
An indication whether a probing payment succeeded or whether and why it failed. FAILURE_REASON_NONE indicates success.
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.
lncli: `resetmc` ResetMissionControl clears all mission control state and starts with a clean slate.
(message has no fields)
(message has no fields)
lncli: `querymc` 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.
lncli: `importmc` XImportMissionControl is an experimental API that imports the state provided to the internal mission control's state, using all results which are more recent than our existing values. These values will only be imported in-memory, and will not be persisted across restarts.
Node pair-level mission control state to be imported.
Whether to force override MC pair history. Note that even with force override the failure pair is imported before the success pair and both still clamp existing failure/success amounts.
(message has no fields)
lncli: `getmccfg` GetMissionControlConfig returns mission control's current config.
(message has no fields)
Mission control's currently active config.
lncli: `setmccfg` SetMissionControlConfig will set mission control's config, if the config provided is valid.
The config to set for mission control. Note that all values *must* be set, because the full config will be applied.
(message has no fields)
lncli: `queryprob` Deprecated. QueryProbability returns the current success probability estimate for a given node pair and amount. The call returns a zero success probability if no channel is available or if the amount violates min/max HTLC constraints.
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.
lncli: `buildroute` 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. Note that LND will use its default final_cltv_delta if no value is supplied. Make sure to add the correct final_cltv_delta depending on the invoice restriction. Moreover the caller has to make sure to provide the payment_addr if the route is paying an invoice which signaled it.
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.
An optional payment addr to be included within the last hop of the route. This is also called payment secret in specifications (e.g. BOLT 11).
An optional field that can be used to pass an arbitrary set of TLV records to the first hop peer of this payment. 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.
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). - `ResumeModified`: Execute the default behavior (usually forward) with HTLC field modifications. - `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.
Encrypted failure message in case the resolve action is Fail. If failure_message is specified, the failure_code field must be set to zero.
Return the specified failure code in case the resolve action is Fail. The message data fields are populated automatically. If a non-zero failure_code is specified, failure_message must not be set. For backwards-compatibility reasons, TEMPORARY_CHANNEL_FAILURE is the default value for this field.
The amount that was set on the p2p wire message of the incoming HTLC. This field is ignored if the action is not RESUME_MODIFIED or the amount is zero.
The amount to set on the p2p wire message of the resumed HTLC. This field is ignored if the action is not RESUME_MODIFIED or the amount is zero.
Any custom records that should be set on the p2p wire message message of the resumed HTLC. This field is ignored if the action is not RESUME_MODIFIED. This map will merge with the existing set of custom records (if any), replacing any conflicting types. Note that there currently is no support for deleting existing custom records (they can only be replaced).
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.
The onion blob for the next hop
The block height at which this htlc will be auto-failed to prevent the channel from force-closing.
The custom records of the peer's incoming p2p wire message.
lncli: `updatechanstatus` UpdateChanStatus attempts to manually set the state of a channel (enabled, disabled, or auto). A manual "disable" request will cause the channel to stay disabled until a subsequent manual request of either "enable" or "auto".
(message has no fields)
XAddLocalChanAliases is an experimental API that creates a set of new channel SCID alias mappings. The final total set of aliases in the manager after the add operation is returned. This is only a locally stored alias, and will not be communicated to the channel peer via any message. Therefore, routing over such an alias will only work if the peer also calls this same RPC on their end. If an alias already exists, an error is returned
XDeleteLocalChanAliases is an experimental API that deletes a set of alias mappings. The final total set of aliases in the manager after the delete operation is returned. The deletion will not be communicated to the channel peer via any message.
Used in:
The amount of time mission control will take to restore a penalized node or channel back to 50% success probability, expressed in seconds. Setting this value to a higher value will penalize failures for longer, making mission control less likely to route through nodes and channels that we have previously recorded failures for.
The probability of success mission control should assign to hop in a route where it has no other information available. Higher values will make mission control more willing to try hops that we have no information about, lower values will discourage trying these hops.
The importance that mission control should place on historical results, expressed as a value in [0;1]. Setting this value to 1 will ignore all historical payments and just use the hop probability to assess the probability of success for each hop. A zero value ignores hop probability completely and relies entirely on historical results, unless none are available.
The fraction of a channel's capacity that we consider to have liquidity. For amounts that come close to or exceed the fraction, an additional penalty is applied. A value of 1.0 disables the capacity factor. Allowed values are in [0.75, 1.0].
Used in:
NodeWeight defines how strongly other previous forwardings on channels of a router should be taken into account when computing a channel's probability to route. The allowed values are in the range [0, 1], where a value of 0 means that only direct information about a channel is taken into account.
ScaleMsat describes the scale over which channels statistically have some liquidity left. The value determines how quickly the bimodal distribution drops off from the edges of a channel. A larger value (compared to typical channel capacities) means that the drop off is slow and that channel balances are distributed more uniformly. A small value leads to the assumption of very unbalanced channels.
DecayTime describes the information decay of knowledge about previous successes and failures in channels. The smaller the decay time, the quicker we forget about past forwardings.
Used in:
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:
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:
,Deprecated, use AprioriParameters. The amount of time mission control will take to restore a penalized node or channel back to 50% success probability, expressed in seconds. Setting this value to a higher value will penalize failures for longer, making mission control less likely to route through nodes and channels that we have previously recorded failures for.
Deprecated, use AprioriParameters. The probability of success mission control should assign to hop in a route where it has no other information available. Higher values will make mission control more willing to try hops that we have no information about, lower values will discourage trying these hops.
Deprecated, use AprioriParameters. The importance that mission control should place on historical results, expressed as a value in [0;1]. Setting this value to 1 will ignore all historical payments and just use the hop probability to assess the probability of success for each hop. A zero value ignores hop probability completely and relies entirely on historical results, unless none are available.
The maximum number of payment results that mission control will store.
The minimum time that must have passed since the previously recorded failure before we raise the failure amount.
ProbabilityModel defines which probability estimator should be used in pathfinding. Note that the bimodal estimator is experimental.
EstimatorConfig is populated dependent on the estimator type.
Used in:
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 occurred.
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:
SETTLE is an action that is used to settle an HTLC instead of forwarding it.
FAIL is an action that is used to fail an HTLC backwards.
RESUME is an action that is used to resume a forward HTLC.
RESUME_MODIFIED is an action that is used to resume a hold forward HTLC with modifications specified during interception.
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.
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.
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).
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.
Number of millisatoshis to send. The fields amt and amt_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.
The pubkey of the last hop of the route. If empty, any hop may be used.
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.
The channel ids of the channels are allowed for the first hop. If empty, any channel may be used.
An optional payment addr to be included within the last hop of the route. This is also called payment secret in specifications (e.g. BOLT 11).
The largest payment split that should be attempted when making a payment if splitting is necessary. Setting this value will effectively cause lnd to split more aggressively, vs only when it thinks it needs to. Note that this value is in milli-satoshis.
If set, an AMP-payment will be attempted.
The time preference for this payment. Set to -1 to optimize for fees only, to 1 to optimize for reliability only or a value inbetween for a mix.
If set, the payment loop can be interrupted by manually canceling the payment context, even before the payment timeout is reached. Note that the payment may still succeed after cancellation, as in-flight attempts can still settle afterwards. Canceling will only prevent further attempts from being sent.
An optional field that can be used to pass an arbitrary set of TLV records to the first hop peer of this payment. 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.
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.
Whether the payment should be marked as failed when a temporary error is returned from the given route. Set it to true so the payment won't be failed unless a terminal error is occurred, such as payment timeout, no routes, incorrect payment details, or insufficient funds.
An optional field that can be used to pass an arbitrary set of TLV records to the first hop peer of this payment. 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.
Used in:
The revealed preimage.
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.