Refactor liquidity source to support multiple LSP nodes by Camillarhi · Pull Request #792 · lightningdevkit/ldk-node

Camillarhi · 2026-02-12T10:42:34Z

The current setup ties you to a single LSP per protocol via set_liquidity_source_lsps1 / set_liquidity_source_lsps2. This refactor replaces that with a unified Vec<LspNode> model where LSP nodes are added via add_lsp() and protocol support is discovered at runtime through LSPS0 list_protocols. Multi-LSP support has been requested previously in #529.

Deprecated set_liquidity_source_lsps1 / set_liquidity_source_lsps2 in favor of add_lsp()
Replaced the per-protocol LSPS1Client / LSPS2Client with global pending request maps keyed by LSPSRequestId
Added LSPS0 protocol discovery with event handling for ListProtocolsResponse
Background discovery task spawns on Node::start()
LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer
Added request_channel_from_lsp() for explicit LSPS1 LSP selection
Updated event handling to use is_lsps_node() for multi-LSP counterparty checks

This sets the foundation for LSPS5 support currently being worked on in #729

ldk-reviews-bot · 2026-02-12T10:42:38Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Camillarhi · 2026-02-12T10:45:04Z

@tnull Early draft up for review, would appreciate feedback on the general API direction

tnull

Thanks! Some initial questions..

tnull · 2026-02-25T10:26:40Z

+ supported_protocols: Mutex::new(None),
+ })
+ .collect(),
+ pending_lsps1_opening_params_requests: Mutex::new(HashMap::new()),


Uh, no, I don't think we should just merge all into one. Especially given that we intend to add more logic on a per-spec basis, this will be will become even more confusing going forward. If anything, we should maybe start the refactoring by first moving the LSPS1/LSPS2 specific parts to src/liquidity/{lsps1,lsps2}.rs, or maybe even to client/service specific sub-modules like src/liquidity/{client,service}/{lsps1,lsps2}.rs.

Alright, I will move the LSPS1/LSPS2 specific parts

tnull · 2026-02-25T10:29:54Z

 	pub(crate) async fn lsps1_request_channel(
 &self, lsp_balance_sat: u64, client_balance_sat: u64, channel_expiry_blocks: u32,
- announce_channel: bool, refund_address: bitcoin::Address,
+ announce_channel: bool, refund_address: bitcoin::Address, node_id: &PublicKey,


Hmm, I do wonder if it would make sense to create something like an struct ServiceProvider and move the API methods to there. Then, each registered LSP would have a corresponding ServiceProvider that exposes a bunch of public and internal APIs, which would make the modularization cleaner and would avoid having to give node_id everywhere?

Makes sense, I will have a look and see

Camillarhi · 2026-03-26T00:47:38Z

Hello @tnull, apologies for the delay. This is ready for another round of review

tnull

Cool, already looks pretty good! Did a first higher-level pass, have yet to look into the details.

tnull · 2026-03-27T08:02:00Z

@@ -1,1542 +0,0 @@
-// This file is Copyright its original authors, visible in version control history.


Would be good to structure this PR in a way that (as far as possible) makes any code moves dedicated commits that can be picked up by git diff --color-moved --patience, as otherwise reviewing this in detail will be very hard.

tnull · 2026-03-27T08:11:47Z

+ }
+ }
+
+ discovery_ls.discover_all_lsp_protocols().await;


I think it would be good to make this part of the background task above? Also, can we spawn the discovery tasks in parallel rather than doing them sequentially?

tnull · 2026-03-27T08:15:51Z

 	}
+
+	/// Configures the [`Node`] instance to source inbound liquidity from the given LSP at runtime,
+	/// without specifying the exact protocol used (e.g., LSPS1 or LSPS2).


I think we can drop the remark regarding 'without specifying the exact protocol' here and elsewhere, as the API already communicates that due to being generic. I do however wonder if we'd want to move this method to an API-extension object similar to what we do for the payment types? I.e., retrieve the API object via Node::liquidity()?

Thanks. I will remove the remark and move this to a Node::liquidity() API-extension

tnull · 2026-03-27T08:16:53Z

+/// [`Bolt11Payment::receive_via_jit_channel`]: crate::payment::Bolt11Payment::receive_via_jit_channel
+#[derive(Clone)]
+#[cfg_attr(feature = "uniffi", derive(uniffi::Object))]
+pub struct LSPS1Liquidity {


It seems this is currently not exposed in the API anymore?

tnull · 2026-03-27T08:17:50Z

 	/// The given `token` will be used by the LSP to authenticate the user.
 	///
 	/// [bLIP-51 / LSPS1]: https://github.com/lightning/blips/blob/master/blip-0051.md
+	#[deprecated(note = "Use `add_lsp` instead")]


Hmm, I think so far we've been fine with just breaking the APIs without deprecating them first. If we find a better API I'd be fine with just dropping the old ones to clean up.

tnull

Cool. Docs CI is currently failing.

Would be great if you try once more to breakup the second commit into smaller chunks, but let me know if it's too cumbersome/impossible.

Feel free to mark ready for review then.

ldk-reviews-bot · 2026-04-02T16:09:13Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-02T16:45:26Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-04T16:09:41Z

🔔 2nd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-04T16:45:53Z

🔔 2nd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T16:10:41Z

🔔 3rd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T16:46:54Z

🔔 3rd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-08T16:11:42Z

🔔 4th Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-08T16:47:56Z

🔔 4th Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-27T00:02:22Z

🔔 9th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-30T00:01:09Z

🔔 10th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-01T00:01:50Z

🔔 11th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-03T00:02:28Z

🔔 12th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-06T00:01:00Z

🔔 13th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-08T00:01:53Z

🔔 14th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-10T00:02:21Z

🔔 15th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Replace per-protocol single-LSP configuration `LSPS1Client` and `LSPS2Client` with a unified `Vec<LspNode>` model where users configure LSP nodes via `add_liquidity_source()` at build time or runtime and per-LSP protocol support is discovered via the LSPS0 `list_protocols`. - Introduce a per-LSP `trust_peer_0conf` flag to `LspConfig`/`LspNode` structs that controls whether 0-conf channels from that LSP are accepted - Add LSPS0 protocol discovery `discover_lsp_protocols` with event handling for `ListProtocolsResponse` - Update events to also use each LSP's `trust_peer_0conf` flag when deciding whether to allow 0-conf channels - Replace `set_liquidity_source_lsps1` and `set_liquidity_source_lsps2` builder methods with a single `add_liquidity_source()` that takes a `trust_peer_0conf` flag - Rename `set_liquidity_provider_lsps2` to `enable_liquidity_provider` - LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer across all of them - Spawn background discovery task on `Node::start()` and expose a watch channel so dependent flows can wait for discovery to complete - Add a new `Liquidity` handler `Node::liquidity()` exposing `add_liquidity_source()` API for adding LSPs at runtime, and `lsps1()` for the existing LSPS1 surface

Remove the `Ignoring` variant now that the liquidity source is always built, so the enum and its match arms are now pure overhead. Replace it with a struct that holds the `LiquiditySource` directly and have each trait method delegate straight to `liquidity_manager()`.

tnull

Thanks! Excuse the considerable delay here! I'm going ahead landing this, we can address / revisit minor things in follow-ups (or as part of #900 for instance).

tnull · 2026-06-12T09:31:06Z

-.and_then(|ls| ls.as_ref().get_lsps2_lsp_details())
+
+// If the peer is a configured LSP node, additionally honor its trust_peer_0conf flag.
+if let Some(lsp) =


Codex:
[P1] trust_peer_0conf is only honored for LSPS2-discovered LSPs: /home/tnull/worktrees/ldk-node/pr-792/src/event.rs:1323. add_liquidity_source(..., true) documents generic 0-conf trust for the LSP (/home/tnull/worktrees/ldk-node/pr-792/src/builder.rs:448, /home/tnull/worktrees/ldk-node/pr-
792/src/liquidity/mod.rs:117), but inbound acceptance only looks up protocol 2. LSPS1-only LSPs, or trusted LSPs before/after failed LSPS0 discovery, now fall through to accept_inbound_channel instead of accept_inbound_channel_from_trusted_peer. The trust lookup should be by node id
independent of protocol; keep the LSPS2 protocol check only for accept_underpaying_htlcs.

tnull · 2026-06-12T09:32:40Z

 where
 	L::Target: Logger,
 {
-	Ignoring,


Hmm, in conjunction with #900 we might want to revisit this, i.e., whether we'll want to allow to disable LSP functionalities based on a feature entirely.

tnull · 2026-06-12T09:33:11Z

+pub(crate) mod lsps1;
+pub(crate) mod lsps2;
+
+pub use lsps1::LSPS1OrderStatus;


nit:
[P3] Three new files have CRLF line endings, so git diff --check upstream/main...HEAD reports trailing whitespace on every line: /home/tnull/worktrees/ldk-node/pr-792/src/liquidity/client/mod.rs:1, /home/tnull/worktrees/ldk-node/pr-792/src/liquidity/service/mod.rs:1, /home/tnull/worktrees/
ldk-node/pr-792/src/liquidity/service/lsps2.rs:1. cargo fmt tolerates it, but diff whitespace checks will fail. Normalize those files to LF.

tnull · 2026-06-12T09:38:00Z

Now documented them over at #936.

Camillarhi · 2026-06-12T10:02:06Z

Thanks for landing it, and no worries about the delay! I'll pick up the follow-ups in #936

Follow-up to #792 (multi-LSP support)

Camillarhi · 2026-02-12T10:42:34Z

The current setup ties you to a single LSP per protocol via set_liquidity_source_lsps1 / set_liquidity_source_lsps2. This refactor replaces that with a unified Vec<LspNode> model where LSP nodes are added via add_lsp() and protocol support is discovered at runtime through LSPS0 list_protocols. Multi-LSP support has been requested previously in #529.

Deprecated set_liquidity_source_lsps1 / set_liquidity_source_lsps2 in favor of add_lsp()
Replaced the per-protocol LSPS1Client / LSPS2Client with global pending request maps keyed by LSPSRequestId
Added LSPS0 protocol discovery with event handling for ListProtocolsResponse
Background discovery task spawns on Node::start()
LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer
Added request_channel_from_lsp() for explicit LSPS1 LSP selection
Updated event handling to use is_lsps_node() for multi-LSP counterparty checks

This sets the foundation for LSPS5 support currently being worked on in #729

ldk-reviews-bot · 2026-02-12T10:42:38Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Camillarhi · 2026-02-12T10:45:04Z

@tnull Early draft up for review, would appreciate feedback on the general API direction

tnull

Thanks! Some initial questions..

tnull · 2026-02-25T10:26:40Z

+ supported_protocols: Mutex::new(None),
+ })
+ .collect(),
+ pending_lsps1_opening_params_requests: Mutex::new(HashMap::new()),


