Skip to content

Add draft ZIP: Deterministic Orchard Wallet Scanning Standard#1158

Closed
Lowo88 wants to merge 1 commit intozcash:mainfrom
Lowo88:draft-lowo88-deterministic-orchard-scanning
Closed

Add draft ZIP: Deterministic Orchard Wallet Scanning Standard#1158
Lowo88 wants to merge 1 commit intozcash:mainfrom
Lowo88:draft-lowo88-deterministic-orchard-scanning

Conversation

@Lowo88
Copy link

@Lowo88 Lowo88 commented Jan 16, 2026

This Standards Track ZIP specifies a deterministic algorithm for scanning Orchard notes in Zcash wallets. The specification ensures that all wallet implementations produce identical results when scanning the same block range, addressing critical issues with wallet reliability and interoperability.

Key features:

  • Deterministic block, transaction, and action processing order
  • Comprehensive note deduplication and spent status tracking
  • Test vectors for verification
  • Reference implementation from NozyWallet/Zkool
  • Backward compatible with existing ZIPs

This Standards Track ZIP specifies a deterministic algorithm for scanning Orchard notes in Zcash wallets. The specification ensures that all wallet implementations produce identical results when scanning the same block range, addressing critical issues with wallet reliability and interoperability.

Key features:
- Deterministic block, transaction, and action processing order
- Comprehensive note deduplication and spent status tracking
- Test vectors for verification
- Reference implementation from NozyWallet
- Backward compatible with existing ZIPs
Comment on lines +21 to +22
**Non-Deterministic Results**: Different wallets may produce different results
when scanning the same block range.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is incorrect. The state of the wallet is a function of the contents of the blockchain; the order of scanning is irrelevant (modulo implementation bugs.)

**Non-Deterministic Results**: Different wallets may produce different results
when scanning the same block range.

**Inconsistent Wallet State**: Wallet restores may produce different results.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same issue, this is also flatly incorrect.


**Inconsistent Wallet State**: Wallet restores may produce different results.

**Interoperability Issues**: Users cannot reliably switch between wallet
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interoperability concerns are the purview of ZIP 315. If there are specific standards required for interoperability (such as standards around key handling), I would recommend that you suggest them there.

@nuttycom
Copy link
Contributor

Closing with @daira and @arya2; this proposal is based on a misconception about wallet state being dependent on scanning order. While this may be ephemerally true (different scanning algorithms will achieve different intermediate states) when a wallet has fully scanned the chain its value MUST be a deterministic function of chain contents irrespective of scanning order.

@nuttycom nuttycom closed this Feb 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Comments