LDK
← All projectsLightning Dev Kit

rust-lightning

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

BitcoinCryptographic librariesLightning NetworkNormal
Repository coverage

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

252security candidates228second-pass queue1525AI analyses
81commits · 30 days
180commits · 60 days
553commits · 180 days
1254commits · 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.

70/100 average clarity
473Strong · 80–100
836Adequate · 60–79
294Thin · 40–59
62Opaque · 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 Rohrer15315153667
Matt Corallo43553371574
Jeffrey Czyz19545182169
Wilmer Paulino15945155169
Leo Nash11613116162
Valentine Wallace14511138169
Vincenzo Palazzo11311183
Joost Jager16224162069
elnosh391333058
auto-pr-bot2478087
shaavan22622069
Carla Kirk-Cohen78366068
Analysis record

Published AI watches

Last scanned 57 minutes ago

Moderate 55 AI analysisMessage 76 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Persistent `MonitorEvent`s' (#4491)

This commit makes on-chain 'MonitorEvent' notifications durable and replay-safe. Previously, if a node crashed after a ChannelMonitor persisted a block update but before the ChannelManager processed the resulting event, the event could be …

Durability/atomicity fix for async persistence: prevents lost MonitorEvents across crashesNew ack-based event lifecycle with random event IDsArchival gating on unacknowledged events to avoid losing preimage/timeout information
9a324e72by wpaulino+467−45912 files
No security note in commit
Low 47 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Fix payment attribution edge cases and simplify claiming' (#5021)

This commit refactors how LDK nodes claim incoming Lightning payments. It replaces a separate 'claim with known custom TLVs' method with an options struct passed to the normal claim call, and fixes two edge cases in payment attribution dat…