Uh, no, I don't think we should just merge all into one. Especially given that we intend to add more logic on a per-spec basis, this will be will become even more confusing going forward. If anything, we should maybe start the refactoring by first moving the LSPS1/LSPS2 specific parts to src/liquidity/{lsps1,lsps2}.rs, or maybe even to client/service specific sub-modules like src/liquidity/{client,service}/{lsps1,lsps2}.rs.

Alright, I will move the LSPS1/LSPS2 specific parts

tnull · 2026-02-25T10:29:54Z

 	pub(crate) async fn lsps1_request_channel(
 &self, lsp_balance_sat: u64, client_balance_sat: u64, channel_expiry_blocks: u32,
- announce_channel: bool, refund_address: bitcoin::Address,
+ announce_channel: bool, refund_address: bitcoin::Address, node_id: &PublicKey,


Hmm, I do wonder if it would make sense to create something like an struct ServiceProvider and move the API methods to there. Then, each registered LSP would have a corresponding ServiceProvider that exposes a bunch of public and internal APIs, which would make the modularization cleaner and would avoid having to give node_id everywhere?

Makes sense, I will have a look and see

Camillarhi · 2026-03-26T00:47:38Z

Hello @tnull, apologies for the delay. This is ready for another round of review

tnull

Cool, already looks pretty good! Did a first higher-level pass, have yet to look into the details.

tnull · 2026-03-27T08:02:00Z

@@ -1,1542 +0,0 @@
-// This file is Copyright its original authors, visible in version control history.


Would be good to structure this PR in a way that (as far as possible) makes any code moves dedicated commits that can be picked up by git diff --color-moved --patience, as otherwise reviewing this in detail will be very hard.

tnull · 2026-03-27T08:11:47Z

+ }
+ }
+
+ discovery_ls.discover_all_lsp_protocols().await;


I think it would be good to make this part of the background task above? Also, can we spawn the discovery tasks in parallel rather than doing them sequentially?

tnull · 2026-03-27T08:15:51Z

 	}
+
+	/// Configures the [`Node`] instance to source inbound liquidity from the given LSP at runtime,
+	/// without specifying the exact protocol used (e.g., LSPS1 or LSPS2).


I think we can drop the remark regarding 'without specifying the exact protocol' here and elsewhere, as the API already communicates that due to being generic. I do however wonder if we'd want to move this method to an API-extension object similar to what we do for the payment types? I.e., retrieve the API object via Node::liquidity()?

Thanks. I will remove the remark and move this to a Node::liquidity() API-extension

tnull · 2026-03-27T08:16:53Z

+/// [`Bolt11Payment::receive_via_jit_channel`]: crate::payment::Bolt11Payment::receive_via_jit_channel
+#[derive(Clone)]
+#[cfg_attr(feature = "uniffi", derive(uniffi::Object))]
+pub struct LSPS1Liquidity {


It seems this is currently not exposed in the API anymore?

tnull · 2026-03-27T08:17:50Z

 	/// The given `token` will be used by the LSP to authenticate the user.
 	///
 	/// [bLIP-51 / LSPS1]: https://github.com/lightning/blips/blob/master/blip-0051.md
+	#[deprecated(note = "Use `add_lsp` instead")]


Hmm, I think so far we've been fine with just breaking the APIs without deprecating them first. If we find a better API I'd be fine with just dropping the old ones to clean up.

tnull

Cool. Docs CI is currently failing.

Would be great if you try once more to breakup the second commit into smaller chunks, but let me know if it's too cumbersome/impossible.

Feel free to mark ready for review then.

ldk-reviews-bot · 2026-04-02T16:09:13Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-02T16:45:26Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-04T16:09:41Z

🔔 2nd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-04T16:45:53Z

🔔 2nd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T16:10:41Z

🔔 3rd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T16:46:54Z

🔔 3rd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-08T16:11:42Z

🔔 4th Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-08T16:47:56Z

🔔 4th Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-27T00:02:22Z

🔔 9th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-30T00:01:09Z

🔔 10th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-01T00:01:50Z

🔔 11th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-03T00:02:28Z

🔔 12th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-06T00:01:00Z

🔔 13th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-08T00:01:53Z

🔔 14th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-10T00:02:21Z

🔔 15th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Replace per-protocol single-LSP configuration `LSPS1Client` and `LSPS2Client` with a unified `Vec<LspNode>` model where users configure LSP nodes via `add_liquidity_source()` at build time or runtime and per-LSP protocol support is discovered via the LSPS0 `list_protocols`. - Introduce a per-LSP `trust_peer_0conf` flag to `LspConfig`/`LspNode` structs that controls whether 0-conf channels from that LSP are accepted - Add LSPS0 protocol discovery `discover_lsp_protocols` with event handling for `ListProtocolsResponse` - Update events to also use each LSP's `trust_peer_0conf` flag when deciding whether to allow 0-conf channels - Replace `set_liquidity_source_lsps1` and `set_liquidity_source_lsps2` builder methods with a single `add_liquidity_source()` that takes a `trust_peer_0conf` flag - Rename `set_liquidity_provider_lsps2` to `enable_liquidity_provider` - LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer across all of them - Spawn background discovery task on `Node::start()` and expose a watch channel so dependent flows can wait for discovery to complete - Add a new `Liquidity` handler `Node::liquidity()` exposing `add_liquidity_source()` API for adding LSPs at runtime, and `lsps1()` for the existing LSPS1 surface

Remove the `Ignoring` variant now that the liquidity source is always built, so the enum and its match arms are now pure overhead. Replace it with a struct that holds the `LiquiditySource` directly and have each trait method delegate straight to `liquidity_manager()`.

tnull

Thanks! Excuse the considerable delay here! I'm going ahead landing this, we can address / revisit minor things in follow-ups (or as part of #900 for instance).

tnull · 2026-06-12T09:31:06Z

-.and_then(|ls| ls.as_ref().get_lsps2_lsp_details())
+
+// If the peer is a configured LSP node, additionally honor its trust_peer_0conf flag.
+if let Some(lsp) =


Codex:
[P1] trust_peer_0conf is only honored for LSPS2-discovered LSPs: /home/tnull/worktrees/ldk-node/pr-792/src/event.rs:1323. add_liquidity_source(..., true) documents generic 0-conf trust for the LSP (/home/tnull/worktrees/ldk-node/pr-792/src/builder.rs:448, /home/tnull/worktrees/ldk-node/pr-
792/src/liquidity/mod.rs:117), but inbound acceptance only looks up protocol 2. LSPS1-only LSPs, or trusted LSPs before/after failed LSPS0 discovery, now fall through to accept_inbound_channel instead of accept_inbound_channel_from_trusted_peer. The trust lookup should be by node id
independent of protocol; keep the LSPS2 protocol check only for accept_underpaying_htlcs.

tnull · 2026-06-12T09:32:40Z

 where
 	L::Target: Logger,
 {
-	Ignoring,


Hmm, in conjunction with #900 we might want to revisit this, i.e., whether we'll want to allow to disable LSP functionalities based on a feature entirely.

tnull · 2026-06-12T09:33:11Z

+pub(crate) mod lsps1;
+pub(crate) mod lsps2;
+
+pub use lsps1::LSPS1OrderStatus;


nit:
[P3] Three new files have CRLF line endings, so git diff --check upstream/main...HEAD reports trailing whitespace on every line: /home/tnull/worktrees/ldk-node/pr-792/src/liquidity/client/mod.rs:1, /home/tnull/worktrees/ldk-node/pr-792/src/liquidity/service/mod.rs:1, /home/tnull/worktrees/
ldk-node/pr-792/src/liquidity/service/lsps2.rs:1. cargo fmt tolerates it, but diff whitespace checks will fail. Normalize those files to LF.

tnull · 2026-06-12T09:38:00Z

Now documented them over at #936.

Camillarhi · 2026-06-12T10:02:06Z

Thanks for landing it, and no worries about the delay! I'll pick up the follow-ups in #936

Follow-up to #792 (multi-LSP support)

Camillarhi · 2026-02-12T10:42:34Z

The current setup ties you to a single LSP per protocol via set_liquidity_source_lsps1 / set_liquidity_source_lsps2. This refactor replaces that with a unified Vec<LspNode> model where LSP nodes are added via add_lsp() and protocol support is discovered at runtime through LSPS0 list_protocols. Multi-LSP support has been requested previously in #529.

Deprecated set_liquidity_source_lsps1 / set_liquidity_source_lsps2 in favor of add_lsp()
Replaced the per-protocol LSPS1Client / LSPS2Client with global pending request maps keyed by LSPSRequestId
Added LSPS0 protocol discovery with event handling for ListProtocolsResponse
Background discovery task spawns on Node::start()
LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer
Added request_channel_from_lsp() for explicit LSPS1 LSP selection
Updated event handling to use is_lsps_node() for multi-LSP counterparty checks

This sets the foundation for LSPS5 support currently being worked on in #729

ldk-reviews-bot · 2026-02-12T10:42:38Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Camillarhi · 2026-02-12T10:45:04Z

@tnull Early draft up for review, would appreciate feedback on the general API direction

tnull

Thanks! Some initial questions..

tnull · 2026-02-25T10:26:40Z

+ supported_protocols: Mutex::new(None),
+ })
+ .collect(),
+ pending_lsps1_opening_params_requests: Mutex::new(HashMap::new()),


