LDK
← All projectsLightning Dev Kit

rust-lightning

Composable Rust libraries for building Lightning wallets, nodes, and services.

BitcoinCryptographic librariesLightning NetworkNormal
Repository coverage

1493 commits in the local evidence base

Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.

225security candidates209second-pass queue626AI analyses
72commits · 30 days
204commits · 60 days
659commits · 180 days
1487commits · 365 days
Backfill bands
Aug 5 → Feb 6819 seen18 candidatesComplete
Feb 6 → Jun 6468 seen16 candidatesComplete
Jun 6 → Jul 6128 seen8 candidatesComplete
Jul 6 → Aug 561 seen3 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

69/100 average clarity
357Strong · 80–100
788Adequate · 60–79
288Thin · 40–59
60Opaque · 0–39
3security candidates with opaque commit messaging
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Elias Rohrer1531556567
Matt Corallo35747140373
Jeffrey Czyz1774169168
Leo Nash1161369162
Valentine Wallace1351025169
Vincenzo Palazzo10210184
Wilmer Paulino1493972069
Joost Jager1622492069
elnosh301320056
shaavan2267069
Carla Kirk-Cohen78320068
benthecarman1836071
Analysis record

Published AI watches

Last scanned 47 minutes ago

Low 32 AI analysisMessage 91 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Only fetch TXIDs instead of entire block during gossip verification' (#4846)

This commit changes how the Lightning Dev Kit's block-sync module verifies Lightning network gossip announcements. Instead of downloading entire Bitcoin blocks (which can be large), it now downloads only the list of transaction IDs for a b…

API surface change in UtxoSource traitReduced data exposure: no longer fetches full blocks for gossip verificationNew JSON parsing for txid lists and TxOut values
ebe7a447by Matt Corallo+275−1025 files
No security note in commit
Low 35 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Allow filtered block rescans at the current tip' (#4847)

This commit changes how the Lightning Dev Kit (LDK) node software handles receiving the same block twice through its filtered-block interface. Previously, calling filtered_block_connected with the current tip again would trigger an asserti…

Assertion relaxation in block connection pathPotential denial-of-service vector removed: previously a malicious or buggy filter provider could crash the node by replaying the current tipNew test coverage for same-block filtered rescan
54ddbd0bby Matt Corallo+177−486 files
No security note in commit
Informational 15 AI analysisMessage 83 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Add test framework coverage of `Listen` block connection replays

This commit only adds a new test mode to the project's internal testing framework. It lets developers simulate a specific way blocks are delivered to the Lightning node (a 'replay' through the Listen interface) so that behavior is covered …

bf6ad23eby Matt Corallo+18−32 files
No security note in commit
Informational 15 AI analysisMessage 83 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Update functional test block connection to detect block replays

This commit changes only internal test helper code in the Lightning Dev Kit repository. It makes the functional test framework smarter about 'block replays'—situations where the same block is fed to a test node more than once—so the fake b…

No production code modifiedNo cryptographic, consensus, or networking changesCommit message frames change as test-framework correctness, not security
477facb4by Matt Corallo+41−333 files
No security note in commit
Moderate 66 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Correct HTLC confusion on unrevoked counterparty commitment txs

This patch fixes a bug in the Lightning Dev Kit where the software could confuse HTLCs (payment contracts) on live, unrevoked counterparty commitment transactions with ones from old, revoked transactions. Previously, it relied only on whet…