API change: claim_funds now takes ClaimFundsOptions, consolidating TLV-known behavior into one pathFailure-packet length bound added to prevent oversized onion error messagesIncoming failure packet truncated at 32 KiB before processing
ee7c61c2by Matt Corallo+256−17322 files
No security note in commit
Low 47 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'release utxos from failed splices' (#4973)

This change fixes a wallet bookkeeping problem in rust-lightning's built-in coin-selection wrappers. Previously, when a splice attempt failed or coin selection errored after picking UTXOs, those UTXOs stayed marked as 'reserved' in memory …

Resource exhaustion / denial-of-service via permanent in-memory UTXO reservationIncorrect state tracking in coin-selection wrapperNew API method required for correct lifecycle management (release_utxos)
7220a6fdby jkczyz+295−383 files
No security note in commit
Low 49 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Restore `Wallet` UTXO locks when coin selection fails afterwards

This commit fixes a bug in the wallet's coin-selection code. When the wallet picked UTXOs to spend, it locked them immediately so they couldn't be reused. But if a later step—fetching the change address or the previous transaction—failed, …

Resource lock leak on error pathUTXO lock state inconsistency between selection and confirmationDenial-of-service/funds-unavailability risk from persistent UTXO locks
81afd9caby elnosh+146−331 file
No security note in commit
Informational 19 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'tx-sync: Parallelize esplora status queries' (#4913)

This commit rewrites how a Lightning wallet talks to Esplora block-explorer servers so that many status checks happen in parallel instead of one at a time. It is a performance/refactoring change. There is no direct evidence in the commit t…

Concurrency/timing change in transaction confirmation logicNew inconsistency check preserved when a previously-confirmed tx is reported unconfirmedAdded defensive error path for missing pre-fetched block status
c303f515by Matt Corallo+140−371 file
No security note in commit
Low 30 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Skip Electrum creator transaction downloads' (#4992)

This change stops the Electrum-based transaction sync client from downloading the very transaction that created an output it is watching. Previously, the client could request that transaction from Electrum, even though a transaction can ne…

Avoids unnecessary Electrum transaction.get requests for watched outputsReduces information disclosure to Electrum server about watched outpointsAdds regression test verifying request suppression
c36e50cbby Matt Corallo+142−02 files
No security note in commit
Low 44 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Use preferred sPK of watched txn in electrum, not rand ones' (#4867)

This change improves how the Lightning Dev Kit's Electrum and Esplora transaction-sync clients track watched Bitcoin transactions. Previously, the code ignored the script pubkey (the 'address' associated with a transaction) supplied when r…

Previously ignored `script_pubkey` argument in `register_tx` for transaction watchersElectrum script-history queries previously used an arbitrary transaction output, which could be OP_RETURN and therefore unindexed by some Electrum serversNew logic prefers caller-supplied script pubkey and falls back to non-OP_RETURN outputs
bfe5ca89by tnull+52−243 files
No security note in commit
Low 33 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Serialize transient Event variants; move persist decision into ChannelManager' (#4791)

This commit changes how LDK stores pending event notifications. It adds serialization support for several event types that previously were not fully saved to disk, and introduces a helper method so the code can decide which events are wort…

Data-loss prevention: previously non-round-trippable event variants are now fully serialized, avoiding accidental event loss when users serialize Event queues themselvesState-consistency hardening: ChannelManager now explicitly skips events that describe non-surviving restart state, preventing replay of stale eventsDefensive assertion: debug builds assert that every persisted event round-trips to Some(event), catching serialization mismatches
a0d4632eby Matt Corallo+694−818 files
No security note in commit
Informational 15 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Document that funding signing events can go stale' (#4960)

This commit only adds documentation comments to two source files. It explains that certain funding-signing events can become stale if the underlying negotiation fails, and that callers may see specific harmless errors as a result. No code …

26eecf2dby Matt Corallo+15−02 files
No security note in commit
Moderate 58 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Add `Wallet::release_utxos` to free UTXOs from abandoned transactions

This commit fixes a design flaw in LDK's built-in wallet helper where coins selected for a splice-in (or other unclaimed funding) were permanently reserved in memory if the transaction was abandoned. Over repeated failed splices, all spend…

Denial-of-service via UTXO exhaustion from repeated failed splice negotiationsRisk of inability to broadcast fee-bumping/claim transactions due to lack of available UTXOsNew API surface (release_utxos) introduced to mitigate resource leak
52ab13fdby elnosh+148−43 files
Vendor flagged security relevance
Informational 15 AI analysisMessage 100 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Drop the honggfuzz version pin from the CI fuzz job

This commit removes a fixed-version pin for the honggfuzz fuzzing tool in a continuous-integration script. The project now uses the current release of honggfuzz instead of an older pinned version. There is no change to the actual Lightning…

4a1635efby auto-pr-bot+1−51 file
No security note in commit
Informational 15 AI analysisMessage 86 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Run the CI fuzz job on the stable toolchain

This commit changes the Rust toolchain used in the continuous integration (CI) fuzzing job from a fixed older version (1.75) to the latest stable release. It is purely a build/test infrastructure change to fix a dependency compatibility is…

21c4ed2bby auto-pr-bot+3−32 files
No security note in commit
Informational 19 AI analysisMessage 91 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Expose the dummy-hop tail constructor publicly

This commit makes a previously internal helper function public so that outside developers can build dummy-hop tails for blinded payment paths without recreating the logic themselves. It is an API usability change, not a fix for a known sec…

No security-relevant behavior change in the diffAPI visibility broadened from crate-public to publicCLTV expiry overflow check already present and unchanged
c5443353by auto-pr-bot+14−71 file
No security note in commit
Moderate 54 AI analysisMessage 100 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Fail commitment sig verification without counterparty params

This change adds a safety check in a Bitcoin Lightning Network library (LDK). Previously, if the software tried to verify a peer's commitment signature before it had learned the peer's channel parameters, it could crash with a panic. Now i…

Defensive check added on peer-driven code path to prevent panicMissing counterparty_parameters could previously cause panic during commitment transaction constructionChannel closure returned instead of panic
de7ecc2fby auto-pr-bot+24−01 file
Vendor flagged security relevance
Informational 15 AI analysisMessage 100 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Clarify the commitment validation failure message

This commit only changes the wording of an error message sent to peers when a commitment transaction fails validation. It replaces the vague phrase 'Failed to validate our commitment' with the clearer 'Received commitment failed validation…

3284a006by auto-pr-bot+11−114 files
No security note in commit
Moderate 61 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Move holder commit sig checks to `InMemorySigner`' (#4885)

This commit moves the checks that validate a counterparty's signatures on the holder's commitment and HTLC transactions out of the general channel code and into the signer module (InMemorySigner). Previously, these signature checks were do…

Moved signature validation from channel state machine into signer moduleAdded new tests that corrupt signatures and verify rejectionChanged error message from 'Invalid commitment tx signature from peer' / 'Invalid funding_created signature from peer' to 'Failed to validate our commitment'
83f5ba55by Matt Corallo+626−31024 files
No security note in commit
Low 42 AI analysisMessage 86 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Drop stale splice signature on disconnect' (#4954)

This change fixes a Lightning channel splicing bug: when two peers temporarily disconnect during a splice, any half-finished signature the other side already sent is now discarded. Before the fix, that stale signature could be reused after…

State-invalidation bug in multi-step protocol (splice negotiation)Stale cryptographic signature not cleared on disconnectPotential reuse of old commitment state after reconnect
c9a77251by Matt Corallo+22−12 files
No security note in commit
Moderate 58 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Drop stale splice signature on disconnect

This fix prevents a Lightning channel from being accidentally force-closed. During a splice (a way to resize a payment channel), one side's initial signature could be kept in memory after the peers disconnected. If the peers later reconnec…

State inconsistency: in-memory buffered message not cleared on disconnectDuplicate message processing after reconnectionForce-close consequence for active Lightning channel
71405b4bby Wilmer Paulino+22−12 files
Vendor flagged security relevance
Informational 20 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'offers: rename matches_invoice_signing_pubkey to key_can_sign_invoice' (#4942)

This commit is a simple rename of a public function from `matches_invoice_signing_pubkey` to `key_can_sign_invoice`, plus matching updates to its documentation, callers, tests, and changelog. No behavior changed. It is not a security fix.

a476cf92by Matt Corallo+13−133 files
No security note in commit
Informational 15 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

offers: rename matches_invoice_signing_pubkey to key_can_sign_invoice

This commit is a simple rename of a function and its documentation from matches_invoice_signing_pubkey to key_can_sign_invoice. No logic, behavior, or security properties changed. It is a follow-up code-review naming cleanup.

388187caby Vincenzo Palazzo+13−133 files
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-priorityDefault to anchor channelsby elnosh · aebcd1f7 · Feb 5, 2026 · 9 filesMessage 50 · ThinLow 42Details
Commit message · elnosh

Default to anchor channels

Set `negotiate_anchors_zero_fee_htlc_tx` default
to true.

50/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides an explanatory body
AI analysis · Low 42/100

This commit changes the default setting so that new Lightning channels will use 'anchor outputs' whenever possible. Anchor outputs are a safer, more modern channel type, but they require the user to keep some on-chain bitcoin available to pay fees during an emergency force-close. To make sure users notice this new responsibility, the library now also forces every inbound channel request to be manually accepted. The change is a deliberate policy update, not a hidden bug, but it could surprise users who are not prepared to maintain the extra on-chain reserve.

Security candidateRemove automatic channel acceptanceby elnosh · cad035db · Feb 5, 2026 · 26 filesMessage 58 · ThinLow 36Details
Commit message · elnosh

Remove automatic channel acceptance

Removes the `manually_accept_inbound_channels` config
option. In upcoming commit we will default to anchor
channels which requires users checking if they have
enough onchain funds to cover fees in case of a force
close. Hence, we move to always require users to
manually accept inbound channels.

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathboot or update path
AI analysis · Low 36/100

This commit removes the automatic acceptance of incoming Lightning channels in the LDK library. Previously, users could set a flag to automatically accept inbound channel requests. Now, every inbound channel request must be explicitly approved by the user through an OpenChannelRequest event. This is a deliberate design change to ensure users verify they have enough on-chain funds to cover fees, especially with upcoming anchor channel defaults. It is not a fix for an active vulnerability, but it prevents accidental or unsafe channel acceptance.

Lower-priorityFix off-by-one for unfunded channel peersby elnosh · b6bd3866 · Feb 5, 2026 · 2 filesMessage 68 · AdequateModerate 52Details
Commit message · elnosh

Fix off-by-one for unfunded channel peers

When accepting channels manually, it would
fail if the # of peers without funded channels
was == `MAX_UNFUNDED_CHANNEL_PEERS`, however,
it should fail if the # of peers > `MAX_UNFUNDED_CHANNEL_PEERS`.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Moderate 52/100

This commit fixes a small boundary error in how Lightning Dev Kit counts peers that have unfunded channels. Previously, the software rejected new channel requests one peer too early, meaning legitimate users could be blocked from opening a channel when they were exactly at the configured limit. The fix changes the comparison from 'greater than or equal to' to 'greater than' the limit, restoring the intended behavior.

Lower-priorityDrop `SplicePrototype` featureby Matt Corallo · 5427b0de · Feb 5, 2026 · 1 fileMessage 58 · ThinInformational 15Details
Commit message · Matt Corallo

Drop `SplicePrototype` feature

Now that `SplicePrototype` and `SpliceProduction` share the same
feature bit, there's not really any reason to have the
`SplicePrototype` feature at all. Instead, we drop it, leaving only
a `Splice` feature.

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This commit is a routine cleanup of internal feature-flag names in a Lightning network library. It removes a duplicate 'SplicePrototype' label and keeps a single 'Splice' label for the same protocol feature bit. There is no security bug being fixed here.

AI review queuedSwitch `SplicePrototype` feature flag to the prod feature bitby Matt Corallo · 98c3cfff · Feb 5, 2026 · 1 fileMessage 73 · AdequateLow 33Details
Commit message · Matt Corallo

Switch `SplicePrototype` feature flag to the prod feature bit

When we shipped 0.2 we used the feature bit 155 to signal splicing,
in line with what eclair was using. However, eclair was actually
using that bit to signal splicing on a previous design which is
incompatible with the current spec.

The result of this was that eclair nodes may attempt to splice
using their protocol and we'd fail to deserialize their splice
message (resulting in a reconnect, which luckily would clear their
splice attempt and return the connection to normal).

As we really need to get off of their feature bit and there's not
much reason to keep using a non-final-spec bit, we simply redefine
`SplicePrototype` to bit 63 here.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
second-pass: broader security terminology
AI analysis · Low 33/100

This commit changes which 'feature bit' the Lightning Dev Kit uses to advertise experimental channel splicing support. Previously it used bit 155, the same bit an older Eclair implementation used for a different, incompatible splicing design. That mismatch could cause Eclair nodes to try to splice with LDK using the wrong protocol, leading to failed message parsing and repeated reconnects. The fix moves LDK's prototype splicing flag to bit 63, avoiding the collision. It is a protocol-compatibility fix, not a cryptographic vulnerability, but it does prevent a real interoperability failure.

Security candidateSupport async signing of interactive-tx initial commitment signaturesby Wilmer Paulino · ee742092 · Feb 5, 2026 · 3 filesMessage 73 · AdequateLow 27Details
Commit message · Wilmer Paulino

Support async signing of interactive-tx initial commitment signatures

This commit allows for an async signer to immediately return upon a call
to `EcdsaChannelSigner::sign_counterparty_commitment` for the initial
commitment signatures of an interactively funded transaction, such that
they can call back in via `ChannelManager::signer_unblocked` once the
signatures are ready. This is done for both splices and dual-funded
channels, though note that the latter still require more work to be
integrated. Since `tx_signatures` must be sent only after exchanging
`commitment_signed`, we make sure to hold them back if they're ready to
be sent until our `commitment_signed` is also ready.

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

This commit adds support for asynchronous (delayed) signing when opening or splicing Lightning channels that use the newer interactive-funding protocol. Previously, if a hardware or remote signer was not ready to produce the initial commitment signature, the code either did not support the delay or could accidentally send transaction signatures before the commitment signature was ready. The change holds back the transaction-signature message until the commitment signature is available, and adds a regression test for splicing. It is a protocol-correctness and robustness improvement rather than a fix for an active exploit.

Security candidatefuzz: fix ChaCha20 encrypt_single_block to preserve databy Joost Jager · dde2c822 · Feb 5, 2026 · 1 fileMessage 83 · StrongLow 27Details
Commit message · Joost Jager

fuzz: fix ChaCha20 encrypt_single_block to preserve data

The fuzzing ChaCha20 implementation's encrypt_single_block was not
copying src to dest, causing encrypted data to be lost (dest remained
zeros). This broke payment flows where metadata is encrypted into
payment_secret - the receiver would decrypt zeros and detect the wrong
payment method (LdkPaymentHash instead of UserPaymentHash), causing
payments to fail with "mismatching preimage".

Fix by making encrypt_single_block copy src to dest (identity
encryption), matching the behavior of the process() method.

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

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidencecryptography-sensitive path
AI analysis · Low 27/100

This commit fixes a bug in a fuzzing-only (test-only) fake version of the ChaCha20 encryption code. The fake encryptor accidentally left the output as all zeros instead of copying the input, which caused simulated Lightning payments to fail during testing. The fix makes the test fake copy input to output unchanged. This is not a real cryptographic vulnerability and does not affect production code.

Lower-prioritySimplify in_flight_monitor_updates from Option<HashMap> to HashMapby Joost Jager · b509c4a9 · Feb 5, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Joost Jager

Simplify in_flight_monitor_updates from Option<HashMap> to HashMap

Since there is no semantic difference between None and Some(empty map)
for in_flight_monitor_updates, simplify the type to HashMap and use
unwrap_or_default() when reading from TLV fields.

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

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This is a straightforward internal code cleanup in the Lightning Dev Kit's channel manager. It changes a data field from 'optional map' to just 'map' because an empty map means the same thing as no map. There is no security-relevant behavior change.

Lower-priorityCombine claimable HTLCs with purposes in ChannelManagerDataby Joost Jager · 07bcba97 · Feb 5, 2026 · 1 fileMessage 83 · StrongLow 29Details
Commit message · Joost Jager

Combine claimable HTLCs with purposes in ChannelManagerData

Move the reconstruction of claimable_payments from the main
ChannelManager::read into ChannelManagerData::read. This removes
the separate claimable_htlc_purposes and claimable_htlc_onion_fields
fields from ChannelManagerData, replacing them with the combined
claimable_payments HashMap.

This requires adding a node_signer parameter to ChannelManagerDataReadArgs
to support verification of legacy hop data when reconstructing payment
purposes for very old serialized data (pre-0.0.107).

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

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
defensive validation
AI analysis · Low 29/100

This commit is a code-cleanup refactor that moves the reconstruction of claimable payment data from one deserialization function to another. It does not change the underlying security logic but reorganizes how legacy payment records are verified when loading old wallet state. There is no direct evidence in the commit that this fixes an active security vulnerability.

Lower-prioritySimplify peer_storage_dir from Option<Vec> to Vec in ChannelManagerDataby Joost Jager · 47901533 · Feb 5, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Joost Jager

Simplify peer_storage_dir from Option<Vec> to Vec in ChannelManagerData

Since there is no semantic difference between None and Some(empty vec)
for peer_storage_dir, simplify the type to Vec and use unwrap_or_default()
when reading from TLV fields.

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

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This is a small internal code cleanup in the Lightning Dev Kit's Rust implementation. It changes a data structure field from 'optional list' to just 'list', because an empty list and a missing list meant the same thing. There is no security-relevant change here.

Lower-priorityGroup legacy fields in ChannelManagerData to deduplicate commentby Joost Jager · 77be67b0 · Feb 5, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Joost Jager

Group legacy fields in ChannelManagerData to deduplicate comment

Reorder the struct fields to place all three `_legacy` fields together
at the end, allowing the explanatory comment to appear once instead of
being duplicated three times.

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

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This commit is a pure code cleanup: it rearranges three struct fields in the Lightning channel manager so that a single comment can explain all of them instead of repeating the same comment three times. No behavior changes, no security fixes, and no bug fixes are present.

Lower-priorityUse consistent unwrap_or_else pattern for optional TLV fieldsby Joost Jager · 4a640d15 · Feb 5, 2026 · 1 fileMessage 73 · AdequateInformational 12Details
Commit message · Joost Jager

Use consistent unwrap_or_else pattern for optional TLV fields

Initialize pending_claiming_payments and monitor_update_blocked_actions_per_peer
with None and resolve with unwrap_or_else, matching the pattern used for other
optional hash map fields like pending_intercepted_htlcs_legacy.

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

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 12/100

This is a small internal code cleanup in the Lightning Dev Kit's channel manager. It changes how two optional data fields are initialized during deserialization so they follow the same safe pattern already used elsewhere. There is no indication this fixes a security vulnerability or changes observable behavior for users.

Lower-priorityAdd a `custom` TLV read/write variantby Matt Corallo · 05c9a036 · Feb 4, 2026 · 2 filesMessage 68 · AdequateInformational 12Details
Commit message · Matt Corallo

Add a `custom` TLV read/write variant

At various points we've been stuck in our TLV read/write variants
but just want to break out and write some damn code to initialize
a field and some more code to decide what to write for a TLV.

We added the write-side part of this with the `legacy` TLV
read/write variant, but its useful to also be able to specify a
function which is called on the read side.

Here we add a `custom` TLV read/write variant which calls a method
both on read and write to either decide what to write or to map a
read value (if any) to the final field.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 12/100

This commit adds a new 'custom' variant to LDK's TLV (Type-Length-Value) serialization macros. It is a developer-facing feature that lets programmers supply custom read and write functions when serializing/deserializing data structures. The change is purely additive and does not by itself fix a bug or introduce a vulnerability; it is infrastructure for future message formats.

Lower-priorityResource manager implementationby elnosh · beb3a57c · Feb 4, 2026 · 3 filesMessage 58 · ThinTriage 0Details
Commit message · elnosh

Resource manager implementation

Introduces the ResourceManager struct. The core of methods that will
be used to inform the HTLC forward decisions are add/resolve_htlc.

- add_htlc: Based on resource availability and reputation, it
evaluates whehther to forward or fail the HTLC.

- resolve_htlc: Releases the bucket resources used from a HTLC
previously added and updates the channel's reputation based on HTLC
fees and resolution times.

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Lower-priorityAdd Channel to resource managerby elnosh · 7b4ae500 · Feb 4, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · elnosh

Add Channel to resource manager

The Channel struct introduced here has the core information that
will be used by the resource manager to make forwarding decisions
on HTLCs:

- Reputation that this channel has accrued as an outgoing link
in HTLC forwards.

- Revenue (forwarding fees) that the channel has earned us as an
incoming link.

- Pending HTLCs this channel is currently holding as an outgoing link.

- Bucket resources that are currently in use in general, congestion
and protected.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityAdd BucketResources to resource managerby elnosh · e235d66c · Feb 4, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · elnosh

Add BucketResources to resource manager

Resources available in the channel will be divided into general,
congestion and protected resources. Here we implement the bucket
resources that will be used for congestion and protected.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityAdd GeneralBucket to resource managerby elnosh · 4a5a9c75 · Feb 4, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · elnosh

Add GeneralBucket to resource manager

Resources available in the channel will be divided into general,
congestion and protected resources. Here we implement the general
bucket with basic denial of service protections.

Co-authored-by: Carla Kirk-Cohen <kirkcohenc@gmail.com>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Security candidateUse SignedAmount::unsigned_abs to avoid overflowby Jeffrey Czyz · 2d948fdd · Feb 4, 2026 · 1 fileMessage 85 · StrongLow 34Details
Commit message · Jeffrey Czyz

Use SignedAmount::unsigned_abs to avoid overflow

In debug mode, using SignedAmount::abs can lead to an integer overflow
when used with SignedAmount::MIN. Use SignedAmount::unsigned_abs to
avoid this.

85/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
Why it was queued
memory safety
AI analysis · Low 34/100

This commit fixes a potential integer overflow bug in the Lightning Dev Kit's channel splicing code. The bug occurs when converting a negative Bitcoin amount to its absolute value in debug builds, which could crash the program. The fix uses a safer method that cannot overflow. The practical security impact is limited because the overflow only happens in debug mode and the affected values are normally constrained by protocol rules.

Lower-priorityAdd SmoothedDecayingAverage to resource managerby elnosh · c0447e18 · Feb 3, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · elnosh

Add SmoothedDecayingAverage to resource manager

The SmoothedDecayingAverage implemented here will be used in
upcoming commits to track the incoming revenue that channels have
generated through HTLC forwards.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityAdd DecayingAverage to resource managerby elnosh · 8bae0610 · Feb 3, 2026 · 2 filesMessage 68 · AdequateTriage 0Details
Commit message · elnosh

Add DecayingAverage to resource manager

Implements a decaying average over a rolling window. It will be
used in upcoming commits by the resource manager to track
reputation and revenue of channels.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityCheck semver of all workspace crates rather than an explicit listby Matt Corallo · a123cfa0 · Feb 3, 2026 · 1 fileMessage 50 · ThinInformational 15Details
Commit message · Matt Corallo

Check semver of all workspace crates rather than an explicit list

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
documentation-only discount
AI analysis · Informational 15/100

This commit updates an automated GitHub workflow that checks whether code changes break promised version compatibility. It replaces a manually maintained list of checks with a single tool command that scans all crates in the project. There is no change to the actual Lightning library code, user-facing behavior, or network security.

AI review queuedCorrect crate version numbers that have broken semverby Matt Corallo · 784b85c1 · Feb 3, 2026 · 10 filesMessage 73 · AdequateInformational 15Details
Commit message · Matt Corallo

Correct crate version numbers that have broken semver

The semver CI check is great but only checks the immediate crate in
question. It doesn't catch that many of our crates depend on
`lightning` and thus have actually broken semver as the types they
use have changed to `lightning` 0.3.

Here we hump the version of crates that have actually changed
semver since 0.2.

In addition to those that depend on `lightning`,
`lightning-invoice`'s API has changed (but was not being checked by
the semver CI task).

Finally, `lightning-macros` was updated to 0.2.1, so the version is
changed to 0.2.2.

73/100 · AdequateMessage clarity
✓ Specific, 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 only changes version numbers in package configuration files (Cargo.toml). It bumps crate versions from 0.2.x to 0.3.x to keep them aligned with semantic versioning rules after the underlying `lightning` crate changed its public types. There is no code change, no bug fix, and no security patch.

Security candidateFix 0.2 CHANGELOG to note that offers will break on downgradeby Matt Corallo · e245c0aa · Feb 3, 2026 · 1 fileMessage 73 · AdequateInformational 18Details
Commit message · Matt Corallo

Fix 0.2 CHANGELOG to note that offers will break on downgrade

It turns out we also switched the key we use to authenticate offers
*created* in the 0.2 upgrade and as a result downgrading to 0.2
will break any offers created on 0.2. This wasn't intentional but
it doesn't really seem worth fixing at this point, so just document
it.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
update trustdocumentation-only discount
AI analysis · Informational 18/100

This commit is a documentation-only update to the 0.2 release CHANGELOG. It adds a note warning users that if they upgrade to LDK 0.2, create BOLT 12 offers, and then downgrade to an older LDK version, those offers will not be accepted. This is a compatibility/operational issue, not a security vulnerability, and no code behavior is changed.

Security candidateAdd AChainMonitor trait and use it in background processorby Joost Jager · 4800a473 · Feb 3, 2026 · 2 filesMessage 73 · AdequateInformational 15Details
Commit message · Joost Jager

Add AChainMonitor trait and use it in background processor

Add a new `AChainMonitor` trait following the same pattern as
`AChannelManager`. This trait provides associated types for all
generic parameters of `ChainMonitor` and a `get_cm()` method to
access the underlying `ChainMonitor`.

Update the background processor to use `AChainMonitor` trait bounds
instead of spelling out the full `ChainMonitor` generic parameters.
This simplifies the function signatures by removing 5-6 explicit
generic parameters (CF, T, F, P, ES) per function.

This is preparation for adding a flush method to the AChainMonitor
trait.

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

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

This commit is a pure internal refactoring in the Lightning Dev Kit Rust library. It introduces a new helper trait called AChainMonitor that wraps the existing ChainMonitor type, and updates background-processor functions to use that trait instead of listing many generic type parameters directly. There is no change to user-visible behavior, no bug fix, and no security-sensitive logic change.

AI review queuedAdd Utxo::new_v1_p2trby Willem Van Lint · 1f6095b5 · Feb 2, 2026 · 1 fileMessage 28 · OpaqueInformational 15Details
Commit message · Willem Van Lint

Add Utxo::new_v1_p2tr

28/100 · OpaqueMessage clarity
✓ Subject identifies a change! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: opaque commit messagesecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit adds a new helper function to create a UTXO descriptor for modern Taproot (P2TR) single-key spending. It is purely additive API surface with no changes to existing behavior, no bug fixes, and no security-sensitive logic beyond correctly estimating transaction weight for fee calculations.