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

Proper fee estimation

Public commit record

What the developer wrote

Authored by Keeqler

28/100 · Opaque
Proper fee estimation
✓ Subject identifies a change! No meaningful explanatory body
The short version

What changed, and why it matters

This commit changes how the Skylight Wallet app estimates Monero transaction fees. Previously, the app calculated fees by actually building full draft transactions and then reusing those draft transactions when the user pressed send. Now it uses a dedicated native fee-estimation function and always builds the real transaction only when the user confirms the send. The change also switches the underlying Monero library from a personal repository (vtnerd/monero_c) to an organization-owned fork (magicgrants/monero_c). The main security-relevant effect is reducing the risk that a stale or reused draft transaction gets sent accidentally, and it removes a retry loop that could have produced misleading fee information. There is no explicit security bug fixed in the diff itself, so the security relevance is moderate and inferred.

Recommended action

Treat this as a defensive hardening change rather than an urgent security patch. Review the new estimateFee() implementation for correct failure handling and ensure the magicgrants/monero_c fork is kept in sync with upstream security fixes. Verify that the deprecated Wallet_estimateTransactionFee FFI call is replaced when the upstream API changes. Users should update to the version containing this commit to benefit from more reliable fee estimates and reduced transaction-reuse risk.

Security signals we found

01

Eliminates reuse of cached pending transactions for fee display and later sending, reducing risk of stale/fee-mismatched transaction submission

02

Removes a 10-attempt retry loop around createTx() that silently swallowed 'Unlocked funds too low' errors and could present inaccurate fee data

03

Adds native fee estimation via deprecated FFI API with null/0 failure handling

04

Switches upstream Monero C library source from vtnerd/monero_c to magicgrants/monero_c fork

05

Adds UI '~' prefix to estimated fees to signal they are approximate

06

No explicit security disclosure, CVE, or advisory referenced in commit or supplied materials

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.