AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 30 Bitcoin

Read persisted LSPS2 service state in `LiquidityManager::new`

Public commit record

What the developer wrote

Authored by Elias Rohrer

65/100 · Adequate
Read persisted LSPS2 service state in `LiquidityManager::new`

We read any previously-persisted state upon construction of
`LiquidityManager`.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
The short version

What changed, and why it matters

This commit changes how the Lightning Dev Kit liquidity manager starts up: it now reads previously saved LSPS2 service state from disk when created. Previously, the manager started with empty in-memory state even if data had been saved, which could cause it to lose track of active liquidity requests and routing information after a restart. The change also makes the constructors return errors if the saved data is corrupt or inconsistent, rather than silently starting fresh. This is a reliability and data-integrity improvement, not a typical remote-exploitable vulnerability.

Recommended action

Treat this as a bug-fix/data-integrity hardening commit. Review downstream callers that now receive a Result to ensure errors are handled rather than unwrapped in production. Verify that the KVStore read in the sync wrapper cannot legitimately return Pending, or add a proper blocking mechanism if it can. Confirm that persisted state is written atomically to avoid the newly-detected inconsistent duplicates.

Security signals we found

01

Constructor now reads persisted state instead of starting with empty peer state

02

Adds duplicate-key validation for intercept SCIDs and channel IDs when reloading state

03

Makes constructors fallible so corrupt/inconsistent persisted data is reported rather than ignored

04

Sync wrapper uses dummy waker and unreachable! on Pending, which assumes the async read will complete synchronously

Risk score

Why this scored 30/100

Our methodology →
Potential impact 8/30
Exploitability 4/25
Stealth signal 3/15
Affected reach 5/15
Confidence 7/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.