Payment Rails CROPS Dashboard
Unaudited, unvetted, experimental. Do not use as a reference. AI-researched ratings that may be wrong; not advice or a statement of fact about any provider. Full disclaimer
Pending review. 1150 of 1150 ratings not yet checked by a human. Do not rely on unreviewed ratings.

Zcash (shielded transfers)

transferZcashZ Assessed on Zcash mainnet (zcash:main)z.cash

Ratings apply to this deployment only. Treat them as unverified for other chains. Why this deployment: Zcash is its own proof-of-work chain, so the unit is Zcash mainnet as defined by the maintained node, Zebra (v6.4.2, MAINNET_ACTIVATION_HEIGHTS in zebra-chain network_upgrade.rs L104-L120, NU6.3 at height 3,428,143). Scope: shielded ZEC transfers (Ironwood pool since NU6.3; Orchard spend-only per ZIP 258) and the transparent pool. Excluded: testnet, ZSAs (NU7 draft), exchanges and bridges. zcash:main is not a registered CAIP-2 namespace (ChainAgnostic/namespaces has none for Zcash); used as the brief directs.

At a glance

Category
Protocols for privacy-preserving transfers
Chain
ZcashZZcash mainnet
CROPS tally
19 of 23 hold up · 2 no evidence
Security audits
15 published
Offered
Everywhere
Last edited
2026-10-13 · History
  1. Censorship Resistance2 PartialWeakest: Admin pause or freeze powers; Settle without the provider; Neutral settlement, disclosed filtering; Token and chain freeze risks disclosed
  2. Open No evidenceWeakest: Contracts verified onchain
  3. Free0 FailsWeakest: Protection against relicensing
  4. Privacy2 PartialWeakest: Tracking and analytics; Third parties in the payment flow
  5. Security No evidenceWeakest: Audits and bug bounty

Where it is offered

Offered everywhere, per the provider's code or documents. Checked 2026-10-09. Not scored.

The protocol has no country or address rules, and the node (Zebra), the beta full-node wallet (Zallet), the light-wallet server (lightwalletd) and the reference mobile wallet (Zodl Android and iOS) contain no country or IP-geolocation gate in GitHub code search on 2026-10-09. Zodl's own website (zodl.com) refused automated requests, so we could not read any terms there; app-store distribution and optional swap or merchant integrations may have their own regional limits, which we did not evidence. Legality of use varies by jurisdiction; that is not an availability restriction by the protocol.

Evidence (2)2 verified
  1. Verified

    The wallet's default servers span North America, South America, Europe and Asia-Pacific, and nothing in the wallet selects or blocks by country.

    zodl-inc/zodl-android · ui-lib/src/main/java/co/electriccoin/zcash/ui/common/provider/LightWalletEndpointProvider.kt

    commit 4248d469c7 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    The node accepts any valid transaction; code search of ZcashFoundation/zebra for country and geoip returns nothing.

    ZcashFoundation/zebra · zebra-rpc/src/methods.rs

    commit e3eef2f37c · checked 2026-10-09

Censorship Resistance

Who can block valid use, and can users route around them?

2 PartialPillar rating: weakest of 5
5 of 5 Partial or better

What would raise this pillar

  • Admin pause or freeze powers reaching Strong: No pause, freeze, blacklist, or relayer/allowlist role that can stop settlement exists in the settlement contracts.
  • Settle without the provider reaching Strong: A payer or payee can complete settlement by calling the public contract directly, with the ABI and addresses documented.
  • Neutral settlement, disclosed filtering reaching Strong: Settlement contracts contain no address or geographic filtering, and any filtering in the SDK, frontend, or backend is disclosed in code or a versioned repo document, names its list source, and is bypassed by the direct settlement path (C2 at least 2). Requires every required component in the request path to be public, or a trace.
  • Token and chain freeze risks disclosed reaching Strong: Supported tokens and chains enumerated in code and docs, with issuer freeze/blacklist powers and sequencer or forced-inclusion assumptions stated to payees.

Admin pause or freeze powers

Can any privileged role stop, freeze, or block payments through the settlement contracts, and how is that role constrained? C1

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The Zcash consensus rules contain no admin key, pause, freeze, blacklist or allowlist role, and shielded addresses are not visible to anyone who could filter them. The rules can still be changed by coordinated node releases that miners and node operators adopt: in June 2026 the node teams shipped an emergency soft fork that disabled the whole Orchard pool for 1,174 blocks (about a day) without advance notice, to contain a balance-violation bug, documented after the fact in ZIP 257. That power is pool-wide, not per-address, and depends on miner adoption. Zebra releases also stop running 84 days after release, which forces operators to choose new software regularly. Judgment call: the substance is close to anchor 3 (no role that can target users), but the dashboard needs onchain evidence about a deployed contract for a 3, which a chain with no contract addresses cannot supply, and the June 2026 no-notice pool halt is recorded here, so we take 2.

Evidence (2)2 verified
  1. Verified

    ZIP 257 records that from Mainnet height 3363426 until NU6.2 activated at height 3364600, transactions MUST NOT contain Orchard Actions; the rule shipped as an emergency hotfix in zcashd v6.12.5 and zebra v4.5.3 after an Orchard circuit soundness bug was reported on 2026-05-29, and a first attempt 60 blocks earlier failed because some mining pools had not upgraded.

    zcash/zips · zips/zip-0257.md

    commit 3af03aa3ad · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    Each Zebra release panics ("Zebra refuses to run") on Mainnet 84 days after its estimated release height (L86-L101), so node operators must install a newer release roughly every 12 weeks; the check is in public code and can be patched out by whoever builds the node.

    ZcashFoundation/zebra · zebrad/src/components/sync/end_of_support.rs

    commit e3eef2f37c · checked 2026-10-09

Settle without the provider

Can a payer or payee complete settlement by calling the public contracts directly, without the provider's API, signer, or relayer? C2

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

A payer builds and signs a transaction in their own wallet and can submit it to any Zcash node, their own or anyone's, or to any light-wallet server; the payee receives it by scanning the chain with their viewing key. No company sits in the path. Settlement is the consensus protocol itself, specified in the ZIPs and protocol specification. Judgment call: this is the strongest form of direct settlement, but anchor 3 is defined by direct calls to public contracts and needs onchain evidence about a deployed contract, which this chain has none of, so we take 2.

Evidence (2)2 verified
  1. Verified

    zebrad's sendrawtransaction RPC accepts any signed transaction into the local node's mempool, from where it is gossiped to peers and mined; no provider signature or API key is involved.

    ZcashFoundation/zebra · zebra-rpc/src/methods.rs

    commit e3eef2f37c · checked 2026-10-09

  2. Verified

    Light wallets submit the same raw signed transaction to any lightwalletd server through SendTransaction(RawTransaction); the server only relays it to its node.

    zcash/lightwalletd · lightwallet-protocol/walletrpc/service.proto

    commit d16d48124e · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Reliance on hosted services

Does the payment flow require a relayer, paymaster, bundler, or API that only the provider runs? C3

3 Strong

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

No hosted service is required. A full-node user (Zebra plus Zallet) needs only peers. A light-wallet user needs a lightwalletd-compatible server; the code is public and self-hostable, and the reference wallet ships several independent default servers, picks one automatically, broadcasts each transaction to more than one, and accepts a custom server.

