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

refactor electrumx based coin transaction building and fee calculation

Public commit record

What the developer wrote

Authored by Julian

50/100 · Thin
refactor electrumx based coin transaction building and fee calculation
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
The short version

What changed, and why it matters

This commit refactors how Stack Wallet builds Bitcoin-like transactions and calculates fees. It introduces a new fee planner that handles three modes: normal fixed-amount sends, 'subtract fee from amount' (the recipient gets slightly less so the sender doesn't need extra funds for the fee), and sweep/all sends. The change consolidates previously scattered fee logic into one place and adds unit tests. It is a code-quality and feature refactor; there is no direct evidence in the commit that it fixes a known security vulnerability, but any change to transaction-fee logic can affect whether users accidentally overpay, underpay, or create invalid transactions.

Recommended action

Treat this as a high-risk refactor of financial logic. Review the new fee planner against edge cases: empty wallets, exact-dust amounts, multi-input size growth, MWEB peg-in/peg-out, and coin-control sends. Run the new unit tests and add integration tests for each supported coin. Monitor for user reports of unexpected fees, failed sends, or incorrect change outputs. If this commit is being backported, verify it does not change behavior for existing transaction types beyond the intended refactor.

Security signals we found

01

Refactor of transaction-fee calculation logic for ElectrumX-based coins

02

New 'subtract fee from amount' mode that reduces the recipient's output to cover fees

03

Iterative fee planner that re-measures vSize after building the transaction

04

Dust-limit checks before building outputs

05

Minimum fee floor logic to prevent underpaying

06

Insufficient-funds exception with required-fee hint for retry logic

Risk score

Why this scored 33/100

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