Uh, no, I don't think we should just merge all into one. Especially given that we intend to add more logic on a per-spec basis, this will be will become even more confusing going forward. If anything, we should maybe start the refactoring by first moving the LSPS1/LSPS2 specific parts to src/liquidity/{lsps1,lsps2}.rs, or maybe even to client/service specific sub-modules like src/liquidity/{client,service}/{lsps1,lsps2}.rs.

Alright, I will move the LSPS1/LSPS2 specific parts

tnull · 2026-02-25T10:29:54Z

 	pub(crate) async fn lsps1_request_channel(
 &self, lsp_balance_sat: u64, client_balance_sat: u64, channel_expiry_blocks: u32,
- announce_channel: bool, refund_address: bitcoin::Address,
+ announce_channel: bool, refund_address: bitcoin::Address, node_id: &PublicKey,


Hmm, I do wonder if it would make sense to create something like an struct ServiceProvider and move the API methods to there. Then, each registered LSP would have a corresponding ServiceProvider that exposes a bunch of public and internal APIs, which would make the modularization cleaner and would avoid having to give node_id everywhere?

Makes sense, I will have a look and see

Camillarhi · 2026-03-26T00:47:38Z

Hello @tnull, apologies for the delay. This is ready for another round of review

tnull

Cool, already looks pretty good! Did a first higher-level pass, have yet to look into the details.

tnull · 2026-03-27T08:02:00Z

@@ -1,1542 +0,0 @@
-// This file is Copyright its original authors, visible in version control history.


Would be good to structure this PR in a way that (as far as possible) makes any code moves dedicated commits that can be picked up by git diff --color-moved --patience, as otherwise reviewing this in detail will be very hard.

tnull · 2026-03-27T08:11:47Z

+ }
+ }
+
+ discovery_ls.discover_all_lsp_protocols().await;


I think it would be good to make this part of the background task above? Also, can we spawn the discovery tasks in parallel rather than doing them sequentially?

tnull · 2026-03-27T08:15:51Z

 	}
+
+	/// Configures the [`Node`] instance to source inbound liquidity from the given LSP at runtime,
+	/// without specifying the exact protocol used (e.g., LSPS1 or LSPS2).


I think we can drop the remark regarding 'without specifying the exact protocol' here and elsewhere, as the API already communicates that due to being generic. I do however wonder if we'd want to move this method to an API-extension object similar to what we do for the payment types? I.e., retrieve the API object via Node::liquidity()?

Thanks. I will remove the remark and move this to a Node::liquidity() API-extension

tnull · 2026-03-27T08:16:53Z

+/// [`Bolt11Payment::receive_via_jit_channel`]: crate::payment::Bolt11Payment::receive_via_jit_channel
+#[derive(Clone)]
+#[cfg_attr(feature = "uniffi", derive(uniffi::Object))]
+pub struct LSPS1Liquidity {


It seems this is currently not exposed in the API anymore?

tnull · 2026-03-27T08:17:50Z

 	/// The given `token` will be used by the LSP to authenticate the user.
 	///
 	/// [bLIP-51 / LSPS1]: https://github.com/lightning/blips/blob/master/blip-0051.md
+	#[deprecated(note = "Use `add_lsp` instead")]


Hmm, I think so far we've been fine with just breaking the APIs without deprecating them first. If we find a better API I'd be fine with just dropping the old ones to clean up.

tnull

Cool. Docs CI is currently failing.

Would be great if you try once more to breakup the second commit into smaller chunks, but let me know if it's too cumbersome/impossible.

Feel free to mark ready for review then.

ldk-reviews-bot · 2026-04-02T16:09:13Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-02T16:45:26Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-04T16:09:41Z

🔔 2nd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-04T16:45:53Z

🔔 2nd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T16:10:41Z

🔔 3rd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T16:46:54Z

🔔 3rd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-08T16:11:42Z

🔔 4th Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-08T16:47:56Z

🔔 4th Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-27T00:02:22Z

🔔 9th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-30T00:01:09Z

🔔 10th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-01T00:01:50Z

🔔 11th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-03T00:02:28Z

🔔 12th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-06T00:01:00Z

🔔 13th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-08T00:01:53Z

🔔 14th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-10T00:02:21Z

🔔 15th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Replace per-protocol single-LSP configuration `LSPS1Client` and `LSPS2Client` with a unified `Vec<LspNode>` model where users configure LSP nodes via `add_liquidity_source()` at build time or runtime and per-LSP protocol support is discovered via the LSPS0 `list_protocols`. - Introduce a per-LSP `trust_peer_0conf` flag to `LspConfig`/`LspNode` structs that controls whether 0-conf channels from that LSP are accepted - Add LSPS0 protocol discovery `discover_lsp_protocols` with event handling for `ListProtocolsResponse` - Update events to also use each LSP's `trust_peer_0conf` flag when deciding whether to allow 0-conf channels - Replace `set_liquidity_source_lsps1` and `set_liquidity_source_lsps2` builder methods with a single `add_liquidity_source()` that takes a `trust_peer_0conf` flag - Rename `set_liquidity_provider_lsps2` to `enable_liquidity_provider` - LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer across all of them - Spawn background discovery task on `Node::start()` and expose a watch channel so dependent flows can wait for discovery to complete - Add a new `Liquidity` handler `Node::liquidity()` exposing `add_liquidity_source()` API for adding LSPs at runtime, and `lsps1()` for the existing LSPS1 surface

Remove the `Ignoring` variant now that the liquidity source is always built, so the enum and its match arms are now pure overhead. Replace it with a struct that holds the `LiquiditySource` directly and have each trait method delegate straight to `liquidity_manager()`.

tnull

Thanks! Excuse the considerable delay here! I'm going ahead landing this, we can address / revisit minor things in follow-ups (or as part of #900 for instance).

tnull · 2026-06-12T09:31:06Z

-.and_then(|ls| ls.as_ref().get_lsps2_lsp_details())
+
+// If the peer is a configured LSP node, additionally honor its trust_peer_0conf flag.
+if let Some(lsp) =


Codex:
[P1] trust_peer_0conf is only honored for LSPS2-discovered LSPs: /home/tnull/worktrees/ldk-node/pr-792/src/event.rs:1323. add_liquidity_source(..., true) documents generic 0-conf trust for the LSP (/home/tnull/worktrees/ldk-node/pr-792/src/builder.rs:448, /home/tnull/worktrees/ldk-node/pr-
792/src/liquidity/mod.rs:117), but inbound acceptance only looks up protocol 2. LSPS1-only LSPs, or trusted LSPs before/after failed LSPS0 discovery, now fall through to accept_inbound_channel instead of accept_inbound_channel_from_trusted_peer. The trust lookup should be by node id
independent of protocol; keep the LSPS2 protocol check only for accept_underpaying_htlcs.

tnull · 2026-06-12T09:32:40Z

 where
 	L::Target: Logger,
 {
-	Ignoring,


Hmm, in conjunction with #900 we might want to revisit this, i.e., whether we'll want to allow to disable LSP functionalities based on a feature entirely.

tnull · 2026-06-12T09:33:11Z

+pub(crate) mod lsps1;
+pub(crate) mod lsps2;
+
+pub use lsps1::LSPS1OrderStatus;


nit:
[P3] Three new files have CRLF line endings, so git diff --check upstream/main...HEAD reports trailing whitespace on every line: /home/tnull/worktrees/ldk-node/pr-792/src/liquidity/client/mod.rs:1, /home/tnull/worktrees/ldk-node/pr-792/src/liquidity/service/mod.rs:1, /home/tnull/worktrees/
ldk-node/pr-792/src/liquidity/service/lsps2.rs:1. cargo fmt tolerates it, but diff whitespace checks will fail. Normalize those files to LF.

tnull · 2026-06-12T09:38:00Z

Now documented them over at #936.

Camillarhi · 2026-06-12T10:02:06Z

Thanks for landing it, and no worries about the delay! I'll pick up the follow-ups in #936

Follow-up to #792 (multi-LSP support)

Camillarhi · 2026-02-12T10:42:34Z

The current setup ties you to a single LSP per protocol via set_liquidity_source_lsps1 / set_liquidity_source_lsps2. This refactor replaces that with a unified Vec<LspNode> model where LSP nodes are added via add_lsp() and protocol support is discovered at runtime through LSPS0 list_protocols. Multi-LSP support has been requested previously in #529.

Deprecated set_liquidity_source_lsps1 / set_liquidity_source_lsps2 in favor of add_lsp()
Replaced the per-protocol LSPS1Client / LSPS2Client with global pending request maps keyed by LSPSRequestId
Added LSPS0 protocol discovery with event handling for ListProtocolsResponse
Background discovery task spawns on Node::start()
LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer
Added request_channel_from_lsp() for explicit LSPS1 LSP selection
Updated event handling to use is_lsps_node() for multi-LSP counterparty checks

This sets the foundation for LSPS5 support currently being worked on in #729

ldk-reviews-bot · 2026-02-12T10:42:38Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Camillarhi · 2026-02-12T10:45:04Z

@tnull Early draft up for review, would appreciate feedback on the general API direction

tnull

Thanks! Some initial questions..

tnull · 2026-02-25T10:26:40Z

+ supported_protocols: Mutex::new(None),
+ })
+ .collect(),
+ pending_lsps1_opening_params_requests: Mutex::new(HashMap::new()),