Evidence (2)2 verified
  1. Verified

    Zodl ships seven Mainnet lightwalletd endpoints from two operators (zec.rocks with regional hosts, zec.stardust.rest US and EU); ChooseServerVM.kt L148-L230 adds automatic selection and a custom server, and MultiEndpointTransactionSubmitter.kt L22-L47 submits each transaction to several endpoints.

    zodl-inc/zodl-android · ui-lib/src/main/java/co/electriccoin/zcash/ui/common/provider/LightWalletEndpointProvider.kt

    commit 4248d469c7 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    The lightwalletd README documents production self-hosting against a local zebrad; Zaino (zingolabs/zaino, Apache-2.0) is a second implementation.

    zcash/lightwalletd · README.md

    commit d16d48124e · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Neutral settlement, disclosed filtering

Is the settlement layer free of address or geographic filtering, and is any filtering at the edge disclosed and avoidable? C4

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The settlement layer is neutral: consensus has no address or country rules, and shielded parties are not visible. We found no screening in the node, the beta full-node wallet, lightwalletd, or the reference mobile wallet. A light-wallet server operator could refuse to relay a transaction, but the wallet can switch server or the user can run a node. Optional swaps run through NEAR intents operators whose screening we did not inspect. Judgment call: the substance fits 3, but 3 needs a distributed-package or trace record for the client, which we do not have, so we take 2.

Evidence (2)2 verified
  1. Verified

    Shielded actions carry encrypted notes; consensus checks proofs, nullifiers and pool balances, so validators cannot see or filter shielded senders and recipients.

    zcash/zips · zips/zip-0224.rst

    commit 3af03aa3ad · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    GitHub code search on 2026-10-09 for country, geolocation, geoip and restricted in zodl-android, zodl-ios, zebra, zallet and lightwalletd found no country or address screening (zodl-ios hits are a language-based layout tweak in WelcomeView.swift and SplashView.swift).

    zodl-inc/zodl-android · ui-lib/src/main/java/co/electriccoin/zcash/ui/common/provider/LightWalletEndpointProvider.kt

    commit 4248d469c7 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Token and chain freeze risks disclosed

Are the tokens and chains the rail depends on enumerated, with their issuers' freeze powers and sequencer assumptions stated to payees? C5

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The rail carries one asset, ZEC, on one proof-of-work chain, so there is no issuer freeze and no sequencer to inherit. Pool-level changes are the inherited risk: after NU6.3 the Orchard pool is spend-only (ZIP 258 L85-L100), and in June 2026 Orchard was disabled for about a day (see C1). The reference wallet does not state these assumptions to payees. Scored 2: enumerated in code, assumptions not stated.

Evidence (1)1 verified
  1. Verified

    Value moves only in ZEC across the transparent, Sprout, Sapling, Orchard and (since NU6.3) Ironwood pools, with per-pool turnstiles; there is no issued token with a freeze function and no sequencer.

    zcash/zips · zips/zip-0224.rst

    commit 3af03aa3ad · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Open

Is the whole stack visible?

No evidencePillar rating: weakest of 4
2 of 4 Partial or better · 1 no evidence

What would raise this pillar

Contracts verified onchain

Does the deployed bytecode match public source, and can a third party rebuild it? O1

No evidence

Sets the pillar rating

UnreviewedAssessed by AI research agent (seed), 2026-10-09

No checkable evidence settles this yet, so it counts as 0.

Not applicable as worded: Zcash has no contracts, and its rules run in node software that each operator builds or downloads. Zallet documents StageX reproducible builds and Zebra publishes release binaries, but we did not verify any binary against source.

Whole stack published

Are the SDK, frontend, backend or API, indexer, and deploy scripts all public? O2

3 Strong

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Every layer a payment touches has public, maintained source: node, protocol libraries, light-wallet server and indexer, wallets and SDKs, plus deploy files. The only closed parts are optional store-build integrations in the mobile wallet. Judgment call: light-wallet servers are run by third parties and we cannot see which build they run, but the wallet treats them as replaceable, so we score the stack, not the operators, at 3.

Evidence (1)1 verified
  1. Verified

    Node (zebra@e3eef2f3, v6.4.2), protocol libraries (librustzcash@9181ef85, orchard@616a669d), light-wallet server (lightwalletd@d16d4812) and Zaino indexer (zaino@b8db9fed), full-node wallet (zallet@522b486d), mobile wallets (zodl-android@4248d469, zodl-ios@6a7dc6b3) and their SDKs (zodl-android-wallet-sdk@afe08faf) are all public; Zebra ships Docker deploy files.

    ZcashFoundation/zebra · zebrad

    commit e3eef2f37c · checked 2026-10-09

Can be self-hosted

Can a stranger reach a working deployment from the README? O3

1 Weak

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Build and run documentation exists for the node, the light-wallet server and the wallets. Reproduction not attempted, so the score is capped at 1.

Evidence (1)1 verified
  1. Verified

    The Zebra README gives Docker and manual build steps; the lightwalletd README L92-L128 covers production setup; Zodl and Zallet READMEs cover building the wallets.

    ZcashFoundation/zebra · README.md

    commit e3eef2f37c · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Interfaces and data export

Are ABIs, event schemas, an API schema, and a payee data export in a non-proprietary format all in the repo? O4

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Interfaces are versioned in the repos: the transaction format and consensus rules in the ZIPs, the light-wallet gRPC schema, and the node RPC. There are no contract ABIs to publish. We did not find a documented payee export format in the reference wallet. Judgment call: treating the protocol and RPC schemas as covering the ABI and API parts gives 2; no export, so not 3.

Evidence (1)1 verified
  1. Verified

    The light-wallet API is a versioned gRPC schema (CompactTxStreamer); compact_formats.proto defines the block format, and the node's JSON-RPC methods are documented in zebra-rpc/src/methods.rs.

    zcash/lightwalletd · lightwallet-protocol/walletrpc/service.proto

    commit d16d48124e · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Free

Does the license actually let a third party fork, modify, and run it?

0 FailsPillar rating: weakest of 3
2 of 3 Partial or better

What would raise this pillar

Open-source licences

Does every repository needed to run the product carry an OSI-approved license? F1

3 Strong

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Every repository listed carries an OSI-approved licence, including the required node and protocol libraries. The Zodl Android SDK is AGPL-3.0-only, which is OSI-approved but copyleft, and is also sold under commercial terms.

Evidence (1)1 verified
  1. Verified

    orchard, librustzcash, sapling-crypto and halo2 are MIT or Apache-2.0; Zebra is MIT or Apache-2.0; lightwalletd, zips and the archived zcashd are MIT; Zaino and Zallet Apache-2.0; Zodl apps MIT; the Zodl Android SDK AGPL-3.0-only.

    zcash/orchard · COPYING.md

    commit 616a669df8 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Protection against relicensing

Can the provider unilaterally relicense future versions, and has it committed not to? F2

0 Fails

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The required node and protocol libraries have no CLA. There have been two relicensing events: orchard moved from the Bootstrap Open Source License to MIT or Apache-2.0 in 2023, which widened rights, and the Zodl Android SDK moved from MIT to AGPL-3.0-only in August 2026 under a CLA that lets Znewco sell commercial licences. No licence-stability commitment exists. Judgment call: anchor 0 names any prior relicense event; the Zodl change concerns an optional wallet SDK and the orchard change was permissive, but under the take-the-lower-anchor rule we score 0.

