`lightning-liquidity`: Add serialization logic, persist service state #4059

tnull · 2025-09-05T14:31:58Z

This is the second PR in a series of PRs adding persistence to lightning-liquidity (see #4058). As this is already >1000LoC, I now decided to put this up as an intermediary step instead of adding everything in one go.

In this PR we add the serialization logic for for the LSPS2 and LSPS5 service handlers as well as for the event queue. We also have LiquidityManager take a KVStore towards which it persists the respective peer states keyed by the counterparty's node id. LiquidityManager::new now also deserializes any previously-persisted state from that given KVStore.

We then have BackgroundProcessor drive persistence, skip persistence for unchanged LSPS2/LSPS5 PeerStates, and use async inline persistence for LSPS2ServiceHandler where needed.

This also adds a bunch of boilerplate to account for both KVStore and KVStoreSync variants, following the approach we previously took with OutputSweeper etc.

cc @martinsaposnic

ldk-reviews-bot · 2025-09-05T14:32:01Z

👋 Thanks for assigning @TheBlueMatt 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.

lightning-liquidity/src/manager.rs

codecov · 2025-09-05T15:08:37Z

Codecov Report

❌ Patch coverage is 64.34955% with 359 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.51%. Comparing base (32314e3) to head (f3da21e).
⚠️ Report is 8 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning-liquidity/src/lsps2/service.rs	50.16%	141 Missing and 13 partials ⚠️
lightning-liquidity/src/events/event_queue.rs	56.55%	58 Missing and 5 partials ⚠️
lightning-liquidity/src/manager.rs	75.60%	54 Missing and 6 partials ⚠️
lightning-liquidity/src/lsps5/service.rs	69.47%	25 Missing and 4 partials ⚠️
lightning-liquidity/src/persist.rs	71.26%	16 Missing and 9 partials ⚠️
lightning-liquidity/src/lsps0/ser.rs	53.57%	10 Missing and 3 partials ⚠️
lightning-background-processor/src/lib.rs	76.59%	8 Missing and 3 partials ⚠️
lightning-liquidity/src/lsps1/client.rs	0.00%	2 Missing ⚠️
lightning-liquidity/src/lsps5/msgs.rs	93.75%	0 Missing and 1 partial ⚠️
lightning-liquidity/src/lsps5/url_utils.rs	91.66%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4059      +/-   ##
==========================================
- Coverage   88.75%   88.51%   -0.25%     
==========================================
  Files         177      179       +2     
  Lines      133318   134190     +872     
  Branches   133318   134190     +872     
==========================================
+ Hits       118330   118778     +448     
- Misses      12293    12661     +368     
- Partials     2695     2751      +56

Flag	Coverage Δ
fuzzing	`21.80% <25.98%> (+0.32%)`	⬆️
tests	`88.35% <63.85%> (-0.25%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

lightning-liquidity/src/manager.rs

martinsaposnic · 2025-09-05T15:45:58Z

this all LGTM.

I have a small concern: maybe I’m being a little paranoid, but read_lsps2_service_peer_states and read_lsps5_service_peer_states pull every entry from the KVStore into memory with no limit. That could lead to unbounded state, exhausting memory and crash. Maybe we can add a limit on how many entries we load into memory to protect against this dos?

not sure how realistic this is though. maybe an attacker could have access to or share the same storage with the victim, and they could dump effectively infinite data onto disk. in this scenario, probably the victim would be vulnerable to other attacks too, but still..

tnull · 2025-09-05T15:51:39Z

I have a small concern: maybe I’m being a little paranoid, but read_lsps2_service_peer_states and read_lsps5_service_peer_states pull every entry from the KVStore into memory with no limit. That could lead to unbounded state, exhausting memory and crash. Maybe we can add a limit on how many entries we load into memory to protect against this dos?

Reading state from disk (currently) happens on startup only, so crashing wouldn't be the worst thing, we would simply fail to start up properly. Some even argue that we need to panic if we hit any IO errors at this point to escalate to an operator. We could add some safeguard/upper bound, but I'm honestly not sure what it would protect against.

not sure how realistic this is though. maybe an attacker could have access to or share the same storage with the victim, and they could dump effectively infinite data onto disk. in this scenario, probably the victim would be vulnerable to other attacks too, but still..

Heh, well, if we assume the attacker has write access to our KVStore, we're very very screwed either way. Crashing could be the favorable outcome then, actually.

ldk-reviews-bot · 2025-09-08T00:00:35Z

🔔 1st Reminder

Hey @TheBlueMatt! 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.

lightning-liquidity/src/manager.rs

TheBlueMatt · 2025-09-08T12:53:22Z

lightning-liquidity/src/lsps2/msgs.rs

 	pub token: Option<String>,
 }

+impl_writeable_tlv_based!(LSPS2GetInfoRequest, {


Do we really want to have two ways to serialize all these types? Wouldn't it make more sense to just use the serde serialization we already have and wrap that so that it can't all be misused?

Yes, I think I'd be in favor of using TLV serialization for our own persistence.

Note that the compat guarantees of LSPS0/the JSON/serde format might not exactly match what we require in LDK, and our Rust representation might also diverge from the pure JSON impl. On top of that JSON is of course much less efficient.

Hmm, is there some easy way to avoid exposing that in the public API, then? Maybe a wrapper struct oe extension trait for serialization somehow? Seems like kinda a footgun for users, I think?

Hmm, is there some easy way to avoid exposing that in the public API, then? Maybe a wrapper struct oe extension trait for serialization somehow? Seems like kinda a footgun for users, I think?

Not quite sure I understand the footgun? You mean because these types then have Writeable as well as Serialize implementations on them and users might wrongly pick Writeable when they use the types independently from/outside of lightning-liquidity?

Sure, for example. Someone who uses serde presumably has some wrapper that serde-writes Writeable structs and suddenly their code could read/compile totally fine and be reading the wrong kind of thing. If they have some less-used codepaths (eg writing Events before they process them and then removing them again after) they might not find immediately.

Sure, for example. Someone who uses serde presumably has some wrapper that serde-writes Writeable structs and suddenly their code could read/compile totally fine and be reading the wrong kind of thing.

I'm confused - Writeable is an LDK concept not connected to serde? Do you mean Serialize? But that also has completely separate API? So how would they trip up? You mean they'd confuse Writeable and Serialize?

TheBlueMatt · 2025-09-08T13:12:12Z

lightning-liquidity/src/lsps5/service.rs

+	) -> Pin<Box<dyn Future<Output = Result<(), lightning::io::Error>> + Send>> {
+		let outer_state_lock = self.per_peer_state.read().unwrap();
+		let mut futures = Vec::new();
+		for (counterparty_node_id, peer_state) in outer_state_lock.iter() {


Huh? Why would we ever want to do a single huge persist pass and write every peer's state at once? Shouldn't we be doing this iteratively? Same applies in the LSPS2 service.

Yes, only persisting what's needed/changed will be part of the next PR as it ties into how we wake the BP to drive persistence (cf. "Avoid re-persisting peer states if no changes happened (needs_persist flag everywhere)" bullet over at #4058 (comment)).

I'm confused why we're adding this method then? If its going to be removed in the next PR in the series we should just not add it in the first place.

No, it's not gonna be removed, but extended: PeerState (here as well as in LSPS2) will gain a dirty/needs_persist flag and we'd simply skip persisting any entries that haven't been changed since the last persistence round.

That seems like a weird design if we need to persist something immediately while its being operated on - we have the node in question why walk a whole peer list? Can you put up the followup code so we can see how its going to be used? Given this PR is mostly boilerplate I honestly wouldn't mind it being a bit bigger, as long as the code isn't too crazy.

That seems like a weird design if we need to persist something immediately while its being operated on - we have the node in question why walk a whole peer list?

Yes, this is why persist_peer_state is a separate method - for inline persistence where we already hold the lock to the peer state we'd just call that. For the general/eventual persistence the background processor task calls LiquidityManager::persist which calls through to the respective LSPS*ServiceHandler::persist methods which then only persists the entries marked dirty since the last persistence round.

Can you put up the followup code so we can see how its going to be used? Given this PR is mostly boilerplate I honestly wouldn't mind it being a bit bigger, as long as the code isn't too crazy.

Sure will do as soon as it's ready an in a coherent state, although I had hoped to land this PR this week.

tnull · 2025-09-09T07:46:46Z

Rebased to address minor conflict.

TheBlueMatt

Responded to the outstanding comments, not quite sure I fully get all the rationale here.

lightning-liquidity/src/lsps5/service.rs

TheBlueMatt · 2025-09-23T15:24:29Z

lightning-liquidity/src/events/event_queue.rs

+				0u8 => {
+					// LSPS0ClientEvents are not persisted.
+					continue;
+				},
+				1u8 => {
+					// LSPS1ClientEvents are not persisted.
+					continue;
+				},
+				2u8 => {
+					// LSPS1ServiceEvents are not persisted.
+					continue;
+				},
+				3u8 => {
+					// LSPS2ClientEvents are not persisted.
+					continue;
+				},


The commit f Write length of actually persisted events is on the wrong base commit, it should be on Implement serialization for event queue types

.. this is likely only temporary necessary as we can drop our own `dummy_waker` implementation once we bump MSRV.

We add simple `persist` call to `LSPS2ServiceHandler` that sequentially persist all the peer states under a key that encodes their node id.

We add simple `persist` call to `LSPS5ServiceHandler` that sequentially persist all the peer states under a key that encodes their node id.

We add simple `persist` call to `EventQueue` that persists it under a `event_queue` key.

.. as we currently prune the the pending request state on peer disconnection anyways, so even if peers would reconnect the service can't use the events anymore anyways.

We read any previously-persisted state upon construction of `LiquidityManager`.

We let the background processor task regularly call `LiquidityManger::persist`. We also change the semantics of the `Future` for waking the background processor to also be used when we need repersisting (which we'll do in the next commit).

.. we only persist the event queue if necessary and wake the BP to do so when something changes.

.. we only persist the service handler if necessary.

.. to allow access in a non-async context

.. and wrap them accordingly for the `LSPS2ServiceHandlerSync` variant.

.. we only persist the service handler if necessary.

We add a simple test that runs the LSPS2 flow, persists, and ensures we recover the service state after reinitializing from our `KVStore`.

We add a simple test that runs the LSPS5 flow, persists, and ensures we recover the service state after reinitializing from our `KVStore`.

Previously, we'd persist peer states to the `KVStore`, but, while we pruned them eventually from our in-memory state, we wouldn't remove it from the `KVStore`. Here, we change this and regularly prune and delete peer state entries from the `KVStore`. Note we still prune the state-internal data on peer disconnection, but leave removal to our (BP-driven) async `persist` calls.

We update the docs of `invoice_params_generated` and mention that `user_channel_id` needs to be unique value.

martinsaposnic · 2025-09-23T18:12:10Z

lightning-liquidity/src/lsps2/service.rs

+						// We already have persisted otherwise by now.
+						return Ok(());
+					} else {
+						peer_state_lock.needs_persist = false;


question: maybe optimistically setting needs_persist=false and then releasing the locks would maybe create some data loss?

with a little help of chatgpt to get a timeline:

Initial State:

Peer ABC123 exists in the HashMap

peer_state.needs_persist = true (needs saving)

Timeline:

Time Thread 1 (Persistence) Thread 2 (Cleanup) State

T1 Acquires outer READ lock needs_persist = true

T2 Acquires peer mutex needs_persist = true

T3 Sets needs_persist = false needs_persist = false

T4 Encodes peer state needs_persist = false

T5 Releases ALL locks needs_persist = false

T6 Starts disk write (slow operation) Acquires outer WRITE lock needs_persist = false

T7 Disk write FAILS Removes peer from HashMap Peer DELETED

T8 Disk write FAILS Releases locks Peer DELETED

T9 Tries to acquire locks for recovery (not running) Peer DELETED

T10 get(&peer_id) returns None (not running) Peer DELETED

T11 .map() does nothing silently (not running) DATA LOST

This was discussed in #3905, we here 'simply' follow the same pattern: if we'd update the state only after the fact we would risk extra writes. Instead we simply revert the needs_persist flag if the write fails. Note that for important operations we initiate the persistence directly inline.

But sure, no matter how you turn it, if you create new data, and all write attempts fail until you shutdown, it will be lost and not persisted. Apart from that, I'm not quite following how to interpret that timeline and 'Peer DELETED' above (FWIW, not sure it's helpful here?)

TheBlueMatt

Okay, a handful of small comments, but I'm ready to land this once they're addressed. Feel free to squash as you go imo.

TheBlueMatt · 2025-09-23T17:37:10Z

lightning-liquidity/src/events/event_queue.rs

 				waker.wake();
 			}

 			self.condvar.notify_one();


Unrelated to this PR, but since we can push multiple events for one Drop this needs to notify_all not just one.

TheBlueMatt · 2025-09-23T17:37:58Z

lightning-liquidity/src/events/event_queue.rs

+				0u8 => {
+					// LSPS0ClientEvents are not persisted.
+					continue;
+				},
+				1u8 => {
+					// LSPS1ClientEvents are not persisted.
+					continue;
+				},
+				2u8 => {
+					// LSPS1ServiceEvents are not persisted.
+					continue;
+				},
+				3u8 => {


Why bother allocating numbers for these? We can't use them if we ever start writing new fields cause they dont read a length and discard that many bytes.

TheBlueMatt · 2025-09-23T17:55:59Z

lightning-liquidity/src/lsps1/event.rs

 	/// You must call [`LSPS1ServiceHandler::update_order_status`] to update the client
 	/// regarding the status of the payment and order.
 	///
+	/// **Note: ** This event will *not* be persisted across restarts.


MIssed some events below.

TheBlueMatt · 2025-09-23T17:57:31Z

lightning-liquidity/src/lsps2/event.rs

 	},
 	/// You should open a channel using [`ChannelManager::create_channel`].
 	///
+	/// **Note: ** As this event is persisted and might get replayed after restart, you'll need to


I don't see any update here?

TheBlueMatt · 2025-09-23T17:59:34Z

lightning-liquidity/src/lsps2/service.rs

 		let pending_requests = new_hash_map();
 		let intercept_scid_by_user_channel_id = new_hash_map();
 		let intercept_scid_by_channel_id = new_hash_map();
+		let needs_persist = true;


Is there a reason to init this to true? Presumably we shouldn't do an init persist until we allocate a channel.

TheBlueMatt · 2025-09-23T18:22:25Z

lightning-liquidity/src/lsps2/service.rs

-				peer_state_lock.is_prunable()
-			} else {
-				return;
+	async fn persist_peer_state(


Why is this a separate method from prune_peer_state? Can't we just do them in the same pass?

TheBlueMatt · 2025-09-23T18:44:48Z

lightning-liquidity/src/lsps5/service.rs

 	pub(crate) fn new_with_time_provider(
-		event_queue: Arc<EventQueue>, pending_messages: Arc<MessageQueue>, channel_manager: CM,
-		node_signer: NS, config: LSPS5ServiceConfig, time_provider: TP,
+		peer_states: Vec<(PublicKey, PeerState)>, event_queue: Arc<EventQueue<K>>,


Same here as LSPS2, let's just read into a hashmap directly so we don't have to into_iter.collect.

TheBlueMatt · 2025-09-23T18:45:54Z

lightning-liquidity/src/lsps5/service.rs

+		}
+	}
+
+	pub(crate) async fn prune_peer_state(&self) {


Same here as LSPS2, ISTM this should be combined with the normal persist loop.

TheBlueMatt · 2025-09-23T18:52:18Z

lightning-liquidity/src/lsps5/service.rs

+					LIQUIDITY_MANAGER_PERSISTENCE_PRIMARY_NAMESPACE,
+					LSPS5_SERVICE_PERSISTENCE_SECONDARY_NAMESPACE,
+					&key,
+					true,


FWIW I think this is relying on #4113.

TheBlueMatt · 2025-09-23T18:57:45Z

lightning-liquidity/src/persist.rs

+/// The primary namespace under which the [`LiquidityManager`] will be persisted.
+///
+/// [`LiquidityManager`]: crate::LiquidityManager
+pub const LIQUIDITY_MANAGER_PERSISTENCE_PRIMARY_NAMESPACE: &str = "liquidity";


nit: Can we be a bit more verbose in the namespace name? Something like ldk_lightning_liquidity_state?

tnull requested a review from TheBlueMatt September 5, 2025 14:31

tnull mentioned this pull request Sep 5, 2025

lightning-liquidity Persistence Tracking Issue #4058

Open

10 tasks

tnull force-pushed the 2025-01-liquidity-persistence branch 2 times, most recently from 124211d to 26f3ce3 Compare September 5, 2025 14:41

tnull self-assigned this Sep 5, 2025

tnull added the weekly goal Someone wants to land this this week label Sep 5, 2025

tnull added this to Weekly Goals Sep 5, 2025

tnull added this to the 0.2 milestone Sep 5, 2025

tnull moved this to Goal: Merge in Weekly Goals Sep 5, 2025

tnull force-pushed the 2025-01-liquidity-persistence branch 4 times, most recently from a98dff6 to d630c4e Compare September 5, 2025 14:58

martinsaposnic reviewed Sep 5, 2025

View reviewed changes

lightning-liquidity/src/manager.rs Outdated Show resolved Hide resolved

tnull force-pushed the 2025-01-liquidity-persistence branch from d630c4e to 70118e7 Compare September 5, 2025 15:15

martinsaposnic reviewed Sep 5, 2025

View reviewed changes

lightning-liquidity/src/manager.rs Outdated Show resolved Hide resolved

tnull force-pushed the 2025-01-liquidity-persistence branch from 70118e7 to dd43edc Compare September 5, 2025 15:28

martinsaposnic approved these changes Sep 5, 2025

View reviewed changes

tnull force-pushed the 2025-01-liquidity-persistence branch from dd43edc to f73146b Compare September 8, 2025 07:37

TheBlueMatt reviewed Sep 8, 2025

View reviewed changes

tnull force-pushed the 2025-01-liquidity-persistence branch from f73146b to 2971982 Compare September 9, 2025 07:35

tnull requested a review from TheBlueMatt September 10, 2025 07:22

TheBlueMatt reviewed Sep 10, 2025

View reviewed changes

tnull requested a review from TheBlueMatt September 10, 2025 12:41

tnull force-pushed the 2025-01-liquidity-persistence branch from d647793 to ec94cb3 Compare September 23, 2025 14:31

TheBlueMatt reviewed Sep 23, 2025

View reviewed changes

tnull added 24 commits September 23, 2025 17:49

f Don't implement Writeable for request types

c05ea9f

Implement serialization for LSPS5 state types

01c4578

f option/required_vec fields for LSPS5 serialization

de6cb88

Implement serialization for event queue types

2710815

Add symlink for async_poll.rs

61de01e

.. this is likely only temporary necessary as we can drop our own `dummy_waker` implementation once we bump MSRV.

Add LSPS2ServiceHandler persistence

dd40d4b

We add simple `persist` call to `LSPS2ServiceHandler` that sequentially persist all the peer states under a key that encodes their node id.

Add LSPS5ServiceHandler persistence

e3e29af

We add simple `persist` call to `LSPS5ServiceHandler` that sequentially persist all the peer states under a key that encodes their node id.

Add EventQueue persistence

60ea36b

We add simple `persist` call to `EventQueue` that persists it under a `event_queue` key.

f Skip persisting GetInfo and BuyRequests

d402b09

.. as we currently prune the the pending request state on peer disconnection anyways, so even if peers would reconnect the service can't use the events anymore anyways.

f Annotate all event types to indicate whether they are persisted

c3c3b11

f Write length of actually persisted events

4d0c8e0

Read persisted LSPS2 service state in LiquidityManager::new

5c88ac3

We read any previously-persisted state upon construction of `LiquidityManager`.

Read persisted LSPS5 service state in LiquidityManager::new

25f0fdb

We read any previously-persisted state upon construction of `LiquidityManager`.

Read persisted event queue state in LiquidityManager::new

2731dd2

We read any previously-persisted state upon construction of `LiquidityManager`.

Skip EventQueue persistence if unnecessary

526db54

.. we only persist the event queue if necessary and wake the BP to do so when something changes.

Skip LSPS2ServiceHandler persistence if unnecessary

a25ac62

.. we only persist the service handler if necessary.

Add LSPS2ServiceHandlerSync wrapper

11a3bb3

.. to allow access in a non-async context

Add inline persistence with async LSPS2ServiceHandler API methods

e7016a4

.. and wrap them accordingly for the `LSPS2ServiceHandlerSync` variant.

Skip LSPS5ServiceHandler persistence if unnecessary

c6d51bf

.. we only persist the service handler if necessary.

Add test asserting LSPS2 service state is persisted across restarts

247599c

We add a simple test that runs the LSPS2 flow, persists, and ensures we recover the service state after reinitializing from our `KVStore`.

Add test asserting LSPS5 service state is persisted across restarts

ebbd98c

We add a simple test that runs the LSPS5 flow, persists, and ensures we recover the service state after reinitializing from our `KVStore`.

Mention user_channel_id uniqueness in invoice_params_generated docs

f3da21e

We update the docs of `invoice_params_generated` and mention that `user_channel_id` needs to be unique value.

tnull force-pushed the 2025-01-liquidity-persistence branch from ec94cb3 to f3da21e Compare September 23, 2025 15:57

tnull requested a review from TheBlueMatt September 23, 2025 16:00

martinsaposnic reviewed Sep 23, 2025

View reviewed changes

TheBlueMatt reviewed Sep 23, 2025

View reviewed changes

Time	Thread 1 (Persistence)	Thread 2 (Cleanup)	State
T1	Acquires outer READ lock		needs_persist = true
T2	Acquires peer mutex		needs_persist = true
T3	Sets needs_persist = false		needs_persist = false
T4	Encodes peer state		needs_persist = false
T5	Releases ALL locks		needs_persist = false
T6	Starts disk write (slow operation)	Acquires outer WRITE lock	needs_persist = false
T7	Disk write FAILS	Removes peer from HashMap	Peer DELETED
T8	Disk write FAILS	Releases locks	Peer DELETED
T9	Tries to acquire locks for recovery	(not running)	Peer DELETED
T10	get(&peer_id) returns None	(not running)	Peer DELETED
T11	.map() does nothing silently	(not running)	DATA LOST

lightning-liquidity: Add serialization logic, persist service state #4059

Are you sure you want to change the base?

lightning-liquidity: Add serialization logic, persist service state #4059

Uh oh!

Conversation

tnull commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

codecov bot commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

martinsaposnic commented Sep 5, 2025

Uh oh!

tnull commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Sep 8, 2025

Uh oh!

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!

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!

Choose a reason for hiding this comment

Uh oh!

tnull Sep 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnull commented Sep 9, 2025

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

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!

TheBlueMatt 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!

Choose a reason for hiding this comment

Uh oh!

`lightning-liquidity`: Add serialization logic, persist service state #4059

`lightning-liquidity`: Add serialization logic, persist service state #4059

tnull commented Sep 5, 2025 •

edited

Loading

ldk-reviews-bot commented Sep 5, 2025 •

edited

Loading

codecov bot commented Sep 5, 2025 •

edited

Loading

tnull commented Sep 5, 2025 •

edited

Loading

tnull Sep 11, 2025 •

edited

Loading