Uh, no, I don't think we should just merge all into one. Especially given that we intend to add more logic on a per-spec basis, this will be will become even more confusing going forward. If anything, we should maybe start the refactoring by first moving the LSPS1/LSPS2 specific parts to src/liquidity/{lsps1,lsps2}.rs, or maybe even to client/service specific sub-modules like src/liquidity/{client,service}/{lsps1,lsps2}.rs.

Alright, I will move the LSPS1/LSPS2 specific parts

tnull · 2026-02-25T10:29:54Z

 	pub(crate) async fn lsps1_request_channel(
 &self, lsp_balance_sat: u64, client_balance_sat: u64, channel_expiry_blocks: u32,
- announce_channel: bool, refund_address: bitcoin::Address,
+ announce_channel: bool, refund_address: bitcoin::Address, node_id: &PublicKey,


Hmm, I do wonder if it would make sense to create something like an struct ServiceProvider and move the API methods to there. Then, each registered LSP would have a corresponding ServiceProvider that exposes a bunch of public and internal APIs, which would make the modularization cleaner and would avoid having to give node_id everywhere?

Makes sense, I will have a look and see

Camillarhi · 2026-03-26T00:47:38Z

Hello @tnull, apologies for the delay. This is ready for another round of review

tnull

Cool, already looks pretty good! Did a first higher-level pass, have yet to look into the details.

tnull · 2026-03-27T08:02:00Z

@@ -1,1542 +0,0 @@
-// This file is Copyright its original authors, visible in version control history.


Would be good to structure this PR in a way that (as far as possible) makes any code moves dedicated commits that can be picked up by git diff --color-moved --patience, as otherwise reviewing this in detail will be very hard.

tnull · 2026-03-27T08:11:47Z

+ }
+ }
+
+ discovery_ls.discover_all_lsp_protocols().await;


I think it would be good to make this part of the background task above? Also, can we spawn the discovery tasks in parallel rather than doing them sequentially?

tnull · 2026-03-27T08:15:51Z

 	}
+
+	/// Configures the [`Node`] instance to source inbound liquidity from the given LSP at runtime,
+	/// without specifying the exact protocol used (e.g., LSPS1 or LSPS2).


I think we can drop the remark regarding 'without specifying the exact protocol' here and elsewhere, as the API already communicates that due to being generic. I do however wonder if we'd want to move this method to an API-extension object similar to what we do for the payment types? I.e., retrieve the API object via Node::liquidity()?

Thanks. I will remove the remark and move this to a Node::liquidity() API-extension

tnull · 2026-03-27T08:16:53Z

+/// [`Bolt11Payment::receive_via_jit_channel`]: crate::payment::Bolt11Payment::receive_via_jit_channel
+#[derive(Clone)]
+#[cfg_attr(feature = "uniffi", derive(uniffi::Object))]
+pub struct LSPS1Liquidity {


It seems this is currently not exposed in the API anymore?

tnull · 2026-03-27T08:17:50Z

 	/// The given `token` will be used by the LSP to authenticate the user.
 	///
 	/// [bLIP-51 / LSPS1]: https://github.com/lightning/blips/blob/master/blip-0051.md
+	#[deprecated(note = "Use `add_lsp` instead")]


Hmm, I think so far we've been fine with just breaking the APIs without deprecating them first. If we find a better API I'd be fine with just dropping the old ones to clean up.

tnull

Cool. Docs CI is currently failing.

Would be great if you try once more to breakup the second commit into smaller chunks, but let me know if it's too cumbersome/impossible.

Feel free to mark ready for review then.

ldk-reviews-bot · 2026-04-02T16:09:13Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-02T16:45:26Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-04T16:09:41Z

🔔 2nd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-04T16:45:53Z

🔔 2nd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T16:10:41Z

🔔 3rd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T16:46:54Z

🔔 3rd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-08T16:11:42Z

🔔 4th Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-08T16:47:56Z

🔔 4th Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-27T00:02:22Z

🔔 9th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-30T00:01:09Z

🔔 10th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-01T00:01:50Z

🔔 11th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-03T00:02:28Z

🔔 12th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-06T00:01:00Z

🔔 13th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-08T00:01:53Z

🔔 14th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-10T00:02:21Z

🔔 15th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Replace per-protocol single-LSP configuration `LSPS1Client` and `LSPS2Client` with a unified `Vec<LspNode>` model where users configure LSP nodes via `add_liquidity_source()` at build time or runtime and per-LSP protocol support is discovered via the LSPS0 `list_protocols`. - Introduce a per-LSP `trust_peer_0conf` flag to `LspConfig`/`LspNode` structs that controls whether 0-conf channels from that LSP are accepted - Add LSPS0 protocol discovery `discover_lsp_protocols` with event handling for `ListProtocolsResponse` - Update events to also use each LSP's `trust_peer_0conf` flag when deciding whether to allow 0-conf channels - Replace `set_liquidity_source_lsps1` and `set_liquidity_source_lsps2` builder methods with a single `add_liquidity_source()` that takes a `trust_peer_0conf` flag - Rename `set_liquidity_provider_lsps2` to `enable_liquidity_provider` - LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer across all of them - Spawn background discovery task on `Node::start()` and expose a watch channel so dependent flows can wait for discovery to complete - Add a new `Liquidity` handler `Node::liquidity()` exposing `add_liquidity_source()` API for adding LSPs at runtime, and `lsps1()` for the existing LSPS1 surface

Remove the `Ignoring` variant now that the liquidity source is always built, so the enum and its match arms are now pure overhead. Replace it with a struct that holds the `LiquiditySource` directly and have each trait method delegate straight to `liquidity_manager()`.

tnull

Thanks! Excuse the considerable delay here! I'm going ahead landing this, we can address / revisit minor things in follow-ups (or as part of #900 for instance).

tnull · 2026-06-12T09:31:06Z

-.and_then(|ls| ls.as_ref().get_lsps2_lsp_details())
+
+// If the peer is a configured LSP node, additionally honor its trust_peer_0conf flag.
+if let Some(lsp) =


Codex:
[P1] trust_peer_0conf is only honored for LSPS2-discovered LSPs: /home/tnull/worktrees/ldk-node/pr-792/src/event.rs:1323. add_liquidity_source(..., true) documents generic 0-conf trust for the LSP (/home/tnull/worktrees/ldk-node/pr-792/src/builder.rs:448, /home/tnull/worktrees/ldk-node/pr-
792/src/liquidity/mod.rs:117), but inbound acceptance only looks up protocol 2. LSPS1-only LSPs, or trusted LSPs before/after failed LSPS0 discovery, now fall through to accept_inbound_channel instead of accept_inbound_channel_from_trusted_peer. The trust lookup should be by node id
independent of protocol; keep the LSPS2 protocol check only for accept_underpaying_htlcs.

tnull · 2026-06-12T09:32:40Z

 where
 	L::Target: Logger,
 {
-	Ignoring,


Hmm, in conjunction with #900 we might want to revisit this, i.e., whether we'll want to allow to disable LSP functionalities based on a feature entirely.

tnull · 2026-06-12T09:33:11Z

+pub(crate) mod lsps1;
+pub(crate) mod lsps2;
+
+pub use lsps1::LSPS1OrderStatus;


nit:
[P3] Three new files have CRLF line endings, so git diff --check upstream/main...HEAD reports trailing whitespace on every line: /home/tnull/worktrees/ldk-node/pr-792/src/liquidity/client/mod.rs:1, /home/tnull/worktrees/ldk-node/pr-792/src/liquidity/service/mod.rs:1, /home/tnull/worktrees/
ldk-node/pr-792/src/liquidity/service/lsps2.rs:1. cargo fmt tolerates it, but diff whitespace checks will fail. Normalize those files to LF.

tnull · 2026-06-12T09:38:00Z

Now documented them over at #936.

Camillarhi · 2026-06-12T10:02:06Z

Thanks for landing it, and no worries about the delay! I'll pick up the follow-ups in #936

Follow-up to #792 (multi-LSP support)

Camillarhi · 2026-02-12T10:42:34Z

The current setup ties you to a single LSP per protocol via set_liquidity_source_lsps1 / set_liquidity_source_lsps2. This refactor replaces that with a unified Vec<LspNode> model where LSP nodes are added via add_lsp() and protocol support is discovered at runtime through LSPS0 list_protocols. Multi-LSP support has been requested previously in #529.

Deprecated set_liquidity_source_lsps1 / set_liquidity_source_lsps2 in favor of add_lsp()
Replaced the per-protocol LSPS1Client / LSPS2Client with global pending request maps keyed by LSPSRequestId
Added LSPS0 protocol discovery with event handling for ListProtocolsResponse
Background discovery task spawns on Node::start()
LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer
Added request_channel_from_lsp() for explicit LSPS1 LSP selection
Updated event handling to use is_lsps_node() for multi-LSP counterparty checks

This sets the foundation for LSPS5 support currently being worked on in #729

ldk-reviews-bot · 2026-02-12T10:42:38Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Camillarhi · 2026-02-12T10:45:04Z

@tnull Early draft up for review, would appreciate feedback on the general API direction

tnull

Thanks! Some initial questions..

tnull · 2026-02-25T10:26:40Z

+ supported_protocols: Mutex::new(None),
+ })
+ .collect(),
+ pending_lsps1_opening_params_requests: Mutex::new(HashMap::new()),


Uh, no, I don't think we should just merge all into one. Especially given that we intend to add more logic on a per-spec basis, this will be will become even more confusing going forward. If anything, we should maybe start the refactoring by first moving the LSPS1/LSPS2 specific parts to src/liquidity/{lsps1,lsps2}.rs, or maybe even to client/service specific sub-modules like src/liquidity/{client,service}/{lsps1,lsps2}.rs.

