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

Add a `payment_metadata` map in blinded payment path contexts

Public commit record

What the developer wrote

Authored by Matt Corallo

83/100 · Strong
Add a `payment_metadata` map in blinded payment path contexts

Similar to how BOLT 11 payments can use a `payment_metadata` to
provide arbitrary bytes in the invoice to be communicated back to
them when receiving, its useful to be able to provide some bytes
which are communicated back upon receiving a payment.

Here we do so in the BOLT 12 blinded path contexts, offering a
`BTreeMap<u64, Vec<u8>>` instead to enable more easily including
multiple sets of data.

Also note that a `Router` building a blinded path is allowed to
modify the `payment_metadata` without breaking the payment.

Tests 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 an optional `payment_metadata` field to BOLT 12 blinded payment contexts in the Lightning Dev Kit. It lets payment recipients attach small pieces of custom data (like an order ID) to a payment path, which are then returned to them when the payment arrives. The change is a feature addition, not a fix for a known vulnerability, and the metadata is explicitly treated as opaque data that LDK does not interpret.

Recommended action

No immediate action required; this is a feature commit. Reviewers may want to confirm that downstream callers enforce reasonable size limits on `payment_metadata` before it reaches the onion, since oversized metadata can render payments unpayable or increase probing surface.

Security signals we found

01

New untrusted data field added to payment onion (payment_metadata)

02

Documentation warns that large metadata can make payments unpayable

03

Router is explicitly permitted to modify metadata without breaking payment validity

04

Serialization uses custom BigSizeKeyedMap with duplicate-key rejection on read

05

No input validation or size cap enforced in code beyond onion size constraints

Risk score

Why this scored 23/100

Our methodology →
Potential impact 2/30
Exploitability 3/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.