Evidence (2)2 verified
  1. Verified

    The Zodl Android SDK requires a signed CLA assigning or broadly licensing contributions to Znewco, Inc. to support dual licensing; its LICENSE changed from MIT to AGPL-3.0-only in commit 9ff67a5e (2026-08-24).

    zodl-inc/zodl-android-wallet-sdk · CONTRIBUTING.md

    commit afe08faff9 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    orchard notes its licence changed from the Bootstrap Open Source License to MIT or Apache-2.0 in release 0.7.0 (commit ac4b5218, 2023-12-19). librustzcash, Zebra and lightwalletd CONTRIBUTING files mention no CLA.

    zcash/orchard · COPYING.md

    commit 616a669df8 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

No proprietary dependencies

Does a production deployment need a proprietary plugin or hosted-only service? F3

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

A production deployment (Zebra node, light-wallet server or Zallet, and a wallet) needs no proprietary component. The mobile wallet's store builds add optional proprietary services, and a FOSS flavour builds without them. Judgment call: the code supports 3, but with no O3 reproduction we take 2.

Evidence (1)1 verified
  1. Verified

    The foss build flavour registers only the local crash reporter; Firebase, Flexa and CoinMarketCap are store-flavour integrations, and the README says the f-droid.org build omits them.

    zodl-inc/zodl-android · crash-android-lib/src/foss/kotlin/co/electriccoin/zcash/crash/android/internal/ListCrashReportersImpl.kt

    commit 4248d469c7 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Privacy

What can an observer learn, and did the user knowingly choose it?

2 PartialPillar rating: weakest of 5
5 of 5 Partial or better

What would raise this pillar

Tracking and analytics

Do the SDK, widget, or frontend ship analytics, telemetry, error reporting, or fingerprinting? P1

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The reference mobile wallet's store build includes Firebase Crashlytics, off by default and enabled only through an opt-in screen; the FOSS build has none. Zebra and Zallet are server software with no analytics SDK found. We ran no trace and did not inspect the iOS app in the same depth. Scored 2: present, off by default, opt-in visible in code.

Evidence (2)2 verified
  1. Verified

    Crash reporters are enabled only when the stored preference is true, and otherwise disabled and their data deleted; the store flavour's preference (is_analytics_enabled) is a nullable boolean set only by the CrashReportOptIn screen, and the foss flavour hardcodes false.

    zodl-inc/zodl-android · app/src/main/java/co/electriccoin/zcash/app/ZcashApplication.kt

    commit 4248d469c7 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-12

  2. Verified

    The Mainnet store release registers Firebase Crashlytics alongside the local reporter.

    zodl-inc/zodl-android · crash-android-lib/src/zcashmainnetStoreRelease/kotlin/co/electriccoin/zcash/crash/android/internal/ListCrashReportersImpl.kt

    commit 4248d469c7 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Data collected beyond payment

Does the flow collect anything beyond addresses, amounts, token, and chain? P2

3 Strong

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

A transfer needs only the signed transaction; a shielded output carries the recipient, amount and an optional memo encrypted to the recipient. No component on the required path holds an account, identity or contact data. The mobile wallet's optional swaps and merchant payments go to third parties with their own data needs. Judgment call: we score the default send flow, which is anchor 3.

Evidence (1)1 verified
  1. Verified

    The light-wallet API carries block ranges, raw transactions, tree states and (for transparent use) addresses; it has no account, identity or contact fields.

    zcash/lightwalletd · lightwallet-protocol/walletrpc/service.proto

    commit d16d48124e · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Payments linkable onchain

What do calldata and events reveal about who paid whom for what? P3

3 Strong

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

A fully shielded payment reveals no payer, payee, amount or memo onchain; the fee, timing, transaction size and the number of actions are visible. Transparent addresses are fully public, as on Bitcoin, and moving between pools reveals the amount. The anonymity set depends on how many users stay shielded and on pool migrations, which we do not score. Judgment call: we score what the protocol reveals for a shielded transfer, which is anchor 3.

Evidence (2)2 verified
  1. Verified

    Within a shielded pool, actions hide sender, recipient and value; moving value across the transparent turnstile reveals the amount, and wallets should warn users about this.

    zcash/zips · zips/zip-0224.rst

    commit 3af03aa3ad · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    Since NU6.3 (height 3,428,143), new shielded value goes to the Ironwood pool and Orchard is spend-only, so Orchard-to-Ironwood migrations cross a turnstile.

    zcash/zips · zips/zip-0258.md

    commit 3af03aa3ad · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Third parties in the payment flow

Which third parties see a request during a payment, and can they be swapped out? P4

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

On the full-node path only the user's own node and its peers see the transaction. On the light-wallet path the chosen lightwalletd server sees the user's IP (unless Tor is on), the transactions they submit and the transactions they fetch; it is named in code and swappable. Optional features add CoinMarketCap (over Tor only), Flexa and NEAR intents. Scored 2: third parties present, named in code, swappable.

Evidence (2)2 verified
  1. Verified

    The light-wallet server operators are named in code and replaceable in the server picker.

    zodl-inc/zodl-android · ui-lib/src/main/java/co/electriccoin/zcash/ui/common/provider/LightWalletEndpointProvider.kt

    commit 4248d469c7 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    Exchange rates come from pro-api.coinmarketcap.com and are fetched only over Tor (comment MOB-1378), so CoinMarketCap does not see the user's IP.

    zodl-inc/zodl-android · ui-lib/src/main/java/co/electriccoin/zcash/ui/common/provider/CMCApiProvider.kt

    commit 4248d469c7 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Endpoints can be changed

Can RPC and indexer URLs be changed, and is the indexer code public? P5

3 Strong

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The wallet's data endpoint (lightwalletd, which is both RPC and indexer for a light client) is configurable in the UI, and both server implementations are public. Full-node users set their own node.

Evidence (1)1 verified
  1. Verified

    The server screen offers automatic selection, the listed servers and a custom server entry (ServerState.Custom); the server code is public as lightwalletd and Zaino.

    zodl-inc/zodl-android · ui-lib/src/main/java/co/electriccoin/zcash/ui/screen/chooseserver/ChooseServerVM.kt

    commit 4248d469c7 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Security

Who can cause loss, lock users in, or change the rules?

No evidencePillar rating: weakest of 6
5 of 6 Partial or better · 1 no evidence

What would raise this pillar

Who holds funds in transit

Who holds funds between payer and payee, and can the provider redirect them? S1

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Value moves directly from notes the payer controls to notes the payee controls, in one transaction; wallets hold keys on the user's device. No one holds funds in flight. Judgment call: this is anchor 3 in substance, but 3 needs onchain evidence about a deployed contract, which this chain has none of, so we take 2.

Evidence (1)1 verified
  1. Verified

    A transaction spends notes the payer controls and creates notes only the recipient's keys can spend; there is no escrow or intermediary account.

    zcash/zips · zips/zip-0224.rst

    commit 3af03aa3ad · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Who can upgrade the code

Who can change the contract code, and with how much notice? S2

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

No key can change the rules. Network upgrades are specified as ZIPs, compiled into node releases with fixed activation heights, and take effect only if miners and node operators run them; scheduled upgrades are announced weeks ahead in the ZIPs and release notes. The emergency soft fork of June 2026 had no advance notice, and the 84-day end-of-support halt pushes operators onto new releases. Judgment call: scheduled upgrades give notice but there is no enforced delay, and emergency changes give none; that resembles anchor 2 more than 3, and 3 would also need onchain evidence this chain cannot supply.