Alright, I will move the LSPS1/LSPS2 specific parts

tnull · 2026-02-25T10:29:54Z

 	pub(crate) async fn lsps1_request_channel(
 &self, lsp_balance_sat: u64, client_balance_sat: u64, channel_expiry_blocks: u32,
- announce_channel: bool, refund_address: bitcoin::Address,
+ announce_channel: bool, refund_address: bitcoin::Address, node_id: &PublicKey,


Hmm, I do wonder if it would make sense to create something like an struct ServiceProvider and move the API methods to there. Then, each registered LSP would have a corresponding ServiceProvider that exposes a bunch of public and internal APIs, which would make the modularization cleaner and would avoid having to give node_id everywhere?

Makes sense, I will have a look and see

Camillarhi · 2026-03-26T00:47:38Z

Hello @tnull, apologies for the delay. This is ready for another round of review

tnull

Cool, already looks pretty good! Did a first higher-level pass, have yet to look into the details.

tnull · 2026-03-27T08:02:00Z

@@ -1,1542 +0,0 @@
-// This file is Copyright its original authors, visible in version control history.


Would be good to structure this PR in a way that (as far as possible) makes any code moves dedicated commits that can be picked up by git diff --color-moved --patience, as otherwise reviewing this in detail will be very hard.

tnull · 2026-03-27T08:11:47Z

+ }
+ }
+
+ discovery_ls.discover_all_lsp_protocols().await;


I think it would be good to make this part of the background task above? Also, can we spawn the discovery tasks in parallel rather than doing them sequentially?

tnull · 2026-03-27T08:15:51Z

 	}
+
+	/// Configures the [`Node`] instance to source inbound liquidity from the given LSP at runtime,
+	/// without specifying the exact protocol used (e.g., LSPS1 or LSPS2).


I think we can drop the remark regarding 'without specifying the exact protocol' here and elsewhere, as the API already communicates that due to being generic. I do however wonder if we'd want to move this method to an API-extension object similar to what we do for the payment types? I.e., retrieve the API object via Node::liquidity()?

Thanks. I will remove the remark and move this to a Node::liquidity() API-extension

tnull · 2026-03-27T08:16:53Z

+/// [`Bolt11Payment::receive_via_jit_channel`]: crate::payment::Bolt11Payment::receive_via_jit_channel
+#[derive(Clone)]
+#[cfg_attr(feature = "uniffi", derive(uniffi::Object))]
+pub struct LSPS1Liquidity {


It seems this is currently not exposed in the API anymore?

tnull · 2026-03-27T08:17:50Z

 	/// The given `token` will be used by the LSP to authenticate the user.
 	///
 	/// [bLIP-51 / LSPS1]: https://github.com/lightning/blips/blob/master/blip-0051.md
+	#[deprecated(note = "Use `add_lsp` instead")]


Hmm, I think so far we've been fine with just breaking the APIs without deprecating them first. If we find a better API I'd be fine with just dropping the old ones to clean up.

tnull

Cool. Docs CI is currently failing.

Would be great if you try once more to breakup the second commit into smaller chunks, but let me know if it's too cumbersome/impossible.

Feel free to mark ready for review then.

ldk-reviews-bot · 2026-04-02T16:09:13Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-02T16:45:26Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-04T16:09:41Z

🔔 2nd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-04T16:45:53Z

🔔 2nd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T16:10:41Z

🔔 3rd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T16:46:54Z

🔔 3rd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-08T16:11:42Z

🔔 4th Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-08T16:47:56Z

🔔 4th Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-27T00:02:22Z

🔔 9th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-30T00:01:09Z

🔔 10th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-01T00:01:50Z

🔔 11th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-03T00:02:28Z

🔔 12th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-06T00:01:00Z

🔔 13th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-08T00:01:53Z

🔔 14th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-10T00:02:21Z

🔔 15th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Replace per-protocol single-LSP configuration `LSPS1Client` and `LSPS2Client` with a unified `Vec<LspNode>` model where users configure LSP nodes via `add_liquidity_source()` at build time or runtime and per-LSP protocol support is discovered via the LSPS0 `list_protocols`. - Introduce a per-LSP `trust_peer_0conf` flag to `LspConfig`/`LspNode` structs that controls whether 0-conf channels from that LSP are accepted - Add LSPS0 protocol discovery `discover_lsp_protocols` with event handling for `ListProtocolsResponse` - Update events to also use each LSP's `trust_peer_0conf` flag when deciding whether to allow 0-conf channels - Replace `set_liquidity_source_lsps1` and `set_liquidity_source_lsps2` builder methods with a single `add_liquidity_source()` that takes a `trust_peer_0conf` flag - Rename `set_liquidity_provider_lsps2` to `enable_liquidity_provider` - LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer across all of them - Spawn background discovery task on `Node::start()` and expose a watch channel so dependent flows can wait for discovery to complete - Add a new `Liquidity` handler `Node::liquidity()` exposing `add_liquidity_source()` API for adding LSPs at runtime, and `lsps1()` for the existing LSPS1 surface

Remove the `Ignoring` variant now that the liquidity source is always built, so the enum and its match arms are now pure overhead. Replace it with a struct that holds the `LiquiditySource` directly and have each trait method delegate straight to `liquidity_manager()`.

tnull

Thanks! Excuse the considerable delay here! I'm going ahead landing this, we can address / revisit minor things in follow-ups (or as part of #900 for instance).

tnull · 2026-06-12T09:31:06Z

-.and_then(|ls| ls.as_ref().get_lsps2_lsp_details())
+
+// If the peer is a configured LSP node, additionally honor its trust_peer_0conf flag.
+if let Some(lsp) =


Codex:
[P1] trust_peer_0conf is only honored for LSPS2-discovered LSPs: /home/tnull/worktrees/ldk-node/pr-792/src/event.rs:1323. add_liquidity_source(..., true) documents generic 0-conf trust for the LSP (/home/tnull/worktrees/ldk-node/pr-792/src/builder.rs:448, /home/tnull/worktrees/ldk-node/pr-
792/src/liquidity/mod.rs:117), but inbound acceptance only looks up protocol 2. LSPS1-only LSPs, or trusted LSPs before/after failed LSPS0 discovery, now fall through to accept_inbound_channel instead of accept_inbound_channel_from_trusted_peer. The trust lookup should be by node id
independent of protocol; keep the LSPS2 protocol check only for accept_underpaying_htlcs.

tnull · 2026-06-12T09:32:40Z

 where
 	L::Target: Logger,
 {
-	Ignoring,


Hmm, in conjunction with #900 we might want to revisit this, i.e., whether we'll want to allow to disable LSP functionalities based on a feature entirely.

tnull · 2026-06-12T09:33:11Z

+pub(crate) mod lsps1;
+pub(crate) mod lsps2;
+
+pub use lsps1::LSPS1OrderStatus;


nit:
[P3] Three new files have CRLF line endings, so git diff --check upstream/main...HEAD reports trailing whitespace on every line: /home/tnull/worktrees/ldk-node/pr-792/src/liquidity/client/mod.rs:1, /home/tnull/worktrees/ldk-node/pr-792/src/liquidity/service/mod.rs:1, /home/tnull/worktrees/
ldk-node/pr-792/src/liquidity/service/lsps2.rs:1. cargo fmt tolerates it, but diff whitespace checks will fail. Normalize those files to LF.

tnull · 2026-06-12T09:38:00Z

Now documented them over at #936.

Camillarhi · 2026-06-12T10:02:06Z

Thanks for landing it, and no worries about the delay! I'll pick up the follow-ups in #936

Follow-up to #792 (multi-LSP support)

Camillarhi · 2026-02-12T10:42:34Z

The current setup ties you to a single LSP per protocol via set_liquidity_source_lsps1 / set_liquidity_source_lsps2. This refactor replaces that with a unified Vec<LspNode> model where LSP nodes are added via add_lsp() and protocol support is discovered at runtime through LSPS0 list_protocols. Multi-LSP support has been requested previously in #529.

Deprecated set_liquidity_source_lsps1 / set_liquidity_source_lsps2 in favor of add_lsp()
Replaced the per-protocol LSPS1Client / LSPS2Client with global pending request maps keyed by LSPSRequestId
Added LSPS0 protocol discovery with event handling for ListProtocolsResponse
Background discovery task spawns on Node::start()
LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer
Added request_channel_from_lsp() for explicit LSPS1 LSP selection
Updated event handling to use is_lsps_node() for multi-LSP counterparty checks

This sets the foundation for LSPS5 support currently being worked on in #729

ldk-reviews-bot · 2026-02-12T10:42:38Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Camillarhi · 2026-02-12T10:45:04Z

@tnull Early draft up for review, would appreciate feedback on the general API direction

tnull

Thanks! Some initial questions..

tnull · 2026-02-25T10:26:40Z

+ supported_protocols: Mutex::new(None),
+ })
+ .collect(),
+ pending_lsps1_opening_params_requests: Mutex::new(HashMap::new()),


Uh, no, I don't think we should just merge all into one. Especially given that we intend to add more logic on a per-spec basis, this will be will become even more confusing going forward. If anything, we should maybe start the refactoring by first moving the LSPS1/LSPS2 specific parts to src/liquidity/{lsps1,lsps2}.rs, or maybe even to client/service specific sub-modules like src/liquidity/{client,service}/{lsps1,lsps2}.rs.

Alright, I will move the LSPS1/LSPS2 specific parts

