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

Replace FundingTemplate contribution methods with FundingBuilder

Public commit record

What the developer wrote

Authored by Wilmer Paulino

73/100 · Adequate
Replace FundingTemplate contribution methods with FundingBuilder

This results in a slight change of behavior: now these methods reuse and
amend the prior contribution, as opposed to always starting from a fresh
contribution, which would be the desired expected behavior by users.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit refactors how users build funding contributions for Lightning channel splicing and RBF (fee-bumping). It replaces several convenience methods with a builder-style API and changes the behavior so that, when a prior splice request exists, new calls amend (add to) the prior request instead of silently replacing it. The commit also removes the ability to start an RBF attempt when there is no prior contribution, and adds tests showing that prior contributions can be amended. There is no explicit security bug in the diff, but the behavioral change could affect how wallets construct splice transactions and could, if callers misunderstand the new semantics, lead to unintended transaction shapes or fee handling.

Recommended action

Treat this as a behavior-affecting API change rather than a confirmed vulnerability. Downstream wallet integrators using rust-lightning's splicing/RBF APIs should review their usage: calls that previously replaced a prior contribution may now amend it, and `rbf_sync` no longer supports fee-bump-only RBF without a prior contribution. If a security issue is suspected, request a security advisory or CVE from the project maintainers and verify whether the behavioral change was made to fix a known bug.

Security signals we found

01

Behavioral change in public API: prior contribution is now amended rather than replaced by convenience methods

02

RBF entry points now require a prior contribution and reject fee-bump-only RBF without one

03

New builder methods allow callers to add/remove value and outputs from a stored prior contribution

04

Validation logic for MAX_MONEY and feerate bounds is preserved but reorganized into the builder

05

No explicit security advisory, CVE, or vulnerability disclosure is present in the commit or supplied references

Risk score

Why this scored 27/100

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