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

refactor: zcash transparent and orchard logic

Public commit record

What the developer wrote

Authored by soralit

57/100 · Thin
refactor: zcash transparent and orchard logic
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
The short version

What changed, and why it matters

This commit is a large refactor of how the Keystone 3 firmware handles Zcash transactions. It splits the code into two build flavors: a 'multi-coins' build that supports only transparent (public) Zcash addresses using a normal xpub, and a 'cypherpunk' build that also supports shielded Orchard addresses using a unified full viewing key (UFVK). The change reorganizes feature flags, renames functions, and adjusts how Zcash account data is cached when wallets are created or unlocked. There is no explicit security fix or vulnerability disclosure in the commit message, and the diff itself is mostly structural. A few small items stand out as worth checking: a typo in a feature-guard macro (CYBERPUNK_VERSION vs CYPHERPUNK_VERSION) could leave the cypherpunk UI path disabled, and a debug printf was left in production key-handling code. On its own, this commit does not appear to introduce a clear exploitable vulnerability, but it is a partial refactor and the new multi-coins transparent-only path is simpler and exposes less shielded-key material than before.

Recommended action

Treat this as a code-quality and build-configuration review item rather than a confirmed vulnerability. Verify that the CYBERPUNK_VERSION typo in src/ui/gui_chain/multi/gui_zcash.c is intentional or fix it to CYPHERPUNK_VERSION. Remove the debug printf in account_public_info.c before release. Confirm that the new multi_coins transparent-only APIs correctly reject orchard/spend data and that feature flags are mutually exclusive where intended. Run tests for both zcash_multi_coins and zcash_cypherpunk builds to ensure no regression in transaction parsing or signing.

Security signals we found

01

Refactor splits Zcash shielded (Orchard/UFVK) and transparent-only code paths by build feature

02

Cypherpunk build continues to handle encrypted UFVK and Orchard actions; multi-coins build uses only transparent xpub

03

Likely typo in feature macro: CYBERPUNK_VERSION instead of CYPHERPUNK_VERSION in src/ui/gui_chain/multi/gui_zcash.c

04

Debug printf left in RSA_KEY handling path in src/crypto/account_public_info.c

05

Removal of ZCASH_UFVK_ENCRYPTED_0 from WEB3 chain table reduces shielded-key exposure in multi-coins builds

06

New SetupZcashSFP routine caches only seed fingerprint for WEB3 builds, while SetupZcashCache remains for cypherpunk builds

Risk score

Why this scored 24/100

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