tnull · 2026-02-25T10:29:54Z

 	pub(crate) async fn lsps1_request_channel(
 &self, lsp_balance_sat: u64, client_balance_sat: u64, channel_expiry_blocks: u32,
- announce_channel: bool, refund_address: bitcoin::Address,
+ announce_channel: bool, refund_address: bitcoin::Address, node_id: &PublicKey,


Hmm, I do wonder if it would make sense to create something like an struct ServiceProvider and move the API methods to there. Then, each registered LSP would have a corresponding ServiceProvider that exposes a bunch of public and internal APIs, which would make the modularization cleaner and would avoid having to give node_id everywhere?

Makes sense, I will have a look and see

Camillarhi · 2026-03-26T00:47:38Z

Hello @tnull, apologies for the delay. This is ready for another round of review

tnull

Cool, already looks pretty good! Did a first higher-level pass, have yet to look into the details.

tnull · 2026-03-27T08:02:00Z

@@ -1,1542 +0,0 @@
-// This file is Copyright its original authors, visible in version control history.


Would be good to structure this PR in a way that (as far as possible) makes any code moves dedicated commits that can be picked up by git diff --color-moved --patience, as otherwise reviewing this in detail will be very hard.

tnull · 2026-03-27T08:11:47Z

+ }
+ }
+
+ discovery_ls.discover_all_lsp_protocols().await;


I think it would be good to make this part of the background task above? Also, can we spawn the discovery tasks in parallel rather than doing them sequentially?

tnull · 2026-03-27T08:15:51Z

 	}
+
+	/// Configures the [`Node`] instance to source inbound liquidity from the given LSP at runtime,
+	/// without specifying the exact protocol used (e.g., LSPS1 or LSPS2).


I think we can drop the remark regarding 'without specifying the exact protocol' here and elsewhere, as the API already communicates that due to being generic. I do however wonder if we'd want to move this method to an API-extension object similar to what we do for the payment types? I.e., retrieve the API object via Node::liquidity()?

Thanks. I will remove the remark and move this to a Node::liquidity() API-extension

tnull · 2026-03-27T08:16:53Z

+/// [`Bolt11Payment::receive_via_jit_channel`]: crate::payment::Bolt11Payment::receive_via_jit_channel
+#[derive(Clone)]
+#[cfg_attr(feature = "uniffi", derive(uniffi::Object))]
+pub struct LSPS1Liquidity {


It seems this is currently not exposed in the API anymore?

tnull · 2026-03-27T08:17:50Z

 	/// The given `token` will be used by the LSP to authenticate the user.
 	///
 	/// [bLIP-51 / LSPS1]: https://github.com/lightning/blips/blob/master/blip-0051.md
+	#[deprecated(note = "Use `add_lsp` instead")]


Hmm, I think so far we've been fine with just breaking the APIs without deprecating them first. If we find a better API I'd be fine with just dropping the old ones to clean up.

tnull

Cool. Docs CI is currently failing.

Would be great if you try once more to breakup the second commit into smaller chunks, but let me know if it's too cumbersome/impossible.

Feel free to mark ready for review then.

ldk-reviews-bot · 2026-04-02T16:09:13Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-02T16:45:26Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-04T16:09:41Z

🔔 2nd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-04T16:45:53Z

🔔 2nd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T16:10:41Z

🔔 3rd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T16:46:54Z

🔔 3rd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-08T16:11:42Z

🔔 4th Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-08T16:47:56Z

🔔 4th Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-27T00:02:22Z

🔔 9th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-30T00:01:09Z

🔔 10th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-01T00:01:50Z

🔔 11th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-03T00:02:28Z

🔔 12th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-06T00:01:00Z

🔔 13th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-08T00:01:53Z

🔔 14th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-10T00:02:21Z

🔔 15th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Replace per-protocol single-LSP configuration `LSPS1Client` and `LSPS2Client` with a unified `Vec<LspNode>` model where users configure LSP nodes via `add_liquidity_source()` at build time or runtime and per-LSP protocol support is discovered via the LSPS0 `list_protocols`. - Introduce a per-LSP `trust_peer_0conf` flag to `LspConfig`/`LspNode` structs that controls whether 0-conf channels from that LSP are accepted - Add LSPS0 protocol discovery `discover_lsp_protocols` with event handling for `ListProtocolsResponse` - Update events to also use each LSP's `trust_peer_0conf` flag when deciding whether to allow 0-conf channels - Replace `set_liquidity_source_lsps1` and `set_liquidity_source_lsps2` builder methods with a single `add_liquidity_source()` that takes a `trust_peer_0conf` flag - Rename `set_liquidity_provider_lsps2` to `enable_liquidity_provider` - LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer across all of them - Spawn background discovery task on `Node::start()` and expose a watch channel so dependent flows can wait for discovery to complete - Add a new `Liquidity` handler `Node::liquidity()` exposing `add_liquidity_source()` API for adding LSPs at runtime, and `lsps1()` for the existing LSPS1 surface

Remove the `Ignoring` variant now that the liquidity source is always built, so the enum and its match arms are now pure overhead. Replace it with a struct that holds the `LiquiditySource` directly and have each trait method delegate straight to `liquidity_manager()`.

tnull

Thanks! Excuse the considerable delay here! I'm going ahead landing this, we can address / revisit minor things in follow-ups (or as part of #900 for instance).

tnull · 2026-06-12T09:31:06Z

-.and_then(|ls| ls.as_ref().get_lsps2_lsp_details())
+
+// If the peer is a configured LSP node, additionally honor its trust_peer_0conf flag.
+if let Some(lsp) =


Codex:
[P1] trust_peer_0conf is only honored for LSPS2-discovered LSPs: /home/tnull/worktrees/ldk-node/pr-792/src/event.rs:1323. add_liquidity_source(..., true) documents generic 0-conf trust for the LSP (/home/tnull/worktrees/ldk-node/pr-792/src/builder.rs:448, /home/tnull/worktrees/ldk-node/pr-
792/src/liquidity/mod.rs:117), but inbound acceptance only looks up protocol 2. LSPS1-only LSPs, or trusted LSPs before/after failed LSPS0 discovery, now fall through to accept_inbound_channel instead of accept_inbound_channel_from_trusted_peer. The trust lookup should be by node id
independent of protocol; keep the LSPS2 protocol check only for accept_underpaying_htlcs.

tnull · 2026-06-12T09:32:40Z

 where
 	L::Target: Logger,
 {
-	Ignoring,


Hmm, in conjunction with #900 we might want to revisit this, i.e., whether we'll want to allow to disable LSP functionalities based on a feature entirely.

tnull · 2026-06-12T09:33:11Z

+pub(crate) mod lsps1;
+pub(crate) mod lsps2;
+
+pub use lsps1::LSPS1OrderStatus;


nit:
[P3] Three new files have CRLF line endings, so git diff --check upstream/main...HEAD reports trailing whitespace on every line: /home/tnull/worktrees/ldk-node/pr-792/src/liquidity/client/mod.rs:1, /home/tnull/worktrees/ldk-node/pr-792/src/liquidity/service/mod.rs:1, /home/tnull/worktrees/
ldk-node/pr-792/src/liquidity/service/lsps2.rs:1. cargo fmt tolerates it, but diff whitespace checks will fail. Normalize those files to LF.

tnull · 2026-06-12T09:38:00Z

Now documented them over at #936.

Camillarhi · 2026-06-12T10:02:06Z

Thanks for landing it, and no worries about the delay! I'll pick up the follow-ups in #936

Follow-up to #792 (multi-LSP support)

Camillarhi · 2026-02-12T10:42:34Z

The current setup ties you to a single LSP per protocol via set_liquidity_source_lsps1 / set_liquidity_source_lsps2. This refactor replaces that with a unified Vec<LspNode> model where LSP nodes are added via add_lsp() and protocol support is discovered at runtime through LSPS0 list_protocols. Multi-LSP support has been requested previously in #529.

Deprecated set_liquidity_source_lsps1 / set_liquidity_source_lsps2 in favor of add_lsp()
Replaced the per-protocol LSPS1Client / LSPS2Client with global pending request maps keyed by LSPSRequestId
Added LSPS0 protocol discovery with event handling for ListProtocolsResponse
Background discovery task spawns on Node::start()
LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer
Added request_channel_from_lsp() for explicit LSPS1 LSP selection
Updated event handling to use is_lsps_node() for multi-LSP counterparty checks

This sets the foundation for LSPS5 support currently being worked on in #729

ldk-reviews-bot · 2026-02-12T10:42:38Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Camillarhi · 2026-02-12T10:45:04Z

@tnull Early draft up for review, would appreciate feedback on the general API direction

tnull

Thanks! Some initial questions..

tnull · 2026-02-25T10:26:40Z

+ supported_protocols: Mutex::new(None),
+ })
+ .collect(),
+ pending_lsps1_opening_params_requests: Mutex::new(HashMap::new()),


Uh, no, I don't think we should just merge all into one. Especially given that we intend to add more logic on a per-spec basis, this will be will become even more confusing going forward. If anything, we should maybe start the refactoring by first moving the LSPS1/LSPS2 specific parts to src/liquidity/{lsps1,lsps2}.rs, or maybe even to client/service specific sub-modules like src/liquidity/{client,service}/{lsps1,lsps2}.rs.

Alright, I will move the LSPS1/LSPS2 specific parts

tnull · 2026-02-25T10:29:54Z

 	pub(crate) async fn lsps1_request_channel(
 &self, lsp_balance_sat: u64, client_balance_sat: u64, channel_expiry_blocks: u32,
- announce_channel: bool, refund_address: bitcoin::Address,
+ announce_channel: bool, refund_address: bitcoin::Address, node_id: &PublicKey,


Hmm, I do wonder if it would make sense to create something like an struct ServiceProvider and move the API methods to there. Then, each registered LSP would have a corresponding ServiceProvider that exposes a bunch of public and internal APIs, which would make the modularization cleaner and would avoid having to give node_id everywhere?

Makes sense, I will have a look and see

Camillarhi · 2026-03-26T00:47:38Z

Hello @tnull, apologies for the delay. This is ready for another round of review

tnull

Cool, already looks pretty good! Did a first higher-level pass, have yet to look into the details.

tnull · 2026-03-27T08:02:00Z

@@ -1,1542 +0,0 @@
-// This file is Copyright its original authors, visible in version control history.


Would be good to structure this PR in a way that (as far as possible) makes any code moves dedicated commits that can be picked up by git diff --color-moved --patience, as otherwise reviewing this in detail will be very hard.

tnull · 2026-03-27T08:11:47Z

+ }
+ }
+
+ discovery_ls.discover_all_lsp_protocols().await;


