ZCash
z.cashUses zero-knowledge proofs to protect privacy cryptographic technique, that allows two users to transact without ever revealing their true identity or address. The Zcash blockchain uses two types of addresses and transactions, Z transactions and addresses are private and T transactions and addresses are transparent like Bitcoin.
- Homepage: z.cash
- GitHub: github.com/zcash/zcash
- Privacy: z.cash/privacy-policy
- Web info: web-check.xyz/check/z.cash
ZCash Source Code
Author
Description
Zcash - Internet Money
Homepage
https://z.cash/License
NOASSERTION
Created
22 Nov 14
Last Updated
07 Jun 26
Latest version
Primary Language
C++
Size
116,886 KB
Stars
5,452
Forks
2,212
Watchers
5,452
Language Usage
Star History
Top Contributors
-
@laanwj (2899)
-
@str4d (2688)
-
@nuttycom (1276)
-
@gavinandresen (1100)
-
@sipa (1087)
-
@zkbot (1053)
-
@daira (696)
-
@ebfull (511)
-
@bitcartel (487)
-
@theuni (368)
-
@non-github-bitcoin (271)
-
@sellout (231)
-
@luke-jr (212)
-
@jonasschnelli (200)
-
@gmaxwell (185)
-
@TheBlueMatt (157)
-
@fanquake (147)
-
@defuse (143)
-
@oxarbitrage (122)
-
@softminus (103)
-
@therealyingtong (97)
-
@LarryRuane (91)
-
@jtimon (81)
-
@petertodd (73)
-
@cozz (70)
-
@charlieok (51)
-
@sdaftuar (50)
-
@morcos (49)
-
@paveljanik (46)
-
@practicalswift (44)
-
@rex4539 (43)
-
@ageis (35)
-
@muggenhor (34)
-
@CodeShark (32)
-
@sandakersmann (31)
-
@dongcarl (30)
-
@mdr0id (29)
-
@rebroad (29)
-
@jnewbery (29)
-
@nejucomo (23)
-
@domob1812 (21)
-
@dooglus (20)
-
@leto (19)
-
@furszy (18)
-
@sdkfjlsfjlskdfjlsdjflsjf (16)
-
@dependabot[bot] (16)
-
@syd0 (16)
-
@super3 (16)
-
@kdomanski (15)
-
@per-gron (14)
-
@kazcw (14)
-
@y4ssi (13)
-
@dexX7 (13)
-
@arielgabizon (13)
-
@dgenr8 (13)
-
@ENikS (13)
-
@teor2345 (12)
-
@wtogami (12)
-
@JeremyRubin (12)
-
@casey (11)
-
@ryanofsky (11)
-
@codler (10)
-
@wizeman (10)
-
@zancas (10)
-
@promag (9)
-
@roques (9)
-
@benzcash (8)
-
@ken2812221 (8)
-
@hebasto (8)
-
@jamesob (8)
-
@jmcorgan (8)
-
@jordanlewis (8)
-
@joshtriplett (8)
-
@kozyilmaz (8)
-
@mrbandrews (8)
-
@ajweiss (8)
-
@sje397 (7)
-
@runeksvendsen (7)
-
@celil-kj (7)
-
@philmb3487 (7)
-
@freewil (7)
-
@centromere (7)
-
@forrestv (7)
-
@maaku (7)
-
@kallewoof (7)
-
@JoelKatz (6)
-
@meshcollider (6)
-
@jrmithdobbs (6)
-
@p2k (6)
-
@zw (6)
-
@vegard (6)
-
@r3ld3v (6)
-
@recursive-rat4 (6)
-
@OttoAllmendinger (6)
-
@mgiuca (6)
-
@Matoking (6)
-
@dertin (6)
-
@radix42 (6)
-
@Empact (6)
-
@schildbach (6)
Recent Commits
-
Kris Nuttycombe (04 Jun 26)
Merge pull request #7172 from zcash/dependabot/github_actions/docker/login-action-4.2.0 build(deps): bump docker/login-action from 4.1.0 to 4.2.0
-
Kris Nuttycombe (04 Jun 26)
Merge pull request #7178 from zcash/dependabot/github_actions/actions/checkout-6.0.3 build(deps): bump actions/checkout from 6.0.2 to 6.0.3
-
John (04 Jun 26)
Merge pull request #7184 from daira/7182-gtest-orchard-assert-no-fatal-failure qa: Guard BuildOrchardSpend test-helper calls with ASSERT_NO_FATAL_FAILURE
-
Daira-Emma Hopwood (04 Jun 26)
qa: Guard BuildOrchardSpend test-helper calls with ASSERT_NO_FATAL_FAILURE The BuildOrchardSpend and MakeOrchardProofNonCanonicalBytes helpers in test_orchard_wallet.cpp use ASSERT_* macros internally. A googletest ASSERT_* in a void subroutine expands to `return;`, which returns only from the helper, not from the calling TEST: a failed assumption is registered but the test keeps running. BuildOrchardSpend's call sites invoked it unguarded, so a violated assumption would leave the caller's CTransaction default-constructed and let the test continue against an empty/invalid transaction (a confusing failure cascade or undefined behaviour, rather than a clean abort at the real cause). Wrap all five BuildOrchardSpend calls in ASSERT_NO_FATAL_FAILURE(...), matching the existing MakeOrchardProofNonCanonicalBytes call sites. Also correct the comment on MakeOrchardProofNonCanonicalBytes, which claimed the out-parameter plus `return;` pattern aborts the test (it does not; the abort comes from the caller's ASSERT_NO_FATAL_FAILURE), and document the same call-site requirement on BuildOrchardSpend. Closes #7182. Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
-
Kris Nuttycombe (03 Jun 26)
Merge pull request #7177 from zcash/deb_control Update maintainer of .deb packages
-
dependabot[bot] (03 Jun 26)
build(deps): bump actions/checkout from 6.0.2 to 6.0.3 Bumps [actions/checkout](https://github.com/actions/checkout) from 6.0.2 to 6.0.3. - [Release notes](https://github.com/actions/checkout/releases) - [Commits](https://github.com/actions/checkout/compare/v6.0.2...v6.0.3) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: 6.0.3 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]>
-
y4ssi (03 Jun 26)
Update maintainer of .deb packages
-
Kris Nuttycombe (03 Jun 26)
Merge pull request #7174 from zcash/release-v6.20.0 Zcashd release v6.20.0
-
Kris Nuttycombe (03 Jun 26)
Merge pull request #7176 from zcash/release-v6.20.0-gitian build: fix gitian build against clang 22 + glibc 2.34
-
y4ssi (03 Jun 26)
build: fix gitian build against clang 22 + glibc 2.34 Three independent issues prevent reproducible gitian builds against the LLVM 22.1.2 toolchain pinned in depends/native_clang on bookworm hosts. 1. depends/packages/bdb.mk BDB 6.2.23's src/os/os_yield.c calls pthread_yield(), which glibc 2.34+ removed as an unversioned symbol. Final link fails with undefined symbol: pthread_yield. Fix: add depends/patches/bdb/pthread_yield_fix.patch to remove the HAVE_PTHREAD_YIELD branch so the existing HAVE_SCHED_YIELD branch handles this case. 2. contrib/gitian-descriptors/gitian-linux{,-parallel}.yml src/Makefile.am has -Werror -Wmissing-include-dirs and BITCOIN_INCLUDES=-I$(builddir)/obj. obj/ holds the genbuild.sh- generated build.h, but with parallel make the libbitcoin_server compilations start before genbuild creates the directory; clang 22 then errors on the missing -I./obj. Pre-create src/obj/ between ./configure and make in the distsrc loop to make this race deterministic. 3. configure.ac clang 22 promoted -Wunique-object-duplication to default-on. With -fvisibility=hidden + -Werror, this fires fatally on Meyer-singleton statics in src/util/time.h, src/support/lockedpool.h, src/addrman.h, src/chain.h, src/mempool_limit.h. Since zcashd ships as a static binary the duplication risk is moot here. Add the warning to DISABLED_WARNING_CXXFLAGS rather than carving out individual declarations. bdb: ship pthread_yield fix as a static patch file Per review feedback (kris): use the same patch -p1 mechanism as the other two BDB patches instead of an inline sed in preprocess_cmds. Rather than substituting sched_yield() into the HAVE_PTHREAD_YIELD branch, the patch removes that branch entirely so the existing HAVE_SCHED_YIELD branch handles the case. BDB's configure probes pthread_yield and sched_yield independently (dist/configure.ac AC_CHECK_FUNCS), so HAVE_PTHREAD_YIELD does not imply HAVE_SCHED_YIELD and the substitution would be safe only by platform coincidence. sched_yield() is the standard POSIX call and is present on every platform that has the nonstandard pthread_yield(), so dropping the branch is correct by construction. Co-authored-by: Kris Nuttycombe <[email protected]> Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
-
Kris Nuttycombe (03 Jun 26)
Upgrade to `orchard 0.14` and `zcash_primitives 0.28`
-
Jack Grigg (02 Jun 26)
Set the NU6.2 mainnet consensus rules and activation height
-
Jack Grigg (02 Jun 26)
Set Debian to critical
-
Jack Grigg (02 Jun 26)
make-release.py: Updated book for 6.20.0.
-
Jack Grigg (02 Jun 26)
make-release.py: Updated release notes and changelog for 6.20.0.
-
Jack Grigg (02 Jun 26)
make-release.py: Updated manpages for 6.20.0.
-
Jack Grigg (02 Jun 26)
make-release.py: Versioning changes for 6.20.0.
-
Jack Grigg (02 Jun 26)
Add release notes Co-authored-by: Kris Nuttycombe <[email protected]>
-
Jack Grigg (02 Jun 26)
qa: Postpone remaining dependency updates
-
Jack Grigg (02 Jun 26)
qa: Fix orchard_action_identity_point RPC test
-
Jack Grigg (02 Jun 26)
Bump protocol version We've set testnet and mainnet to the same version since we're setting their activation heights at the same time. However, regtest is set to the same as testnet, and without bumping this, no RPC test can activate NU 6.2 without disconnecting its peers and breaking the test.
-
Jack Grigg (02 Jun 26)
qa: Update soft-fork test to ensure NU 6.2 re-enables Orchard
-
Jack Grigg (02 Jun 26)
Restore AcceptBlockHeader ban level outside of soft fork
-
Jack Grigg (02 Jun 26)
gtest: Fix Orchard unit tests for epk validation The change to validate epk when parsing Orchard bundles exposed several bugs in the gtests: - ChecktransactionTests.NU5AcceptsOrchardShieldedCoinbase mutates an Orchard transaction to invalidate different parts of it. At the time it was written, epk was in a different location within the transaction, but that eventually changed and the test was not updated. This went unnoticed because the failure modes were identical, but after epk validation was moved to parsing, the failures became distinguishable. Fixed by correcting the v5 tx offsets and adding intentional epk malleation tests. - orchardMerkleTree.appendBundle tests appending note commitments to the Orchard tree. However, because Orchard was implemented entirely in Rust, and at the time crossing the FFI was Not Fun™, we instead used the already-available Bundle type (which was a pointer to Rust memory) to pass its commitments to the tree. That meant the C++ test vectors needed to load note commitments in via bundles, and this was done with structurally-valid but semantically-invalid bundle encodings. The ciphertext-related bytes were all zeroed out, which included epk; that happens to encode the identity, which is now invalid. Fixed by altering each action's epk to use the encoding of `1` which is a valid curve point. (Also the test was only testing one of the fixtures; we now test them all.)
-
Daira-Emma Hopwood (02 Jun 26)
Prove Orchard transactions against the correct circuit version NU6.2 fixed the Orchard variable-base scalar-multiplication circuit, changing the verifying key. Decide which circuit to prove against with `CChainParams::UseFixedCircuitForProving`. On Mainnet, the fixed circuit is always used. On Testnet or Regtest, the fixed circuit is used when NU6.2 is active. The prover must match, so that a transaction's proof verifies under the verifying key for its era. This policy ensures that Mainnet nodes will still use fixed proofs even when not fully synced, or eclipsed; it is safe because the emergency soft fork to turn off Orchard after NU6.1 has already activated. Thread this decision through the Orchard proving FFI so that the circuit version is chosen in exactly one place. `orchard_builder_new` takes the choice and stamps the version onto each action via `Builder::new_for_version`. The proving key therefore cannot disagree with the circuit the actions were built against. The `TransactionBuilder` (wallet) and miner (for coinbase) pass `UseFixedCircuitForProving(nHeight)` when constructing the builder. The insecure proving key is built lazily, so it is never constructed on Mainnet. Co-Authored-By: Claude Opus 4.8 <[email protected]>
-
Daira-Emma Hopwood (02 Jun 26)
qa: Add an RPC test for Orchard across NU6.2 With NU6.2 active, shield into the Orchard pool and then spend Orchard -> Orchard, and mine both transactions. The Orchard proofs are produced against the NU6.2 fixed circuit, and connecting the blocks batch-validates them against the fixed verifying key, so acceptance demonstrates that the fixed key is selected from NU6.2 onward. Add NU6_2_BRANCH_ID so the test can activate NU6.2 via -nuparams. Co-Authored-By: Claude Opus 4.8 <[email protected]>
-
Daira-Emma Hopwood (02 Jun 26)
Verify Orchard proofs against the correct circuit across NU6.2 The Orchard circuit changed in NU6.2 (the variable-base scalar-multiplication fix), which changes the verifying key. Build both the pre-NU6.2 (insecure) and NU6.2-onward (fixed) verifying keys, since a node that validates both historical and new blocks needs both, and select between them in Orchard batch validation by whether NU6.2 is active at the block height: a batch never mixes epochs (one batch per block, and a fresh batch per transaction during mempool acceptance), so a single verifying key per batch is correct. In ContextualCheckTransaction the temporary Orchard-disabling soft-fork rule is restricted to the pre-NU6.2 case, since NU6.2 re-enables Orchard. Add a test that a canonical-proof Orchard transaction is accepted under NU6.2. Co-Authored-By: Claude Opus 4.8 <[email protected]>
-
Daira-Emma Hopwood (02 Jun 26)
Test that the canonical Orchard proof size is enforced from NU6.2 From NU6.2, an Orchard proof must have the canonical length for its number of actions. This is enforced when a transaction is parsed, via librustzcash's Transaction::read keyed on the transaction's own (v5+) consensus branch id, so a non-canonical proof fails to deserialize from NU6.2 onward. The standalone Orchard bundle parse stays lenient (ProofSizeEnforcement::Unenforced) so that historical transactions remain deserializable. Document that this parse, which runs for every transaction via CTransaction::UpdateHash, is consensus-critical (in Zcash a structural or encoding violation is a consensus violation), including the subtlety that the placeholder branch id is only used for v1-v4 transactions while Orchard exists only in v5+, where the transaction's own branch id is used. Add tests that a NU6.2 transaction with a non-canonical (padded) proof fails to deserialize under the NU6.2 branch id, and that the same bytes deserialize under an earlier branch id (so a node can still sync and reindex historical chain data). Co-Authored-By: Claude Opus 4.8 <[email protected]>
-
Daira-Emma Hopwood (02 Jun 26)
Add NU6.2 to the upgrade list Add the UPGRADE_NU6_2 upgrade index and its NetworkUpgradeInfo entry (branch id 0x5437f330), thread its activation height through the consensus parameters and the Rust network bridge, and add RegtestActivateNU6point2 / RegtestDeactivateNU6point2 test helpers. RegtestActivateNU6point2 disables the temporary Orchard-disabling soft fork, since NU6.2 re-enables Orchard. Activation heights are left unset (NO_ACTIVATION_HEIGHT) on mainnet and testnet; the provisional mainnet height is recorded in a comment. Testnet is intended to activate after mainnet, so the protocol versions indicating NU6.2 support are 170150 (mainnet) and 170160 (testnet/regtest). Co-Authored-By: Claude Opus 4.8 <[email protected]>
-
Daira-Emma Hopwood (02 Jun 26)
Temporary git-revision patches for the security-fix crates, and orchard 0.14 API adaptations DO NOT MERGE the patch directives: patch orchard, the halo2 crates, and the librustzcash crates to their unreleased security-fix revisions, so the NU6.2 changes can be built and tested before those crates' releases are published. Drop these patches once the crates are released. Adapt to the orchard 0.14 API so this builds: `read_v5_bundle` now takes a `ProofSizeEnforcement`, so deserialize Orchard bundles leniently (`ProofSizeEnforcement::Unenforced`); the consensus logic that enforces proof size is added in a later commit. Name the Orchard verifying key `ORCHARD_VK_INSECURE`, built for the original (insecure) circuit; the post-NU6.2 (fixed) verifying key and the logic selecting between the two are added in a later commit. Co-Authored-By: Claude Opus 4.8 <[email protected]>
ZCash Security
Security Advisories (3)
- critical Unpatched
GHSA-fqr9-fxpx-rfpf zcashd ConnectBlock use-after-free: stack destruction order frees PrecomputedTransactionData while CCheckQueueControl Wait() still has worker threads dereferencing it (parity with Bitcoin Core CVE-2024-52911 disclosed 2026-05-05)
- medium Patched
GHSA-rpcw-q5mr-gq35 Auth Data Body Poisoning in NU5+ Block Ingestion
- medium Patched
GHSA-3jg6-49c6-q99v zcashd Normalizes Malformed V4 Sapling valueBalance Encodings That Zebra Rejects
ZCash Website
Website
Zcash: Privacy-protecting digital currency
The first cryptocurrency to develop zero-knowledge encryption for private peer-to-peer payments. Use Zcash Learn Zcash Current price (USD) $ 0 Outstanding…
Redirects
Does not redirect
Security Checks
2 security checks failed (63 passed)
- Top-Level Domain Highly Abused
- Domain is Blacklisted
Server Details
- IP Address 172.66.151.13
- Location San Francisco, California, United States of America, NA
- ISP CloudFlare Inc.
- ASN AS13335
Associated Countries
-
US -
FR
Safety Score
Website marked as very dangerous
0%
Blacklist Check
z.cash was found on 1 blacklists
- CoinBlockerLists
- AntiSocial Blacklist
- Artists Against 419
- Badbitcoin
- Bambenek Consulting
- CERT Polska
- CRDF
- CryptoScamDB
- EtherAddressLookup
- EtherScamDB
- Fake Website Buster
- MetaMask EthPhishing
- NABP Not Recommended Sites
- OpenPhish
- PetScams
- PhishFeed
- PhishFort
- Phishing.Database
- PhishStats
- PhishTank
- Phishunt
- RPiList Not Serious
- Scam.Directory
- SecureReload Phishing List
- Spam404
- StopGunScams
- Suspicious Hosting IP
- ThreatFox
- ThreatLog
- TweetFeed
- URLhaus
- ViriBack C2 Tracker
Website Preview
ZCash Reviews
More Cryptocurrencies
-
One of the most private cryptocurrencies, since no meta data is available (not even the transaction amount). It uses complex on-chain cryptographic methods such as Ring signatures, RingCT, Kovri, and Stealth addresses all of which help protect the privacy of users.
About the Data: ZCash
API
You can access ZCash's data programmatically via our API. Simply make a GET request to:
https://api.awesome-privacy.xyz/v1/services/zcash The REST API is free, no-auth and CORS-enabled. To learn more, view the API Docs or read the API Usage Guide.
Share ZCash
Help your friends compare Cryptocurrencies, and pick
privacy-respecting software and services.
Share ZCash and Awesome Privacy with your network!