Evidence (2)2 verified
  1. Verified

    Mainnet activation heights are compiled into the node (NU6.2 at 3,364,600, NU6.3 at 3,428,143); a rule change takes effect only for nodes and miners running a release that contains it.

    ZcashFoundation/zebra · zebra-chain/src/parameters/constants.rs

    commit e3eef2f37c · checked 2026-10-09

  2. Verified

    The June 2026 Orchard disabling was deployed as an emergency hotfix and documented retrospectively; ZIP 258 (NU6.3) was published on 2026-06-19 ahead of its 2026-07 activation.

    zcash/zips · zips/zip-0257.md

    commit 3af03aa3ad · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Token approval scope

How large an allowance does the SDK ask users to grant, and for how long? S3

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

There are no token approvals: each payment is a signed transaction spending exact notes, and nothing can pull funds later. Judgment call: this beats exact-amount approvals in substance, but 3 needs a distributed-package or trace record for the client, so we take 2.

Evidence (1)1 verified
  1. Verified

    A wallet submits a fully signed transaction; the protocol has no allowance or delegated-spend mechanism for ZEC, so no wallet asks for one.

    zcash/lightwalletd · lightwallet-protocol/walletrpc/service.proto

    commit d16d48124e · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Funds safe if provider disappears Derived

If the provider disappears tomorrow, do payees keep their funds and the ability to keep settling? S4

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Derived from S1=2 (anchor 3 in substance), C2=2 (direct in substance), C3=3 and O3=1. Funds are notes controlled by the user's keys (S1). Any node or light-wallet server can accept a payment (C2), and no hosted service is required (C3). If the reference wallet's company or the default servers disappeared, users could restore their seed in another open wallet or run Zebra plus Zallet. We did not reproduce a self-hosted setup (O3=1). Judgment call: 2, not 3, for that reason.

Evidence (1)1 verified
  1. Verified

    If default servers disappear, the wallet accepts a custom server; Zallet with a local Zebra node needs no server at all.

    zodl-inc/zodl-android · ui-lib/src/main/java/co/electriccoin/zcash/ui/screen/chooseserver/ChooseServerVM.kt

    commit 4248d469c7 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Secrets and webhook handling

Are secrets kept out of client bundles and are webhooks signed and verified? S5

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Spending keys stay on the user's device; the protocol has no API keys or webhooks. The mobile wallet ships a CoinMarketCap API key in its store build, a minor issue since it grants only price-quote quota. Judgment call: 2 for the shipped key.

Evidence (1)1 verified
  1. Verified

    The store build sends a CoinMarketCap API key from the app in the X-CMC_PRO_API_KEY header; it authorises only price quotes.

    zodl-inc/zodl-android · ui-lib/src/main/java/co/electriccoin/zcash/ui/common/provider/CMCApiProvider.kt

    commit 4248d469c7 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Audits and bug bounty

Has the code been audited at a pinned commit, were findings fixed traceably, and is there a live bounty? S6

No evidence

Sets the pillar rating

UnreviewedAssessed by AI research agent (seed), 2026-10-09

No checkable evidence settles this yet, so it counts as 0.

We found no audit report pinned to a commit in the node, protocol-library or wallet repos, and could not load zodl.com (HTTP 403 to automated requests). Zebra's SECURITY.md (L107) says the Zcash Foundation runs no bug bounty. ZIP 257 records that the critical Orchard bug of May 2026 was found during a commissioned AI-assisted audit, but that is not an audit report. External audit reports exist by reputation only, which we do not score.

Security audits 15

Published audits and similar reviews of this provider's code, newest first. Context for the Audits and bug bounty rating, which scores them; this list does not change any rating, and an audit of older code says little about what is deployed now.