I think it would be good to make this part of the background task above? Also, can we spawn the discovery tasks in parallel rather than doing them sequentially?

tnull · 2026-03-27T08:15:51Z

 	}
+
+	/// Configures the [`Node`] instance to source inbound liquidity from the given LSP at runtime,
+	/// without specifying the exact protocol used (e.g., LSPS1 or LSPS2).


I think we can drop the remark regarding 'without specifying the exact protocol' here and elsewhere, as the API already communicates that due to being generic. I do however wonder if we'd want to move this method to an API-extension object similar to what we do for the payment types? I.e., retrieve the API object via Node::liquidity()?

Thanks. I will remove the remark and move this to a Node::liquidity() API-extension

tnull · 2026-03-27T08:16:53Z

+/// [`Bolt11Payment::receive_via_jit_channel`]: crate::payment::Bolt11Payment::receive_via_jit_channel
+#[derive(Clone)]
+#[cfg_attr(feature = "uniffi", derive(uniffi::Object))]
+pub struct LSPS1Liquidity {


It seems this is currently not exposed in the API anymore?

tnull · 2026-03-27T08:17:50Z

 	/// The given `token` will be used by the LSP to authenticate the user.
 	///
 	/// [bLIP-51 / LSPS1]: https://github.com/lightning/blips/blob/master/blip-0051.md
+	#[deprecated(note = "Use `add_lsp` instead")]


Hmm, I think so far we've been fine with just breaking the APIs without deprecating them first. If we find a better API I'd be fine with just dropping the old ones to clean up.

tnull

Cool. Docs CI is currently failing.

Would be great if you try once more to breakup the second commit into smaller chunks, but let me know if it's too cumbersome/impossible.

Feel free to mark ready for review then.

ldk-reviews-bot · 2026-04-02T16:09:13Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-02T16:45:26Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-04T16:09:41Z

🔔 2nd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-04T16:45:53Z

🔔 2nd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T16:10:41Z

🔔 3rd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T16:46:54Z

🔔 3rd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-08T16:11:42Z

🔔 4th Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-08T16:47:56Z

🔔 4th Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-27T00:02:22Z

🔔 9th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-30T00:01:09Z

🔔 10th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-01T00:01:50Z

🔔 11th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-03T00:02:28Z

🔔 12th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-06T00:01:00Z

🔔 13th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-08T00:01:53Z

🔔 14th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-10T00:02:21Z

🔔 15th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Replace per-protocol single-LSP configuration `LSPS1Client` and `LSPS2Client` with a unified `Vec<LspNode>` model where users configure LSP nodes via `add_liquidity_source()` at build time or runtime and per-LSP protocol support is discovered via the LSPS0 `list_protocols`. - Introduce a per-LSP `trust_peer_0conf` flag to `LspConfig`/`LspNode` structs that controls whether 0-conf channels from that LSP are accepted - Add LSPS0 protocol discovery `discover_lsp_protocols` with event handling for `ListProtocolsResponse` - Update events to also use each LSP's `trust_peer_0conf` flag when deciding whether to allow 0-conf channels - Replace `set_liquidity_source_lsps1` and `set_liquidity_source_lsps2` builder methods with a single `add_liquidity_source()` that takes a `trust_peer_0conf` flag - Rename `set_liquidity_provider_lsps2` to `enable_liquidity_provider` - LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer across all of them - Spawn background discovery task on `Node::start()` and expose a watch channel so dependent flows can wait for discovery to complete - Add a new `Liquidity` handler `Node::liquidity()` exposing `add_liquidity_source()` API for adding LSPs at runtime, and `lsps1()` for the existing LSPS1 surface

Remove the `Ignoring` variant now that the liquidity source is always built, so the enum and its match arms are now pure overhead. Replace it with a struct that holds the `LiquiditySource` directly and have each trait method delegate straight to `liquidity_manager()`.

tnull

Thanks! Excuse the considerable delay here! I'm going ahead landing this, we can address / revisit minor things in follow-ups (or as part of #900 for instance).

tnull · 2026-06-12T09:31:06Z

-.and_then(|ls| ls.as_ref().get_lsps2_lsp_details())
+
+// If the peer is a configured LSP node, additionally honor its trust_peer_0conf flag.
+if let Some(lsp) =


Codex:
[P1] trust_peer_0conf is only honored for LSPS2-discovered LSPs: /home/tnull/worktrees/ldk-node/pr-792/src/event.rs:1323. add_liquidity_source(..., true) documents generic 0-conf trust for the LSP (/home/tnull/worktrees/ldk-node/pr-792/src/builder.rs:448, /home/tnull/worktrees/ldk-node/pr-
792/src/liquidity/mod.rs:117), but inbound acceptance only looks up protocol 2. LSPS1-only LSPs, or trusted LSPs before/after failed LSPS0 discovery, now fall through to accept_inbound_channel instead of accept_inbound_channel_from_trusted_peer. The trust lookup should be by node id
independent of protocol; keep the LSPS2 protocol check only for accept_underpaying_htlcs.

tnull · 2026-06-12T09:32:40Z

 where
 	L::Target: Logger,
 {
-	Ignoring,


Hmm, in conjunction with #900 we might want to revisit this, i.e., whether we'll want to allow to disable LSP functionalities based on a feature entirely.

tnull · 2026-06-12T09:33:11Z

+pub(crate) mod lsps1;
+pub(crate) mod lsps2;
+
+pub use lsps1::LSPS1OrderStatus;


nit:
[P3] Three new files have CRLF line endings, so git diff --check upstream/main...HEAD reports trailing whitespace on every line: /home/tnull/worktrees/ldk-node/pr-792/src/liquidity/client/mod.rs:1, /home/tnull/worktrees/ldk-node/pr-792/src/liquidity/service/mod.rs:1, /home/tnull/worktrees/
ldk-node/pr-792/src/liquidity/service/lsps2.rs:1. cargo fmt tolerates it, but diff whitespace checks will fail. Normalize those files to LF.

tnull · 2026-06-12T09:38:00Z

Now documented them over at #936.

Camillarhi · 2026-06-12T10:02:06Z

Thanks for landing it, and no worries about the delay! I'll pick up the follow-ups in #936

Follow-up to #792 (multi-LSP support)

Camillarhi · 2026-02-12T10:42:34Z

The current setup ties you to a single LSP per protocol via set_liquidity_source_lsps1 / set_liquidity_source_lsps2. This refactor replaces that with a unified Vec<LspNode> model where LSP nodes are added via add_lsp() and protocol support is discovered at runtime through LSPS0 list_protocols. Multi-LSP support has been requested previously in #529.

Deprecated set_liquidity_source_lsps1 / set_liquidity_source_lsps2 in favor of add_lsp()
Replaced the per-protocol LSPS1Client / LSPS2Client with global pending request maps keyed by LSPSRequestId
Added LSPS0 protocol discovery with event handling for ListProtocolsResponse
Background discovery task spawns on Node::start()
LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer
Added request_channel_from_lsp() for explicit LSPS1 LSP selection
Updated event handling to use is_lsps_node() for multi-LSP counterparty checks

This sets the foundation for LSPS5 support currently being worked on in #729

ldk-reviews-bot · 2026-02-12T10:42:38Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Camillarhi · 2026-02-12T10:45:04Z

@tnull Early draft up for review, would appreciate feedback on the general API direction

tnull

Thanks! Some initial questions..

tnull · 2026-02-25T10:26:40Z

+ supported_protocols: Mutex::new(None),
+ })
+ .collect(),
+ pending_lsps1_opening_params_requests: Mutex::new(HashMap::new()),


Uh, no, I don't think we should just merge all into one. Especially given that we intend to add more logic on a per-spec basis, this will be will become even more confusing going forward. If anything, we should maybe start the refactoring by first moving the LSPS1/LSPS2 specific parts to src/liquidity/{lsps1,lsps2}.rs, or maybe even to client/service specific sub-modules like src/liquidity/{client,service}/{lsps1,lsps2}.rs.

Alright, I will move the LSPS1/LSPS2 specific parts

tnull · 2026-02-25T10:29:54Z

 	pub(crate) async fn lsps1_request_channel(
 &self, lsp_balance_sat: u64, client_balance_sat: u64, channel_expiry_blocks: u32,
- announce_channel: bool, refund_address: bitcoin::Address,
+ announce_channel: bool, refund_address: bitcoin::Address, node_id: &PublicKey,


Hmm, I do wonder if it would make sense to create something like an struct ServiceProvider and move the API methods to there. Then, each registered LSP would have a corresponding ServiceProvider that exposes a bunch of public and internal APIs, which would make the modularization cleaner and would avoid having to give node_id everywhere?

Makes sense, I will have a look and see

Camillarhi · 2026-03-26T00:47:38Z

Hello @tnull, apologies for the delay. This is ready for another round of review

tnull

Cool, already looks pretty good! Did a first higher-level pass, have yet to look into the details.

tnull · 2026-03-27T08:02:00Z

@@ -1,1542 +0,0 @@
-// This file is Copyright its original authors, visible in version control history.


Would be good to structure this PR in a way that (as far as possible) makes any code moves dedicated commits that can be picked up by git diff --color-moved --patience, as otherwise reviewing this in detail will be very hard.

tnull · 2026-03-27T08:11:47Z

+ }
+ }
+
+ discovery_ls.discover_all_lsp_protocols().await;


