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

Fix trampoline onion encoding to match doc-declared CLTV rules

Public commit record

What the developer wrote

Authored by Matt Corallo

85/100 · Strong
Fix trampoline onion encoding to match doc-declared CLTV rules

The docs for `RouteHop::cltv_expiry_delta` claim that it includes
any trampoline hops, but the way we actually implemented onion
building it did not.

Because the docs described a simpler and more backwards-compatible
API, we update the onion-building logic to match rather than
updating the docs.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit fixes a mismatch between the documented behavior and the actual code for building trampoline payment onions in the Lightning Dev Kit. The documentation said that a route hop's time-lock delta already includes any trampoline hops, but the onion-building code was not doing that. The fix changes the code to match the documented (and simpler, more backwards-compatible) behavior. In practical terms, before the fix, trampoline payments could have been constructed with incorrect CLTV (time-lock) values, which could cause payment failures or, in edge cases, affect safety margins for time-locked refunds.

Recommended action

Review and merge the patch, then run the updated trampoline and blinded-path payment tests. Operators using trampoline payments should upgrade to ensure their outbound onions conform to the documented CLTV semantics and avoid payment failures or reduced time-lock safety margins.

Security signals we found

01

CLTV/time-lock mismatch between documentation and implementation

02

Trampoline onion payload construction bug

03

Potential payment failure or refund-safety margin reduction due to incorrect outgoing_cltv_value

04

Backwards-compatible API contract enforcement

05

No explicit vendor security disclosure or CVE referenced in commit

Risk score

Why this scored 59/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 8/15
Affected reach 10/15
Confidence 7/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.