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

report a transaction tab height the server will not prove instead of marking it unverified until it does

Public commit record

What the developer wrote

Authored by Craig Raw

50/100 · Thin
report a transaction tab height the server will not prove instead of marking it unverified until it does
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
The short version

What changed, and why it matters

This commit changes how Sparrow Wallet shows a transaction's block height when the connected server cannot prove the transaction is actually in that block. Previously, the transaction tab would label such a height as 'Unverified' while waiting for proof. Now it shows the height plainly, and only after the server has had a fair chance to prove it and fails does it add an 'Unverified' warning. The change also makes the transaction-tab verification use the same retry logic and user-facing reporting that wallet history verification already uses, so a momentary server hiccup is not treated as a server lie.

Recommended action

Reviewers should confirm that verifyMerkleProofs(null, ...) safely handles a null wallet (no wallet-specific state is dereferenced), that the new unverifiedWarning is correctly hidden on reorg/disconnect, and that the retry budget is not exhausted by a server that is merely slow before the user is warned. No immediate security patch appears required; this is a defensive hardening change.

Security signals we found

01

UI no longer marks a transaction as unverified merely because a proof is still pending

02

Transaction-tab proof requests now share retry logic with wallet-history proof requests

03

Server refusals/failures outside any wallet are reported to the user with the same event mechanism as wallet transactions

04

A server that does not implement the proof RPC disables verification for the session rather than marking individual transactions unverified

05

Reorg and disconnect events clear the unproven-pair state so stale warnings are not shown against a new chain or connection

Risk score

Why this scored 36/100

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