I think it would be good to make this part of the background task above? Also, can we spawn the discovery tasks in parallel rather than doing them sequentially?

tnull · 2026-03-27T08:15:51Z

 	}
+
+	/// Configures the [`Node`] instance to source inbound liquidity from the given LSP at runtime,
+	/// without specifying the exact protocol used (e.g., LSPS1 or LSPS2).


I think we can drop the remark regarding 'without specifying the exact protocol' here and elsewhere, as the API already communicates that due to being generic. I do however wonder if we'd want to move this method to an API-extension object similar to what we do for the payment types? I.e., retrieve the API object via Node::liquidity()?

Thanks. I will remove the remark and move this to a Node::liquidity() API-extension

tnull · 2026-03-27T08:16:53Z

+/// [`Bolt11Payment::receive_via_jit_channel`]: crate::payment::Bolt11Payment::receive_via_jit_channel
+#[derive(Clone)]
+#[cfg_attr(feature = "uniffi", derive(uniffi::Object))]
+pub struct LSPS1Liquidity {


It seems this is currently not exposed in the API anymore?

tnull · 2026-03-27T08:17:50Z

 	/// The given `token` will be used by the LSP to authenticate the user.
 	///
 	/// [bLIP-51 / LSPS1]: https://github.com/lightning/blips/blob/master/blip-0051.md
+	#[deprecated(note = "Use `add_lsp` instead")]


Hmm, I think so far we've been fine with just breaking the APIs without deprecating them first. If we find a better API I'd be fine with just dropping the old ones to clean up.

tnull

Cool. Docs CI is currently failing.

Would be great if you try once more to breakup the second commit into smaller chunks, but let me know if it's too cumbersome/impossible.

Feel free to mark ready for review then.

ldk-reviews-bot · 2026-04-02T16:09:13Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-02T16:45:26Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-04T16:09:41Z

🔔 2nd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-04T16:45:53Z

🔔 2nd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T16:10:41Z

🔔 3rd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T16:46:54Z

🔔 3rd Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-08T16:11:42Z

🔔 4th Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-08T16:47:56Z

🔔 4th Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-27T00:02:22Z

🔔 9th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-30T00:01:09Z

🔔 10th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-01T00:01:50Z

🔔 11th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-03T00:02:28Z

🔔 12th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-06T00:01:00Z

🔔 13th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-08T00:01:53Z

🔔 14th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-10T00:02:21Z

🔔 15th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Replace per-protocol single-LSP configuration `LSPS1Client` and `LSPS2Client` with a unified `Vec<LspNode>` model where users configure LSP nodes via `add_liquidity_source()` at build time or runtime and per-LSP protocol support is discovered via the LSPS0 `list_protocols`. - Introduce a per-LSP `trust_peer_0conf` flag to `LspConfig`/`LspNode` structs that controls whether 0-conf channels from that LSP are accepted - Add LSPS0 protocol discovery `discover_lsp_protocols` with event handling for `ListProtocolsResponse` - Update events to also use each LSP's `trust_peer_0conf` flag when deciding whether to allow 0-conf channels - Replace `set_liquidity_source_lsps1` and `set_liquidity_source_lsps2` builder methods with a single `add_liquidity_source()` that takes a `trust_peer_0conf` flag - Rename `set_liquidity_provider_lsps2` to `enable_liquidity_provider` - LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer across all of them - Spawn background discovery task on `Node::start()` and expose a watch channel so dependent flows can wait for discovery to complete - Add a new `Liquidity` handler `Node::liquidity()` exposing `add_liquidity_source()` API for adding LSPs at runtime, and `lsps1()` for the existing LSPS1 surface

Remove the `Ignoring` variant now that the liquidity source is always built, so the enum and its match arms are now pure overhead. Replace it with a struct that holds the `LiquiditySource` directly and have each trait method delegate straight to `liquidity_manager()`.

tnull

Thanks! Excuse the considerable delay here! I'm going ahead landing this, we can address / revisit minor things in follow-ups (or as part of #900 for instance).

tnull · 2026-06-12T09:31:06Z

-.and_then(|ls| ls.as_ref().get_lsps2_lsp_details())
+
+// If the peer is a configured LSP node, additionally honor its trust_peer_0conf flag.
+if let Some(lsp) =


Codex:
[P1] trust_peer_0conf is only honored for LSPS2-discovered LSPs: /home/tnull/worktrees/ldk-node/pr-792/src/event.rs:1323. add_liquidity_source(..., true) documents generic 0-conf trust for the LSP (/home/tnull/worktrees/ldk-node/pr-792/src/builder.rs:448, /home/tnull/worktrees/ldk-node/pr-
792/src/liquidity/mod.rs:117), but inbound acceptance only looks up protocol 2. LSPS1-only LSPs, or trusted LSPs before/after failed LSPS0 discovery, now fall through to accept_inbound_channel instead of accept_inbound_channel_from_trusted_peer. The trust lookup should be by node id
independent of protocol; keep the LSPS2 protocol check only for accept_underpaying_htlcs.

tnull · 2026-06-12T09:32:40Z

 where
 	L::Target: Logger,
 {
-	Ignoring,


Hmm, in conjunction with #900 we might want to revisit this, i.e., whether we'll want to allow to disable LSP functionalities based on a feature entirely.

tnull · 2026-06-12T09:33:11Z

+pub(crate) mod lsps1;
+pub(crate) mod lsps2;
+
+pub use lsps1::LSPS1OrderStatus;


nit:
[P3] Three new files have CRLF line endings, so git diff --check upstream/main...HEAD reports trailing whitespace on every line: /home/tnull/worktrees/ldk-node/pr-792/src/liquidity/client/mod.rs:1, /home/tnull/worktrees/ldk-node/pr-792/src/liquidity/service/mod.rs:1, /home/tnull/worktrees/
ldk-node/pr-792/src/liquidity/service/lsps2.rs:1. cargo fmt tolerates it, but diff whitespace checks will fail. Normalize those files to LF.

tnull · 2026-06-12T09:38:00Z

Now documented them over at #936.

Camillarhi · 2026-06-12T10:02:06Z

Thanks for landing it, and no worries about the delay! I'll pick up the follow-ups in #936

Follow-up to #792 (multi-LSP support)

tnull self-requested a review February 24, 2026 16:28

tnull reviewed Feb 25, 2026
View reviewed changes

Camillarhi force-pushed the multi-lsp-support branch 2 times, most recently from 3cda7f7 to 8bbf55aCompare March 26, 2026 00:46

Camillarhi requested a review from tnull March 26, 2026 00:47

Camillarhi force-pushed the multi-lsp-support branch from 8bbf55a to ea93afeCompare March 26, 2026 01:18

tnull reviewed Mar 27, 2026
View reviewed changes

Camillarhi force-pushed the multi-lsp-support branch 2 times, most recently from 6061c6d to a560764Compare March 30, 2026 16:32

Camillarhi requested a review from tnull March 30, 2026 16:32

tnull reviewed Mar 31, 2026
View reviewed changes

Camillarhi force-pushed the multi-lsp-support branch from a560764 to c430e51Compare March 31, 2026 16:07

Camillarhi marked this pull request as ready for review March 31, 2026 16:07

ldk-reviews-bot requested a review from valentinewallace March 31, 2026 16:08

Camillarhi requested a review from tnull March 31, 2026 16:45

tnull mentioned this pull request Apr 1, 2026
LSPS5 Notifications for Pending HTLCs #762
Open

Camillarhi force-pushed the multi-lsp-support branch 2 times, most recently from 22da16c to 2cda868Compare April 9, 2026 15:16

valentinewallace removed their request for review April 9, 2026 15:37

Camillarhi force-pushed the multi-lsp-support branch 2 times, most recently from 43c5ccc to 7ceb385Compare June 2, 2026 12:12

Camillarhi mentioned this pull request Jun 3, 2026
An option to change the LSP token after init lightningdevkit/orange-sdk#38
Open

Camillarhi force-pushed the multi-lsp-support branch from 7ceb385 to e3b8933Compare June 3, 2026 00:25

Camillarhi added 9 commits June 10, 2026 17:00

Move liquidity.rs to liquidity/mod.rs module directory
0713f6d

Move LSPS1 client logic into liquidity/client/lsps1.rs
07dbde9

Move LSPS1 client event handling into liquidity/client/lsps1.rs
7890b78

Move LSPS2 client logic into liquidity/client/lsps2.rs
cab8892

Move LSPS2 client event handling into liquidity/client/lsps2.rs
1f02b86

Move LSPS2 service logic into liquidity/service/lsps2.rs
aa2cbfb

Move LSPS2 service event handling into liquidity/service/lsps2.rs
96ba539

Camillarhi force-pushed the multi-lsp-support branch from e3b8933 to 5191217Compare June 10, 2026 16:06

tnull approved these changes Jun 12, 2026
View reviewed changes

tnull merged commit 926c18a into lightningdevkit:mainJun 12, 2026

tnull mentioned this pull request Jun 12, 2026
Multi-LSP support #529
Closed

Camillarhi mentioned this pull request Jun 13, 2026
LSPS1 service integration tracking issue #917
Open
5 tasks

Camillarhi mentioned this pull request Jul 1, 2026
Follow-up to #792 (multi-LSP support) #956
Merged

f3r10 mentioned this pull request Jul 17, 2026
chore: upgrade ldk-node to latest main (056447c2) and migrate deprecated liquidity APIs f3r10/lightning-ecommerce#59
Closed
6 tasks

tnull added a commit that referenced this pull request Jul 21, 2026
Merge pull request#956from Camillarhi/multi-lsp-support-follow-up
08efb3a
Follow-up to #792 (multi-LSP support)