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

plugins: lsps: remove cln dependencies from core module and clean up service

Public commit record

What the developer wrote

Authored by Peter Neuroth

73/100 · Adequate
plugins: lsps: remove cln dependencies from core module and clean up service

The core module shouldn't depend on anything from the cln_adapters
module. This ensures that we can switch out interfaces in the future
(e.g a different database than cln's datastore).

This change made it necessary to refactor the service plugin which
allowed us to clean it up on the go

Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit is a code cleanup inside Core Lightning's experimental LSPS (Lightning Service Provider Specification) plugin. It removes a direct dependency between the plugin's core logic and the CLN-specific adapter types, replacing them with generic types. The service layer now converts between CLN-specific hook request/response formats and the new generic core types. There is no obvious security vulnerability introduced or fixed; it is primarily an architectural refactor.

Recommended action

No immediate action required. Treat as normal code-review refactor. Reviewers should verify that the new service-layer error-to-continue fallback in `handle_htlc_safe` is intentional and safe for production LSPS operation, because silently continuing on unexpected errors could change failure semantics compared to the prior code.

Security signals we found

01

Refactor moves request/response serialization boundary from core module to service module

02

Error propagation changed: internal API errors (capacity query, fund channel, channel-ready check) now surface as `HtlcError` rather than being silently converted to `UNKNOWN_NEXT_PEER` failures

03

Service-layer wrapper `handle_htlc_safe` catches all errors and falls back to `json_continue()`, which could cause HTLCs to be forwarded instead of failed when unexpected errors occur

04

MPP (multi-part payment) rejection is currently mapped to `continue` as a temporary workaround, same as before refactor

Risk score

Why this scored 16/100

Our methodology →
Potential impact 2/30
Exploitability 1/25
Stealth signal 1/15
Affected reach 2/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.