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

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

Opening this as an early draft to get feedback on the overall API direction

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..

src/builder.rs

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

src/liquidity.rs

+					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

src/liquidity.rs

 	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

Replace per-protocol single-LSP configuration `LSPS1Client, LSPS2Client` with a unified `Vec<LspNode>` model where users configure LSP nodes via `add_lsp()` and protocol support is discovered at runtime via LSPS0 `list_protocols`. - Replace separate `LSPS1Client/LSPS2Client` with global pending request maps keyed by `LSPSRequestId` - Add LSPS0 protocol discovery `discover_lsp_protocols` with event handling for `ListProtocolsResponse` - Update events to use is_lsps_node() for multi-LSP counterparty checks - Deprecate `set_liquidity_source_lsps1/lsps2` builder methods in favor of `add_lsp()` - LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer across all of them - Add `request_channel_from_lsp()` for explicit LSPS1 LSP selection - Spawn background discovery task on `Node::start()`

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

src/liquidity.rs

@@ -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

src/lib.rs

+					}
+				}
+
+				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

src/lib.rs

 	}
+
+	/// 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()?

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

src/liquidity/client/lsps1.rs

+/// [`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

src/builder.rs

 	/// 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 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 8bbf55a Compare 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 ea93afe Compare March 26, 2026 01:18

tnull reviewed Mar 27, 2026

View reviewed changes

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

Conversation

Camillarhi commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Camillarhi commented Feb 12, 2026

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Camillarhi commented Mar 26, 2026

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Camillarhi commented Feb 12, 2026 •

edited

Loading

ldk-reviews-bot commented Feb 12, 2026 •

edited

Loading