Incorrect revocation state detection for counterparty commitment transactionsHTLC direction not previously checked when matching against pending HTLCsPromotion of debug assertions to full assertions for HTLC claim path consistency
f06a08a6by Matt Corallo+26−192 files
Vendor flagged security relevance
Low 47 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Return `Err`s` instead of panicking on oversized messages

This commit changes how the Lightning networking code handles oversized encrypted messages. Previously, certain conditions would cause the program to crash with a panic. Now the code returns errors instead, which is a defensive improvement…

panic-to-error conversion for oversized message encryption/decryptiondenial-of-service hardening against oversized peer messagesdebug_assert retained to preserve test coverage of invariant violations
08f12bc7by Matt Corallo+68−313 files
Vendor flagged security relevance
Moderate 62 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Avoid panicking when attempting to send an oversized message

This commit fixes a crash bug in the Lightning Dev Kit's peer message handling. Previously, if a message grew too large to be sent over the encrypted peer connection, the code would panic (abruptly terminate the whole program). The patch m…

Replaces a `.expect()` panic path with a fallible `Result` in peer message encryptionAdds graceful peer disconnection when a critical message cannot be sentIncludes a regression test for oversized-message handling
c5fdc3bfby Matt Corallo+148−901 file
Vendor flagged security relevance
High 74 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Avoid oversized relayed failure messages

This patch fixes a crash bug in the Lightning Dev Kit's handling of HTLC failure messages. A downstream peer could send a maximally-sized failure message without attribution data. When the node added its own attribution data while relaying…

Denial-of-service via remote-triggered panic in message encryptionOversized message exceeding Noise/Lightning wire framing limitMissing length validation before adding attribution data during relay
6b1dfb1aby Matt Corallo+64−191 file
Vendor flagged security relevance
Moderate 64 AI analysisMessage 83 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Reject attempts to advance one-hop blinded forward paths

This commit fixes a denial-of-service bug in rust-lightning where a maliciously crafted one-hop blinded reply path could cause the node to panic when it tried to respond. The fix rejects paths with too few hops before advancing them, and a…

Denial-of-service vector via malformed blinded pathPanic in onion construction due to zero-hop pathUntrusted reply path input validation gap
969a40cfby Matt Corallo+49−14 files
Vendor flagged security relevance
High 72 AI analysisMessage 96 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

lightning-types: replace Zl/Zp separators in `PrintableString`

This commit fixes a log-forgery risk in a Rust Lightning library helper called PrintableString. That helper is meant to make untrusted text safe to print by replacing dangerous characters with a placeholder. It already caught most control …

log injection / log forgery via U+2028/U+2029 line separatorsincomplete input sanitisation in PrintableStringpeer-controlled strings (node alias, BOLT 12 description/issuer/payer_note, peer_msg) as attack surface
75defa9cby Vincenzo Palazzo+63−83 files
Vendor flagged security relevance
Moderate 69 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Apply the unfunded channel peer limit to all unaccepted channels

This commit fixes a rate-limiting bug in the Lightning Dev Kit (LDK) that let a single peer bypass the cap on how many different peers can have unfunded (not-yet-funded) channels open. Previously, if a peer sent multiple channel requests q…

Denial-of-service resource exhaustion via rapid inbound channel open requestsLogic error in rate-limiting conditionRegression test added for the bypass scenario
56a4ee43by Matt Corallo+87−62 files
Vendor flagged security relevance
Moderate 60 AI analysisMessage 88 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Allow filtered block rescans at the current tip

This commit fixes a bug where replaying the current blockchain block through a normal listener callback could crash two core Lightning components (ChannelManager and OutputSweeper) with a panic. The fix recognizes a same-block replay as a …

panic in chain listener callbacksame-block replay/rescan mishandlingassertion failure on valid chain input
686f9860by Elias Rohrer+118−123 files
Vendor flagged security relevance
Moderate 57 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Avoid panic when reorged claims cannot merge

This commit fixes a crash bug in the Lightning Dev Kit's on-chain transaction handler. During a deep blockchain reorganization, a previously settled HTLC claim could be 'resurrected' at a block height where it could no longer be combined w…

Assertion/panic in reorg handling pathDeep blockchain reorg as trigger conditionHTLC claim resurrection after reorg
f1dc8487by Matt Corallo+219−52 files
Vendor flagged security relevance
Informational 15 AI analysisMessage 45 · Thin
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Update crate repository links to forgejo

This commit simply updates the 'repository' web links in 15 package metadata files from GitHub to a self-hosted Forgejo instance. It does not change any program code, build logic, dependencies, or security behavior. There is no security is…

eb77676dby benthecarman+15−1515 files
No security note in commit
Low 45 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Account for message type prefix len in prevtx length enforcement

This commit fixes a small but real accounting bug in how rust-lightning checks whether a previous transaction (prevtx) attached to a funding input will make the resulting Lightning wire message too large. The code previously compared the m…

Off-by-constant length check in protocol message size enforcementPotential acceptance of a prevtx that produces an oversized Lightning wire messageDenial-of-service / protocol-interop risk from peer message rejection
d29e1415by Wilmer Paulino+21−41 file
No security note in commit
Moderate 54 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Retransmit splice_locked for 0-conf channels missing tx_signatures

This commit fixes a bug in the Lightning Dev Kit where, after a disconnection, a node could fail to retransmit a 'splice_locked' message to a peer that was still waiting for transaction signatures. Without this retransmission, the two peer…

Protocol state desynchronization between channel peers after reconnectionMissing retransmission of splice_locked for 0-conf splice channelsPotential channel unusability or stuck splice negotiation
5434015bby Wilmer Paulino+266−12 files
No security note in commit
Low 37 AI analysisMessage 83 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

bolt12: add pay_for_bolt12_invoice for externally-sourced invoices

This commit adds a new API, pay_for_bolt12_invoice, that lets users pay a BOLT 12 invoice even if LDK did not originally request it. It is intended for advanced use cases like multi-sender payments and replaces an older, more restrictive A…

New API removes internal invoice-origin verification, shifting trust boundary to callerDocumentation explicitly warns caller to verify invoice via Bolt12Invoice::verify_using_metadata and to ensure unique payment_id to avoid duplicate paymentsInput validation added for zero amount, overpay, and partial-amount-without-MPP
5b80fe9cby Alkamal01+550−156 files
No security note in commit
Low 26 AI analysisMessage 90 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Include to_self_delay size in DelayedPaymentOutput weight calculation

This commit fixes a small accounting bug in how the Lightning wallet estimates the size (and therefore transaction fee) of a special Bitcoin transaction that sweeps funds back to the user after a channel closes. The old code always assumed…

debug assertion failure possible in development/testing buildstransaction weight/fee estimate overestimation up to 3 WUconstant replaced with per-descriptor length computation
e6652237by Matt Morehouse+97−83 files
No security note in commit
Informational 18 AI analysisMessage 65 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Correct docs on `ChannelSigner::get_per_commitment_point`

This commit only updates documentation comments for a Rust function called get_per_commitment_point. It removes an outdated warning that the method was non-asynchronous and that returning an error could cause a crash, and replaces it with …

Documentation-only changeRemoves outdated panic warningAdds retry/unblock guidance for signer errors
5057809bby Matt Corallo+6−31 file
No security note in commit
Informational 17 AI analysisMessage 83 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

fuzz: allow empty-channel force close with in-flight payments

This commit changes a fuzz-testing harness, not the production Lightning node code. It loosens a test rule so the fuzzer can simulate force-closing a channel that has no pending payments of its own, even if other channels in the test still…

Fuzz harness behavior change onlyNo modifications to production consensus, cryptography, or networking codeNo privilege boundary crossed
dbb12502by Joost Jager+32−71 file
No security note in commit
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

Lower-priorityAdd newline to fuzz log statementsby Wilmer Paulino · 7b8c68c9 · Feb 18, 2026 · 1 fileMessage 70 · AdequateInformational 15Details
Commit message · Wilmer Paulino

Add newline to fuzz log statements

This regressed at some point, making the logs harder to parse on a
failed test run.

70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100

This commit fixes a formatting issue in fuzz testing logs by adding a missing newline at the end of each log entry. It only affects test output readability and has no security relevance.

Security candidateTime out incomplete MPP payments in chanmon_consistencyby Wilmer Paulino · 520dcbb2 · Feb 18, 2026 · 4 filesMessage 73 · AdequateLow 27Details
Commit message · Wilmer Paulino

Time out incomplete MPP payments in chanmon_consistency

This requires calling `timer_tick_occurred`. As a result, when
`timer_tick_occurred` is called, disabled/enabled updates and
`WarnAndDisconnect` events may be triggered.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
boot or update path
AI analysis · Low 27/100

This commit changes how a Lightning payment library runs its internal fuzz tests. It makes the test harness call the normal periodic timer function instead of a special stripped-down version, so incomplete multi-part payments time out properly during testing. The production code is mostly unchanged, but a few internal test-only helpers are now available under a new test-utilities feature flag. There is no direct evidence this fixes a real-world security bug; it appears to be a test-harness cleanup that makes fuzzing more realistic.

Lower-priorityConsider probe events for stuck payments check in chanmon_consistencyby Wilmer Paulino · 28ef7a8d · Feb 18, 2026 · 1 fileMessage 85 · StrongInformational 15Details
Commit message · Wilmer Paulino

Consider probe events for stuck payments check in chanmon_consistency

Even though we don't explicitly send probes, because probes are detected
based on hashing the payment hash+preimage, it's rather trivial for the
fuzzer to build payments that accidentally end up looking like probes.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100

This commit fixes a fuzz testing harness so it correctly tracks payments that the fuzzer accidentally generates as probe-like payments. It is a test-only change and does not affect real Lightning node behavior or user funds.

Lower-priorityUse channel_id over short_channel_id for payments in chanmon_consistencyby Wilmer Paulino · c0c09c7d · Feb 18, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Wilmer Paulino

Use channel_id over short_channel_id for payments in chanmon_consistency

The `short_channel_id` is no longer guaranteed to be stable with
splicing now that the fuzzer can actually lock splices.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100

This commit updates an internal fuzz-testing harness (a tool that automatically throws random inputs at the code to find bugs) to use a more stable channel identifier when building test payments. It does not change the production Lightning node code that real users run, and there is no indication it fixes a security vulnerability. The change is purely about making the fuzzer work correctly now that the codebase supports 'splicing,' a feature that can change a channel's short identifier.

Security candidateDrive splices to completion in chanmon_consistencyby Wilmer Paulino · 3c09513b · Feb 18, 2026 · 1 fileMessage 85 · StrongInformational 12Details
Commit message · Wilmer Paulino

Drive splices to completion in chanmon_consistency

This commit adds support for locking splices. This required confirming
transactions, which this target previously didn't consider.

It also fixes a `serial_id` collision, due to its generation using
the first 4 bytes of `get_secure_random_bytes`, that was preventing
splices from negotiating up to the `tx_signatures` exchange.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing boundary
AI analysis · Informational 12/100

This commit updates a fuzzing test harness (chanmon_consistency) in the Lightning Dev Kit project. It adds the ability to simulate confirming splice transactions on a fake blockchain and fixes a serial ID collision in the test's random number generator. The changes are confined to test/fuzzing code and do not alter production Lightning logic.

Security candidateSupport async signing in chanmon_consistencyby Wilmer Paulino · ed520ae9 · Feb 18, 2026 · 2 filesMessage 68 · AdequateInformational 13Details
Commit message · Wilmer Paulino

Support async signing in chanmon_consistency

This commit adds new opcodes to enable/disable signer operations one by
one. Note that this only covers signer operations post-funding.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 13/100

This commit only changes test and fuzzing code. It adds new test controls that let developers temporarily disable or enable individual signer operations during fuzz testing, and it removes one unused signer-operation flag. There is no change to production Lightning code, so it does not create a real-world security vulnerability or fix one.

Lower-prioritySplit CI test script into parallel jobsby Joost Jager · a026acef · Feb 18, 2026 · 10 filesMessage 78 · AdequateInformational 15Details
Commit message · Joost Jager

Split CI test script into parallel jobs

Split the monolithic ci-tests.sh into six focused scripts that run as
separate parallel jobs via a reusable workflow (ci-build.yml):

- ci-tests-workspace.sh: workspace checks, tests, docs, and downstream compat
- ci-tests-features.sh: crate feature/flag combinations (dnssec, tokio, backtrace, test vectors, serde)
- ci-tests-bindings.sh: c_bindings builds and tests
- ci-tests-nostd.sh: no_std builds and compatibility checks
- ci-tests-cfg-flags.sh: experimental gated cfg flags (taproot, simple_close, lsps1_service, peer_storage)
- ci-tests-sync.sh: block sync and transaction sync clients

Shared setup (MSRV pins, backtrace) is extracted into ci-tests-common.sh.
The ci-tests.sh script now delegates to the sub-scripts for local use.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100

This commit is purely a refactoring of the project's continuous integration (CI) setup. It splits one large test script into six smaller, focused scripts that can run in parallel on GitHub Actions. There are no changes to the actual Lightning protocol code, cryptography, networking, or any code that end users or nodes run. It does not fix or introduce any security-relevant behavior.

Lower-priorityAllow intercepting HTLCs based on the source channelby Matt Corallo · 9a9531f3 · Feb 18, 2026 · 3 filesMessage 73 · AdequateTriage 0Details
Commit message · Matt Corallo

Allow intercepting HTLCs based on the source channel

It may be useful in some situations to select HTLCs for
interception based on the source channel in addition to the sink.
Here we add the ability to do so by adding new flags to
`HTLCInterceptionFlags`.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityPass constructed `PendingAddHTLCInfo` to chanman `forward_htlcs`by Matt Corallo · 113f9cbd · Feb 18, 2026 · 1 fileMessage 85 · StrongTriage 0Details
Commit message · Matt Corallo

Pass constructed `PendingAddHTLCInfo` to chanman `forward_htlcs`

We jump through some hoops in order to pass a small list of objects
to `forward_htlcs` on a per-channel basis rather than per-HTLC.
Then, `forward_htlcs` builds a `PendingAddHTLCInfo` for each HTLC
for insertion. Worse, in some `forward_htlcs` callsites we're
actually starting with a `PendingAddHTLCInfo`, converting it to a
tuple, then back inside `forward_htlcs`.

Instead, here we just pass a list of built `PendingAddHTLCInfo`s to
`forward_htlcs`, cleaning up a good bit of code and even avoiding
an allocation of the HTLCs vec in many cases.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Lower-priorityMake FundingContribution::net_value() infallibleby Jeffrey Czyz · 9f6c6785 · Feb 17, 2026 · 2 filesMessage 58 · ThinLow 34Details
Commit message · Jeffrey Czyz

Make FundingContribution::net_value() infallible

Split FundingContribution::net_value() (which returned
Result<SignedAmount, String>) into a separate validate() method and an
infallible net_value() that returns SignedAmount directly. The validate()
method checks prevtx sizes and input sufficiency, while net_value()
computes the net contribution amount.

To make net_value() safe to call without error handling, add MAX_MONEY
bounds checks in the build_funding_contribution! macro before coin
selection. This ensures FundingContribution is valid by construction:
value_added and the sum of outputs are each bounded by MAX_MONEY
(~2.1e15 sat), so the worst-case net_value() computation (-2 * MAX_MONEY
~= -4.2e15) is well within i64 range (~-9.2e18).

Update callers in channel.rs to use the new separate methods, simplifying
error handling at call sites where net_value() previously required
unwrapping a Result.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Why it was queued
defensive validation
AI analysis · Low 34/100

This commit refactors how a Bitcoin Lightning channel funding calculation reports its results. Previously, a single method could either return a number or fail with an error. Now validation and the actual number calculation are split apart, and the code adds upfront checks to ensure the numbers involved can never be large enough to cause an arithmetic overflow. It is a defensive hardening change rather than a fix for a known active exploit.

Security candidateFree holding cell upon tx_signatures exchangeby Wilmer Paulino · 3e8b0604 · Feb 17, 2026 · 2 filesMessage 68 · AdequateLow 44Details
Commit message · Wilmer Paulino

Free holding cell upon tx_signatures exchange

After cad88af, a few code paths that also lead to a quiescence exit were
not accounted for. This commit addresses the last remaining path where
we exit quiescence when we exchange `tx_signatures` with the
counterparty.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundary
AI analysis · Low 44/100

This patch fixes a bug in the Lightning Dev Kit where, after a special quiet period called 'quiescence' used during splicing (modifying a channel's funds), some queued payment updates were not released when the quiet period ended via the 'tx_signatures' message exchange. The fix ensures those queued updates are freed and processed, preventing payment delays or stalls during splice operations.

Lower-priorityFree holding cell upon handling a counterparty tx_abortby Wilmer Paulino · 2665465b · Feb 17, 2026 · 3 filesMessage 85 · StrongTriage 0Details
Commit message · Wilmer Paulino

Free holding cell upon handling a counterparty tx_abort

After cad88af, a few code paths that also lead to a quiescence exit were
not accounted for. This commit addresses the path where we exit
quiescence due to processing a counterparty's `tx_abort` message.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Lower-priorityFree holding cell upon handling an invalid interactive-tx messageby Wilmer Paulino · ac0f53fa · Feb 17, 2026 · 3 filesMessage 85 · StrongTriage 0Details
Commit message · Wilmer Paulino

Free holding cell upon handling an invalid interactive-tx message

After cad88af, a few code paths that also lead to a quiescence exit were
not accounted for. This commit addresses the path where we exit
quiescence due to a processing error on a counterparty's
`tx_add_input/output`, `tx_remove_input/output`, or `tx_complete`
message.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Lower-priorityRemove PersistenceNotifierGuard from splice_channelby Jeffrey Czyz · 04130c10 · Feb 17, 2026 · 2 filesMessage 63 · AdequateTriage 0Details
Commit message · Jeffrey Czyz

Remove PersistenceNotifierGuard from splice_channel

Now that ChannelManager::splice_channel only reads, there is no need to
notify listeners about event handling nor persistence.

63/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Provides detailed explanatory context
Lower-priorityRemove redundant is_initiator from FundingTemplate/FundingContributionby Jeffrey Czyz · e24ff563 · Feb 17, 2026 · 2 filesMessage 73 · AdequateTriage 0Details
Commit message · Jeffrey Czyz

Remove redundant is_initiator from FundingTemplate/FundingContribution

FundingTemplate is only ever created by the splice initiator, so
is_initiator is always true. The channel already knows who initiated
the splice from who won quiescence (is_holder_quiescence_initiator),
making the field on FundingTemplate and FundingContribution redundant.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI review queuedRemove use of Deref with CoinSelectionSourceby Jeffrey Czyz · 2a238d76 · Feb 17, 2026 · 3 filesMessage 68 · AdequateInformational 17Details
Commit message · Jeffrey Czyz

Remove use of Deref with CoinSelectionSource

Instead of using Deref in APIs using CoinSelectionSource, implement
CoinSelectionSource for any Deref with a Target that implements
CoinSelectionSource.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 17/100

This commit is a code cleanup in the Lightning Dev Kit's Rust library. It changes how a wallet interface called CoinSelectionSource is used in function signatures. Instead of requiring that a wallet type be a pointer-like wrapper (Deref) around something that implements CoinSelectionSource, the commit makes CoinSelectionSource directly implementable for any pointer-like wrapper. This simplifies the API and removes an internal wrapper struct, but it does not fix a security bug or change runtime behavior in a way that would affect funds or network safety.

AI review queuedMake ConfirmedUtxo the primary typeby Jeffrey Czyz · 9a0a2497 · Feb 17, 2026 · 2 filesMessage 68 · AdequateInformational 15Details
Commit message · Jeffrey Czyz

Make ConfirmedUtxo the primary type

FundingTxInput was originally designed for channel funding but is now
used more broadly for coin selection and splicing. The name
ConfirmedUtxo better reflects its general-purpose nature as a confirmed
UTXO with previous transaction data. Make ConfirmedUtxo the real struct
in wallet_utils and alias FundingTxInput to it for backward
compatibility.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit is a pure code reorganization: it renames the internal primary type from FundingTxInput to ConfirmedUtxo and makes FundingTxInput a backward-compatible alias. No behavior, logic, or security properties change. It is not a security fix.

AI review queuedMove sync wallet utils to util::wallet_utilsby Jeffrey Czyz · 0ce6ba40 · Feb 17, 2026 · 11 filesMessage 68 · AdequateInformational 15Details
Commit message · Jeffrey Czyz

Move sync wallet utils to util::wallet_utils

Synchronous wallet utilities were coupled to bump_transaction::sync,
limiting their reusability for other features like channel funding and
splicing which need synchronous wallet operations. Consolidate all
wallet utilities in a single module for consistency and improved code
organization.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit is a straightforward code reorganization. It moves synchronous wallet helper code from one module (bump_transaction::sync) into a shared utility module (util::wallet_utils) so it can be reused by channel funding and splicing features. No security-relevant behavior is changed; only import paths and module locations are adjusted.

AI review queuedMove wallet utils to dedicated moduleby Jeffrey Czyz · 45db7c88 · Feb 17, 2026 · 9 filesMessage 68 · AdequateInformational 19Details
Commit message · Jeffrey Czyz

Move wallet utils to dedicated module

Wallet-related types were tightly coupled to bump_transaction, making
them less accessible for other use cases like channel funding and
splicing. Extract these utilities to a dedicated module for improved
code organization and reusability across the codebase.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 19/100

This commit is a pure code reorganization: it moves wallet-related types and traits (for choosing which coins to spend in Bitcoin transactions) from one internal module to a new dedicated module. There are no functional changes, no bug fixes, and no security patches visible in the diff.

Lower-priorityConsistently log in propose_quiescenceby Jeffrey Czyz · 20916b7a · Feb 17, 2026 · 2 filesMessage 58 · ThinTriage 0Details
Commit message · Jeffrey Czyz

Consistently log in propose_quiescence

Instead of logging both inside propose_quiescence and at the call site,
only log inside it. This simplifies the return type.

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Security candidateUse CoinSelection::change_output when splicingby Jeffrey Czyz · 96b9e6af · Feb 17, 2026 · 7 filesMessage 68 · AdequateLow 32Details
Commit message · Jeffrey Czyz

Use CoinSelection::change_output when splicing

Now that CoinSelection is used to fund a splice funding transaction, use
that for determining of a change output should be used. Previously, the
initiator could either provide a change script upfront or let LDK
generate one using SignerProvider::get_destination_script.

Since older versions may have serialized a SpliceInstruction without a
change script while waiting on quiescence, LDK must still generate a
change output in this case.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundary
AI analysis · Low 32/100

This commit changes how Lightning Dev Kit handles 'change' money during Bitcoin channel splicing. Previously, the user could provide a change address or LDK would generate one itself. Now, the wallet's coin-selection logic decides whether a change output is needed and what it looks like. The commit keeps a fallback for older stored data that may not include a change script. It is a code-quality and consistency improvement rather than a clear security fix, though it reduces the chance of fee or change-output mistakes during splicing.

AI review queuedSplit splice initiation into two phasesby Jeffrey Czyz · 2fd33510 · Feb 17, 2026 · 11 filesMessage 68 · AdequateLow 28Details
Commit message · Jeffrey Czyz

Split splice initiation into two phases

Previously, splice_channel required callers to manually construct
funding inputs and pass them directly, making coin selection the
caller's responsibility. This made the API difficult to use and
prevented reuse of the existing CoinSelectionSource trait.

Introduce a two-phase API: splice_channel now returns a FundingTemplate
that callers use to build a FundingContribution via wallet-backed
splice methods (e.g., splice_in_sync, splice_out_sync), which handle
coin selection automatically. The completed contribution is then passed
to a new funding_contributed method to begin quiescence and negotiation.

This also renames SpliceContribution to FundingContribution and moves
fee estimation and input validation into the funding module, co-located
with the types they operate on.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 28/100

This commit refactors how Lightning channel 'splicing' is started. Instead of requiring the user to manually pick coins and hand them to the API, it splits the process into two steps: first the library returns a 'funding template', then the user's wallet automatically selects coins through a standard trait and the result is handed back. The change is mostly an API usability improvement and moves fee-estimation/validation code into a dedicated module. There is no direct evidence in the commit that it fixes a security vulnerability; it is a design/API change.

AI review queuedRun rustfmt on fuzzby Jeffrey Czyz · df777e8d · Feb 17, 2026 · 3 filesMessage 38 · OpaqueInformational 15Details
Commit message · Jeffrey Czyz

Run rustfmt on fuzz

38/100 · OpaqueMessage clarity
✓ Subject identifies a change✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
fuzzing or regression evidencesecond-pass: opaque commit message
AI analysis · Informational 15/100

This commit only reformats code in test/fuzz files using rustfmt. It reorders import statements and wraps a constructor call across more lines. No program behavior, logic, or security properties are changed.

AI review queuedMake ClaimId optional in coin selectionby Jeffrey Czyz · 4cae129b · Feb 17, 2026 · 2 filesMessage 80 · StrongLow 27Details
Commit message · Jeffrey Czyz

Make ClaimId optional in coin selection

CoinSelectionSource is used for anchor bumping where a ClaimId is passed
in to avoid double spending other claims. To re-use this trait for
funding a splice, the ClaimId must be optional. And, if None, then any
locked UTXOs may be considered ineligible by an implementation.

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 27/100

This commit changes how a wallet picks coins to spend when building Bitcoin transactions. Previously, every coin selection had to be tied to a specific 'claim ID' used to avoid accidentally spending the same coin twice across different claims. Now the claim ID is optional so the same code can be reused for a new feature called 'splicing.' When no claim ID is provided, the code is designed to treat the spend as unique and avoid double-spending locked coins. The change includes safety checks to skip the 'force conflicting spend' path when there is no claim ID.

AI review queuedUse FundingTxInput instead of Utxo in CoinSelectionby Jeffrey Czyz · fc3fa7ca · Feb 17, 2026 · 6 filesMessage 85 · StrongLow 27Details
Commit message · Jeffrey Czyz

Use FundingTxInput instead of Utxo in CoinSelection

In order to reuse CoinSelectionSource for splicing, the previous
transaction of each UTXO is needed. Update CoinSelection to use
FundingTxInput (renamed to ConfirmedUtxo) so that it is available.

This requires adding a method to WalletSource to look up a previous
transaction for a UTXO. Otherwise, Wallet's implementation of
CoinSelectionSource would need WalletSource to include the previous
transactions when listing confirmed UTXOs to select from. But this would
be inefficient since only some UTXOs are selected.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 27/100

This commit refactors how the Lightning Dev Kit (LDK) selects coins for on-chain Bitcoin transactions. It changes the internal data structure used during coin selection so that each selected coin now carries the full previous transaction that created it, not just the coin's own details. The main stated reason is to prepare for a future feature called 'splicing.' The commit also adds a new wallet method to look up those previous transactions on demand. There is no direct evidence in the commit that this fixes an active security bug, but it does touch code that handles real money (transaction fees and UTXOs) and changes a public wallet interface, so downstream implementers need to update their code.