DateAuditorTypeScopeCovers deployed codeFindings
2026-07-14zkSecurityAuditOrchard crate 0.14.0 (Action circuit and verifier-facing code) and halo2 gadgets, proofs and Poseidon at halo2_gadgets-0.5.0, with a Lean formal verification of the Action circuit; commissioned by the Tachyon Foundation after the 2026 Orchard bug.
Zebra v6.4.2 (the assessed node) uses halo2_gadgets 0.5.0, the audited tag, but orchard 0.15.3, newer than the audited 0.14.0.		Partly1 medium, 2 low, 1 informational; none affecting the deployed Orchard protocol, per the report
2025-11-03Least AuthorityAuditZebra changes for the NU6.1 network upgrade (milestone 43). at e422d2f4e5
The commit is the verification revision; six revisions were reviewed initially. Covers the NU6.1 diff only.		PartlyNo issues; 4 suggestions
2024-11-08Least AuthorityAuditZebra changes for the NU6 network upgrade (PRs 8694, 8727, 8729, 8732, 8733, 8742, 8747). at c32c4f6fec
Verification at 46c6b6eb. Covers the NU6 diff only.		PartlyNo issues; 2 suggestions
2024-10-21Least AuthorityAuditzcashd 5.10.0 changes for the NU6 network upgrade. at 3b9272462a
zcashd is now archived; Zebra is the assessed node.		NoNo issues; 2 suggestions
2023-06-27NCC GroupAuditZebra node at the audit-v1.0.0-rc.0 branch, focusing on zebra-chain, zebra-consensus, zebra-network, zebra-state, zebra-rpc, zebra-script and related crates.
Published by NCC Group at this address (linked from its public report page); nccgroup.com returns HTTP 403 to scripted requests, so we did not read the report and give no findings. Zebra 1.0 rc0 is many releases behind the assessed v6.4.2.		Partly
2021-11NCC GroupSecurity reviewNU5 cryptography review - protocol spec and ZIPs 216, 224, 225, 244, 252, plus Pallas/Vesta curves, RedPallas, the Orchard crate (excluding the circuit) and note encryption.
Hosted on fox-it.com, NCC Group's own site; it returns HTTP 403 to scripted requests, so we did not read it and scope comes from NCC's summary page. Orchard code has changed since, including the 2026 soundness fix.		Partly
2021-09QEDITAuditNU5 - Halo 2 proving system, Orchard protocol, primitives and Action circuit, key derivation, Pasta field and curve arithmetic, and NU5 librustzcash changes. at f82d00e40d
The commit is the Orchard one; halo2 was reviewed at 7774dd82 and pasta_curves at b016b972. Orchard and halo2 have changed since, including the 2026 circuit fix.		Partly
2020-09NCC GroupSecurity reviewNU4 (Canopy) - the six core ZIPs and their implementation in zcashd.
Public report page on nccgroup.com, which links the PDF and returns HTTP 403 to scripted requests; not read. The implementation reviewed was zcashd, now archived.		No
2020-04-29Trail of BitsAuditzcashd implementation of ZIP 221 (FlyClient Merkle mountain range) and ZIP 213 (shielded coinbase), at commits 084303d, 659ac40 and 35bff6a.
zcashd code, now archived.		No3 informational (build system, sanitizer and cppcheck errors, lack of fuzzing)
2020-01NCC GroupSecurity reviewNU3 specification and the zcashd Blossom implementation.
Public report page on nccgroup.com (linked from ECC's blog), which returns HTTP 403 to scripted requests; not read.		No
2019-12-04Trail of BitsSecurity reviewSpecification review of ZIP 213 (shielded coinbase) and ZIP 221 (FlyClient), with the Sapling spec as background.
A specification review; both ZIPs remain consensus rules that Zebra implements.		PartlyNo significant security findings; privacy observations on the two ZIPs
2019-01-30NCC GroupSecurity reviewOverwinter consensus code and the Sapling cryptographic primitives.
Published by NCC Group at this address; nccgroup.com returns HTTP 403 to scripted requests, so we did not read it. Sapling primitives remain in use through sapling-crypto; the Overwinter code reviewed was zcashd.		Partly
2019-01-30Least AuthorityAuditSecond Sapling implementation and RPC interface changes in zcashd. at 78c228fc4d
Updated (not final) report; zcashd is now archived.		No5 issues (including DNS rebinding on the RPC server), 1 suggestion
2018-08-17Least AuthoritySecurity reviewZcash protocol specification 2018.0-beta-20 (Overwinter+Sapling).
A specification review; the spec has been revised many times since, but Sapling rules remain in force.		Partly2 issues, 2 suggestions, 6 comments
2018-05-29Least AuthorityAuditzcashd 1.0.15 (Magic Bean) with libsnark, librustzcash, zcash-seeder and zcash-gitian, plus the Overwinter ZIPs 143 and 200-203.
Pre-Sapling zcashd code, long superseded.		No6 issues (A to F)

Compiled from: Audit folders and security docs of the zebra, librustzcash, orchard, halo2, zcash, lightwalletd, zaino, zallet and zodl repos (none hold reports; Zebra's book describes its audit process), Least Authority's published Zcash reports, NCC Group's public Zcash reports (nccgroup.com refuses scripted requests, so those entries are marked blocked_to_bots and were not read), the Trail of Bits publications list, QEDIT's and zkSecurity's report sites, ECC blog posts on audits, and the ZecSec list (third-party wallets, not listed). Not logged: Kudelski's 2019 Sapling report (its blog link now redirects away), Least Authority's 2026 AI-assisted audit (reports sent privately, only a summary published), Zaino's internal design review, and audits of ZSA, FROST, payment URI and hardware-wallet code outside this payment path. No published audit of the Zodl wallet or its SDKs was found. Checked 2026-10-13. Only published reports are listed; private audits a provider mentions without a report are not.

Operational and procurement

Facts an institution's procurement, finance and security functions ask for. Separate from the CROPS ratings and never scored.

Group A: operational facts. Group B: 45 due-diligence controls derived from a UN agency's vendor requirements: 13 evidenced, 0 attested, 1 absent, 30 not applicable, 1 unknown. "Not applicable" means there is no operator to hold the control: it falls to whoever deploys the rail. How to read this.

Group A: operational facts

Fees

Evidenced
ComponentPaid byAmountBasis
networkpayerZIP 317 conventional fee, 5000 zatoshis per logical action, minimum 2 actions (10000 zats = 0.0001 ZEC)Wallet and mempool convention (ZIP 317, Active), not a consensus fee; logical actions count transparent inputs/outputs, Sapling spends/outputs, Orchard and (since NU6.3) Ironwood actions. Paid to the miner. Changes need a ZIP and node releases.

There is no protocol or provider fee. Relayers do not exist; light-wallet servers are free public services. Swap and merchant integrations in third-party wallets are out of scope.

  1. Verified

    conventional_fee = marginal_fee x max(grace_actions, logical_actions) with marginal_fee = 5000 zatoshis and grace_actions = 2 (L130-L146); Revision 1 adds nActionsIronwood to logical_actions from NU6.3 (L178-L196).

    zcash/zips · zips/zip-0317.rst

    commit 3af03aa3ad · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Custody model

Evidenced

Self-custody

Agrees with the S1 finding (anchor 3 in substance, capped at 2 only for want of contract evidence). Value moves from notes the payer controls to notes the payee controls; nobody holds funds in flight.

Evidence shared with CROPS: S1 item 1

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Licences and registrations

N/A: falls to the institution

No operating entity runs the rail. Zcash is a proof-of-work chain run by independent miners and node operators; the Zcash Foundation and ZODL maintain software but do not transmit or hold users' funds.

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Cash-out options

N/A: falls to the institution

Native-asset rail. The payee receives ZEC at its own shielded address; converting ZEC to local currency is outside the protocol.

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

First deployment

Evidenced

2016-10-28: Zcash mainnet genesis (Sprout shielded pool). The assessed Ironwood pool activated with NU6.3 at height 3,428,143 on 2026-07-28 (see changes).

Judgment call. Genesis is recorded as the first deployment of the rail; the Ironwood pool, which carries new shielded transfers today, is under three months old.

  1. Verified

    Mainnet activation heights compiled into Zebra v6.4.2, from Overwinter 347,500 to NU6.3 3,428,143; network_upgrade.rs L104-L120 maps Height(0) to Genesis.

    ZcashFoundation/zebra · zebra-chain/src/parameters/constants.rs

    commit e3eef2f37c · checked 2026-10-09

  2. Verified

    The raw genesis header's nTime field (bytes 100-103, little-endian) decodes to 2016-10-28T07:56:00Z. The NU6.3 activation block 3428143 decodes to 2026-07-28T14:07:23Z the same way. Read through a public explorer API; any Zcash node returns the same header.

    api.blockchair.com/zcash/raw/block/0

    block 0 · checked 2026-10-09

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Operating entity

Evidenced

Zcash Foundation, US

Judgment call. Maintenance is split between the Zcash Foundation (Zebra node) and ZODL (librustzcash, orchard, Zallet, Zodl wallet; Znewco, Inc. per the Zodl SDK CLA). The Foundation is recorded because the assessed unit is defined by Zebra. The IRS exempt-organisation entry was not looked up (no EIN on the site), so no register_url. Electric Coin Company still runs electriccoin.co but no longer appears as maintainer in the sources read.

  1. Verified

    Zebra's security policy names Zcash Open Development Lab (ZODL) as maintainer of zcash/zcash, librustzcash and zallet.

    ZcashFoundation/zebra · SECURITY.md

    commit e3eef2f37c · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

  2. Documented

    The Zcash Foundation maintains Zebra, the only maintained consensus node since zcashd reached end of life, and holds the Zcash trademark.

    zfnd.org

    checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Security incidents

Evidenced
  • 2019-03-27: CVE-2019-7167 published. A flaw in the original Sprout zk-SNARK parameters allowed counterfeiting before the Sapling upgrade (2018-10-28), which removed it. Whether it was exploited cannot be seen in the shielded pool. funds lost: unknown source
  • 2026-06-02: Orchard circuit soundness flaw (reported 2026-05-29) allowed counterfeiting and spending others' notes within Orchard. Orchard disabled by emergency soft fork at height 3363426, fixed in NU6.2 (2026-06-03), sealed withdraw-only by NU6.3. Exploitation cannot be ruled out; the ZIP 209 turnstile protects the supply cap. funds lost: unknown source

Absence of a found incident is not evidence that none occurred.

Only fund-safety incidents are listed. 2026 node advisories in zcashd and Zebra (denial of service, block poisoning, peer bans) are not repeated here. ECC's 2019 post-mortem on electriccoin.co returned HTTP 403 and was not read; the CVE record is cited instead.

  1. Verified

    ZIP 257 records the 2026-05-29 report, the emergency disabling of Orchard from height 3363426 and the failed attempt at 3363366.

    zcash/zips · zips/zip-0257.md

    commit 3af03aa3ad · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

  2. Verified

    zcash/zcash publishes GHSA-ghc3-g8w4-whf9 (critical, 2026-07-19) plus node DoS and consensus-robustness advisories; ZcashFoundation/zebra publishes GHSA-ww9q-8r59-xv46 for the same flaw and further peer-handling advisories in 2026.

    api.github.com/repos/zcash/zcash/security-advisories

    checked 2026-10-09

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Product changes affecting users

Evidenced
  • 2018-10-29: Sapling network upgrade (height 419200), new shielded pool and proving system. source
  • 2022-05-31: NU5 (height 1687104) introduces the Orchard pool and Halo 2 proofs without trusted setup. source
  • 2024-11-23: NU6 (height 2726400) replaces the dev fund with the deferred lockbox (12%) and Zcash Community Grants (8%) streams. source
  • 2025-11-24: NU6.1 (height 3146400) extends the funding streams and disburses the lockbox (ZIP 271). source
  • 2026-06-02: Emergency soft fork disables Orchard actions (height 3363426). source
  • 2026-06-03: NU6.2 (height 3364600) re-enables Orchard with the corrected circuit and limits proof length. source
  • 2026-07-18: zcashd reaches its end-of-support halt at height 3417100; Zebra and Zallet become the only maintained node and full-node wallet. source
  • 2026-07-28: NU6.3 (height 3428143) activates the Ironwood pool and seals Orchard as withdraw-only behind a turnstile. source

Overwinter, Blossom, Heartwood and Canopy are omitted for brevity; their heights are in the same Zebra constants.

  1. Verified

    Mainnet activation heights for every upgrade listed; dates are the timestamps of the activation blocks (read from block headers via api.blockchair.com/zcash/raw/block/<height>).

    ZcashFoundation/zebra · zebra-chain/src/parameters/constants.rs

    commit e3eef2f37c · checked 2026-10-09

  2. Verified

    ZIP 258 fixes the NU6.3 Mainnet activation height at 3428143 (status Draft at this commit although the upgrade has activated).

    zcash/zips · zips/zip-0258.md

    commit 3af03aa3ad · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Volume transacted (verified only)

Not observable

Shielded transfers hide amounts and parties by design; only pool-level flows (value entering or leaving each shielded pool through the turnstile) are visible on the chain. Zcash also has no contract address the volume script could query.

UnreviewedAssessed by AI research agent (operational), 2026-10-09

Group B: institutional due diligence

ControlStateWhat was found
Assurance and certifications
B1.1 ISO 27001, developer organisation
Is the organisation that develops the product ISO 27001 certified, and does the certificate name that entity?		N/A: falls to the institution
implied from the component list
B1.2 ISO 27001, hosting and support organisation
Is the organisation that hosts and supports the service ISO 27001 certified in its own name, with a scope covering the service?		N/A: falls to the institution
implied from the component list
B1.3 SOC 2 Type II or ISAE 3000/3402 reports
Does the provider undergo periodic SOC 2 Type II or ISAE 3402 Type II assessments and make reports available?		N/A: falls to the institution
implied from the component list
B1.4 Independent source-code security review before go-live
Was the application reviewed by an independent party before launch, and is the report linked?		N/A: falls to the institution
implied from the component list
B1.5 Penetration testing
Is the service penetration-tested before go-live and at least every three years, with results available?		N/A: falls to the institution
implied from the component list
B1.6 Vulnerability scanning cadence
Are the platform and the application scanned for vulnerabilities at least every six months?		N/A: falls to the institution
implied from the component list
Vulnerability and patch management
B2.1 Security contact and disclosure policy
Is there a published way to report a vulnerability (SECURITY.md, security.txt, or a disclosure page)?		Evidencedsome of 11 repo(s): ZcashFoundation/zebra ✓ security policy file: SECURITY.md; zcash/librustzcash ✗ no security policy file; zcash/orchard ✗ no security policy file; zcash/zips ✗ no security policy file; zcash/lightwalletd ✗ no security policy file; zingolabs/zaino ✗ no security policy file; zcash/zallet ✗ no security policy file; zodl-inc/zodl-android ✗ no security policy file; zodl-inc/zodl-ios ✗ no security policy file; zodl-inc/zodl-android-wallet-sdk ✗ no security policy file; zcash/zcash (archived) ✓ security policy file: SECURITY.md
source 1 · source 2 · source 3 · source 4 · source 5 · source 6 · source 7 · source 8 · source 9 · source 10 · source 11
B2.2 Patch service levels
Does the provider commit to patch timelines for known vulnerabilities (the partner expects 30 days critical, 40 high, 90 medium)?		N/A: falls to the institution
implied from the component list
B2.3 Dependency and vulnerability scanning in CI
Do the public repositories run dependency or code scanning automatically?		Evidencedsome of 11 repo(s): ZcashFoundation/zebra ✓ dependabot config present; zcash/librustzcash ✓ dependabot config present; zcash/orchard ✗ no scanning config or workflow step found; zcash/zips ✓ dependabot config present; zcash/lightwalletd ✗ no scanning config or workflow step found; zingolabs/zaino ✓ dependabot config present; zcash/zallet ✓ scanning step in a workflow; zodl-inc/zodl-android ✓ dependabot config present; zodl-inc/zodl-ios ✗ no scanning config or workflow step found; zodl-inc/zodl-android-wallet-sdk ✓ dependabot config present; zcash/zcash (archived) ✓ dependabot config present
source 1 · source 2 · source 3 · source 4 · source 5 · source 6 · source 7 · source 8 · source 9 · source 10 · source 11
Incident reporting and continuity
B3.1 Incident reporting commitment
Does the provider commit to notify customers of security or data incidents within a stated time (the partner expects 24 hours)?		N/A: falls to the institution
implied from the component list
B3.2 Backups and restore testing
Are customer records backed up daily and restores tested on a schedule?		N/A: no such service
implied from the component list
B3.3 Recovery plan
Is there an approved and tested recovery plan for the service?		N/A: no such service
implied from the component list
B3.4 Status page and post-mortems
Does the provider publish service status and post-mortems for incidents?		N/A: falls to the institution
implied from the component list
Identity and access (operator side)
B4.1 MFA for end users
Can or must end users protect accounts with multi-factor authentication?		N/A: no such service
implied from the component list
B4.2 MFA and separate accounts for privileged access
Is privileged access protected by MFA and kept on separate accounts?		N/A: falls to the institution
implied from the component list
B4.3 Periodic access reviews
Are user access rights reviewed at least annually and privileged accounts at least six-monthly?		N/A: falls to the institution
implied from the component list
B4.4 Segregation of duties and joiner-mover-leaver controls
Is there a documented segregation-of-duties model and a joiner-mover-leaver process?		N/A: falls to the institution
implied from the component list
B4.5 Session timeout
Are idle interactive sessions terminated after a defined period (the partner expects 60 minutes)?		N/A: no such service
implied from the component list
API and integration
B5.1 API authentication, browser to server
Which standard (OAuth 2.0, OpenID Connect, SAML, JWT) protects browser-to-server API calls?		N/A: falls to the institution
implied from the component list
B5.2 API authentication, server to server
Are server-to-server calls authenticated with keys or PKI certificates, and are keys scoped and rotatable?		N/A: falls to the institution
implied from the component list
B5.3 Token expiry
Do API tokens expire, and within what period (the partner caps it at 120 minutes for public data, 30 otherwise)?		N/A: falls to the institution
implied from the component list
B5.4 Export controls
If an API exports data, does it limit volumes and log exports?		N/A: falls to the institution
implied from the component list
Data protection and privacy governance
B6.1 Data classification and encryption
Does the provider state a data classification and enforce encryption at rest and TLS 1.2 or better in transit?		N/A: falls to the institution
implied from the component list
B6.2 Production data kept out of test environments
Does the provider state that production or real personal data is not used in development and testing?		N/A: falls to the institution
implied from the component list
B6.3 Data retention and deletion on termination
What is retained, for how long, and is customer data removed on termination?		N/A: falls to the institution
implied from the component list
B6.4 Data protection impact assessment and roles
For systems holding personal data, has a DPIA been completed and are controller and processor defined?		N/A: falls to the institution
implied from the component list
B6.5 Data processing or sharing agreement available
Can a customer obtain a data processing agreement or equivalent?		N/A: falls to the institution
implied from the component list
Logging and monitoring
B7.1 Audit logging
Are account changes, logins and activity on important records logged and retained?		N/A: falls to the institution
implied from the component list
B7.2 Central monitoring and endpoint detection
Are logs sent to a managed SIEM and is endpoint detection running on all platforms?		N/A: falls to the institution
implied from the component list
Hosting and network
B8.1 Hardened hosting
Are hosts hardened to a recognised benchmark, with only essential ports open, IDS/IPS, a WAF for internet-facing applications and tenant isolation?		N/A: falls to the institution
implied from the component list
B8.2 Deployment configuration and infrastructure as code
Does the repository ship reproducible deployment configuration (containers, IaC, Helm) that a self-hoster can harden?		Evidencedsome of 11 repo(s): ZcashFoundation/zebra ✗ no deployment configuration; zcash/librustzcash ✗ no deployment configuration; zcash/orchard ✗ no deployment configuration; zcash/zips ✓ deployment configuration: Dockerfile; zcash/lightwalletd ✓ deployment configuration: Dockerfile; zingolabs/zaino ✓ deployment configuration: Dockerfile; zcash/zallet ✓ deployment configuration: Dockerfile; zodl-inc/zodl-android ✗ no deployment configuration; zodl-inc/zodl-ios ✗ no deployment configuration; zodl-inc/zodl-android-wallet-sdk ✗ no deployment configuration; zcash/zcash (archived) ✗ no deployment configuration
source 1 · source 2 · source 3 · source 4 · source 5 · source 6 · source 7 · source 8 · source 9 · source 10 · source 11
Engineering practice in public repositories
B9.1 Default branch protected
Does the default branch require reviews and passing checks, with no direct pushes?		Evidencedall of 11 repo(s): ZcashFoundation/zebra ✓ rules: pull_request, required_status_checks, merge_queue, deletion, non_fast_forward; zcash/librustzcash ✓ rules: deletion, non_fast_forward, pull_request, pull_request, required_status_checks; zcash/orchard ✓ rules: deletion, non_fast_forward, pull_request, pull_request, required_status_checks; zcash/zips ✓ rules: deletion, non_fast_forward, pull_request, deletion, pull_request, required_status_checks; zcash/lightwalletd ✓ rules: deletion, non_fast_forward, pull_request, pull_request, required_status_checks; zingolabs/zaino ✓ rules: deletion, non_fast_forward, pull_request, non_fast_forward; zcash/zallet ✓ rules: deletion, non_fast_forward, pull_request, pull_request, required_status_checks; zodl-inc/zodl-android ✓ rules: deletion, non_fast_forward, pull_request, pull_request; zodl-inc/zodl-ios ✓ rules: pull_request, required_status_checks, deletion, pull_request, non_fast_forward; zodl-inc/zodl-android-wallet-sdk ✓ rules: deletion, non_fast_forward, pull_request, pull_request, required_status_checks; zcash/zcash (archived) ✓ rules: deletion, non_fast_forward, pull_request, pull_request, required_status_checks
source 1 · source 2 · source 3 · source 4 · source 5 · source 6 · source 7 · source 8 · source 9 · source 10 · source 11
B9.2 CI runs on pull requests
Does every pull request trigger automated checks?		Evidencedall of 11 repo(s): ZcashFoundation/zebra ✓ 29 workflow file(s); zcash/librustzcash ✓ 6 workflow file(s); zcash/orchard ✓ 6 workflow file(s); zcash/zips ✓ 4 workflow file(s); zcash/lightwalletd ✓ 1 workflow file(s); zingolabs/zaino ✓ 13 workflow file(s); zcash/zallet ✓ 12 workflow file(s); zodl-inc/zodl-android ✓ 9 workflow file(s); zodl-inc/zodl-ios ✓ 4 workflow file(s); zodl-inc/zodl-android-wallet-sdk ✓ 6 workflow file(s); zcash/zcash (archived) ✓ 8 workflow file(s)
source 1 · source 2 · source 3 · source 4 · source 5 · source 6 · source 7 · source 8 · source 9 · source 10 · source 11
B9.3 Tests run in CI
Do the CI workflows run the test suite?		Evidencedsome of 11 repo(s): ZcashFoundation/zebra ✗ test command in a workflow; zcash/librustzcash ✓ test command in a workflow; zcash/orchard ✓ test command in a workflow; zcash/zips ✓ test command in a workflow; zcash/lightwalletd ✓ test command in a workflow; zingolabs/zaino ✗ test command in a workflow; zcash/zallet ✓ test command in a workflow; zodl-inc/zodl-android ✗ test command in a workflow; zodl-inc/zodl-ios ✗ test command in a workflow; zodl-inc/zodl-android-wallet-sdk ✓ test command in a workflow; zcash/zcash (archived) ✓ test command in a workflow
source 1 · source 2 · source 3 · source 4 · source 5 · source 6 · source 7 · source 8 · source 9 · source 10 · source 11
B9.4 Coverage reported
Is test coverage measured and reported (the partner expects 85%)?		Evidencedsome of 11 repo(s): ZcashFoundation/zebra ✓ coverage tooling referenced; zcash/librustzcash ✓ coverage tooling referenced; zcash/orchard ✗ coverage tooling referenced; zcash/zips ✗ coverage tooling referenced; zcash/lightwalletd ✓ coverage tooling referenced; zingolabs/zaino ✓ coverage tooling referenced; zcash/zallet ✓ coverage tooling referenced; zodl-inc/zodl-android ✓ coverage tooling referenced; zodl-inc/zodl-ios ✗ coverage tooling referenced; zodl-inc/zodl-android-wallet-sdk ✓ coverage tooling referenced; zcash/zcash (archived) ✗ coverage tooling referenced
source 1 · source 2 · source 3 · source 4 · source 5 · source 6 · source 7 · source 8 · source 9 · source 10 · source 11
B9.5 Versioned releases
Are releases tagged with immutable semantic versions?		Evidencedsome of 11 repo(s): ZcashFoundation/zebra ✗ latest tags: zebra-utils-v10.0.3, zebra-utils-v10.0.2, zebra-utils-v10.0.1; zcash/librustzcash ✗ latest tags: zip321-0.10.0-pre.2, zip321-0.10.0-pre.1, zip321-0.10.0-pre.0; zcash/orchard ✓ latest tags: v0.11.0, v0.1.0-beta.3, v0.1.0-beta.2; zcash/zips ✓ latest tags: vtest, v2026.7.0, v2026.6.4; zcash/lightwalletd ✓ latest tags: v0.5.5, v0.5.4, v0.5.3; zingolabs/zaino ✓ latest tags: zainod-0.10.2, zainod-0.10.1, v0.4.0_nu_6_2_alpha; zcash/zallet ✓ latest tags: v0.1.0-beta.3, v0.1.0-beta.2, v0.1.0-beta.1; zodl-inc/zodl-android ✓ latest tags: shielded-vote-2.4.10-testflight.5, shielded-vote-2.4.10-testflight.4, shielded-vote-2.4.10-testflight.3; zodl-inc/zodl-ios ✓ latest tags: test-0.0.1-42, release-baseline-2026-08-08, beta4-rc2; zodl-inc/zodl-android-wallet-sdk ✓ latest tags: v5.2.1, v5.2.0, v5.1.0; zcash/zcash (archived) ✓ latest tags: zc.v0.11.2.z0, v6.20.0, v6.12.5
source 1 · source 2 · source 3 · source 4 · source 5 · source 6 · source 7 · source 8 · source 9 · source 10 · source 11
B9.6 Signed tags or commits
Are release tags or recent commits cryptographically signed?		Evidencedsome of 11 repo(s): ZcashFoundation/zebra ✓ 9 of 10 recent commits signed; zcash/librustzcash ✗ 3 of 10 recent commits signed; zcash/orchard ✗ 4 of 10 recent commits signed; zcash/zips ✗ 2 of 10 recent commits signed; zcash/lightwalletd ✓ 6 of 10 recent commits signed; zingolabs/zaino ✓ 8 of 10 recent commits signed; zcash/zallet ✗ 4 of 10 recent commits signed; zodl-inc/zodl-android ✓ 6 of 10 recent commits signed; zodl-inc/zodl-ios ✓ 10 of 10 recent commits signed; zodl-inc/zodl-android-wallet-sdk ✓ 5 of 10 recent commits signed; zcash/zcash (archived) ✓ 9 of 10 recent commits signed
source 1 · source 2 · source 3 · source 4 · source 5 · source 6 · source 7 · source 8 · source 9 · source 10 · source 11
B9.7 Changelog
Is a changelog maintained with the code?		Evidencedsome of 11 repo(s): ZcashFoundation/zebra ✓ CHANGELOG file; zcash/librustzcash ✓ 6 release(s) with notes; zcash/orchard ✓ CHANGELOG file; zcash/zips ✗ no changelog or release notes; zcash/lightwalletd ✓ CHANGELOG file; zingolabs/zaino ✓ CHANGELOG file; zcash/zallet ✓ CHANGELOG file; zodl-inc/zodl-android ✓ CHANGELOG file; zodl-inc/zodl-ios ✓ CHANGELOG file; zodl-inc/zodl-android-wallet-sdk ✓ CHANGELOG file; zcash/zcash (archived) ✓ 10 release(s) with notes
source 1 · source 2 · source 3 · source 4 · source 5 · source 6 · source 7 · source 8 · source 9 · source 10 · source 11
B9.8 Contribution and branching model documented
Does the README or contribution guide state how changes are proposed, reviewed and released?		Evidencedsome of 11 repo(s): ZcashFoundation/zebra ✓ CONTRIBUTING file; zcash/librustzcash ✓ CONTRIBUTING file; zcash/orchard ✓ contribution section in README; zcash/zips ✗ none found; zcash/lightwalletd ✓ CONTRIBUTING file; zingolabs/zaino ✓ CONTRIBUTING file; zcash/zallet ✓ CONTRIBUTING file; zodl-inc/zodl-android ✓ CONTRIBUTING file; zodl-inc/zodl-ios ✓ CONTRIBUTING file; zodl-inc/zodl-android-wallet-sdk ✓ CONTRIBUTING file; zcash/zcash (archived) ✓ CONTRIBUTING file
source 1 · source 2 · source 3 · source 4 · source 5 · source 6 · source 7 · source 8 · source 9 · source 10 · source 11
Architecture documentation
B10.1 Architecture documentation
Is there a public architecture document covering logical, infrastructure and integration architecture and the components used?		EvidencedLogical and integration architecture of the node (crate structure, services, dependencies) in the Zebra book; the protocol is specified in the Zcash Protocol Specification and ZIPs. No infrastructure view, as no operator-run infrastructure is required.
source 1
Commercial and financial
B11.1 Contracting entity
Which legal entity would an institution contract with, and in which jurisdiction?		N/A: falls to the institution
implied from the component list
B11.2 Funding of ongoing operation
How is ongoing operation and maintenance funded (revenue, foundation, grants, fee switch), per a primary source?		EvidencedProtocol funding streams in consensus. From NU6.1 until height 4,406,400, 12% of each block subsidy goes to the deferred lockbox and 8% to the Major Grants stream administered by the Financial Privacy Fund. The Zcash Foundation also publishes quarterly financial reports.
source 1
B11.3 Termination terms
What happens to customer funds and data on termination by either side?		N/A: falls to the institution
implied from the component list
AI components
B12.1 AI in the payment path
Does an AI system take part in payment processing or compliance decisions (for example automated transaction screening)?		Absent
source 1
B12.2 AI controls documented
If AI is used, are monitoring, validation, override, decommissioning and bias evaluation documented?		Unknown
implied from the component list

Scope of assessment

Components in the payment path

ComponentRolePublicLicenceOperatorRequired
Zcash mainnet consensus (proof-of-work miners and full nodes)ledgerYesApache-2.0miners and node operators; rule changes ship as node releases (ZIP process)Yes
Zebra full node (zebrad), the maintained consensus nodebackendYesApache-2.0Zcash Foundation (code); run by users, server operators and minersYes
Protocol libraries in every listed wallet (librustzcash, orchard, halo2)sdkYesMITuser (runs inside the wallet)Yes
Zodl mobile wallet (Android and iOS; reference light wallet)walletYesMITZnewco, Inc. (d/b/a Zodl)No
Zodl Android and iOS wallet SDKs (AGPL-3.0-only, CLA, dual-licensed)sdkYesAGPL-3.0-onlyZnewco, Inc.No
Zallet full-node wallet (beta)walletYesApache-2.0userNo
lightwalletd servers (Zodl defaults zec.rocks, zec.stardust.rest, or custom)apiYesMITindependent server operatorsNo
Zaino indexer (lightwalletd-compatible)indexerYesApache-2.0server operatorsNo
zcashd (archived predecessor node and wallet)backendYesMITnone (archived 2026)No
Zodl store-build integrations (Crashlytics, CoinMarketCap, Flexa, NEAR swaps)otherNoproprietaryGoogle, CoinMarketCap, Flexa, NEAR intents operatorsNo

Repositories

RepositoryRoleLicense
ZcashFoundation/zebrabackendApache-2.0
zcash/librustzcashsdkMIT
zcash/orchardsdkMIT
zcash/zipsdocsMIT
zcash/lightwalletdindexerMIT
zingolabs/zainoindexerApache-2.0
zcash/zalletfrontendApache-2.0
zodl-inc/zodl-androidfrontendMIT
zodl-inc/zodl-iosfrontendMIT
zodl-inc/zodl-android-wallet-sdksdkAGPL-3.0-only
zcash/zcashbackendMIT

Contracts

None listed.

Assessor notes

Unit: Zcash mainnet shielded transfers. Pins: zebra@e3eef2f3 (v6.4.2), zips@3af03aa3, lightwalletd@d16d4812, orchard@616a669d, librustzcash@9181ef85, zallet@522b486d (v0.1.0-beta.3 line), zodl-android@4248d469, zodl-ios@6a7dc6b3, zodl-android-wallet-sdk@afe08faf, zcashd@558f6865 (archived). The chain has no contracts, so cells whose top anchor needs onchain contract evidence (C1, C2, S1, S2) are capped at 2 with the reason in each finding, and O1 is unknown. Events of 2026 recorded from primary sources: Orchard disabled by emergency soft fork (ZIP 257), NU6.2 fix, NU6.3 Ironwood pool (ZIP 258), zcashd archived, Zashi renamed Zodl under Znewco, Inc. No transactions, node runs, builds, traces or self-host attempts were made.