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

Allow BOLT 11 payments to be a part of a larger MPP payment

Public commit record

What the developer wrote

Authored by Matt Corallo

83/100 · Strong
Allow BOLT 11 payments to be a part of a larger MPP payment

In some uses of LDK we need the ability to send HTLCs for only a
portion of some larger MPP payment. This allows payers to make
single payments which spend funds from multiple wallets, which may
be important for ecash wallets holding funds in multiple mints or
graduated wallets which hold funds across a trusted wallet and a
self-custodial wallet.

In the previous few commits we added support for making these
kinds of payments when using the payment methods which explicitly
accepted a `RecipientOnionFields`. Here we also add support for
such payments made via the `pay_for_bolt11_invoice` method,
utilizing the new `OptionalBolt11PaymentParams` to hide the
parameter from most calls.

Test mostly by Claude
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit adds a new, optional feature to the Lightning Dev Kit (LDK) that lets multiple wallets or devices team up to pay a single Lightning invoice. Each participating wallet can pay just part of the total, and the merchant's node sees the combined payment as one normal multi-path payment. It is a deliberate feature addition, not a bug fix, and the code includes validation to prevent obvious misuse such as paying less than promised.

Recommended action

Treat as a normal feature review. Verify that the new validation rules cannot be bypassed, that `total_mpp_amount_msat` is only set when the override is present, and that downstream payment tracking does not conflate partial local amounts with the declared total. No immediate security response is indicated by the supplied materials.

Security signals we found

01

New API surface added to `OptionalBolt11PaymentParams`

02

Validation logic added for `declared_total_mpp_value_msat_override` against invoice amount and local amount

03

Recipient onion `total_mpp_amount_msat` is set from user-supplied optional value

04

Tests added for multi-node partial BOLT11 payments and retry-after-failure scenarios

05

No mention of vulnerability, CVE, bug bounty, or security fix in commit message or diff

Risk score

Why this scored 23/100

Our methodology →
Potential impact 3/30
Exploitability 2/25
Stealth signal 2/15
Affected reach 4/15
Confidence 8/10
Evidence quality 4/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.