How Zcash Works

Key Facts

• A Zcash wallet decides which receiver and value pool a payment actually uses.
• Shielded notes are encrypted for their recipients while zero-knowledge proofs establish validity.
• Nodes reject invalid signatures, proofs, value balances, and repeated nullifiers under shared consensus rules.
• The public chain still records transaction existence, a transaction identifier, and block inclusion.
• A recipient wallet scans compact chain data and attempts to decrypt notes addressed to its keys.

The wallet chooses the real privacy path

A Zcash payment begins before anything reaches the network. The sender gives a wallet a destination, an amount, and sometimes a memo. The wallet resolves the destination into a receiver it supports, selects spendable funds, calculates a conventional fee, creates change, and chooses which transaction components to construct. That choice matters because Zcash supports transparent components alongside Sapling and Orchard shielded components.

A Unified Address can package several receiver types, but it is not itself a privacy guarantee. A capable wallet normally prefers the strongest mutually supported shielded receiver. Another wallet may fall back to a transparent receiver or refuse the payment. The chain validates the transaction that was built, not the privacy promise a user inferred from the address label.

Shielded value is represented as notes, not public outputs

Inside a shielded pool, value is represented by notes. A note includes the value, recipient-related data, randomness, and memo material needed by the protocol. The sender encrypts the note plaintext so that an intended recipient can discover and decrypt it while an ordinary chain observer sees ciphertext and protocol commitments instead of a readable address-and-amount pair.

A commitment binds the transaction to a particular note without publishing the note. Commitments are appended to a pool-specific tree. When the recipient later spends the note, the wallet proves that an eligible note exists in the commitment tree and that it controls the required spending authority. The note itself does not become a public unspent output in the Bitcoin sense.

The proof shows that private arithmetic is valid

A shielded transaction must convince every validating node that no counterfeit ZEC was created and no note was spent without authorization. Zcash uses zero-knowledge proofs for that job. The proof establishes that the private witness satisfies the shielded circuit: committed notes exist, values balance, keys authorize the spend, and required protocol relationships hold. It does not need to reveal the protected payment facts used to construct the proof.

Orchard uses Halo 2 and packages shielded activity into actions. Signatures still authorize the transaction, while value commitments and consensus checks connect private components to any transparent or cross-pool value. Zero knowledge is not a magic invisibility switch. Network metadata, wallet behavior, transparent legs, and visible value crossing pool boundaries can still reveal context.

Nullifiers stop the same note being spent twice

Public ledgers usually prevent double spending by pointing directly to a previous output. A shielded protocol cannot expose that link without damaging privacy. Instead, a valid shielded spend publishes a nullifier derived from the note and secret key material. Nodes maintain the set of nullifiers already accepted and reject a transaction that repeats one.

The nullifier is public, but it is designed not to identify the note commitment that created it to an observer without the relevant authority. That gives consensus a durable spent marker without turning the shielded graph into a public map of which output funded which later payment.

Peers relay bytes; nodes enforce one rule set

After construction, the wallet broadcasts the serialized transaction to a Zcash peer. Peers relay it through the network. Consensus nodes independently parse the transaction and check its version, signatures, proofs, nullifiers, value balances, expiry, fee behavior, and the rules active in the current network-upgrade epoch. A miner can include a valid transaction in a candidate block, and other nodes verify the block before extending their view of the chain.

The network does not need a trusted privacy server. Each validating implementation can reach the same accept-or-reject result from public protocol data and cryptographic verification. Zcash currently has distinct node implementations, including Zebra and the transitioning zcashd codebase, but consensus compatibility requires them to enforce the same active rules.

The recipient discovers an owned note locally

A shielded recipient cannot search a public address index because the recipient is encrypted. The wallet scans chain data using incoming viewing capability derived from its keys. It attempts note decryption, recognizes notes it can receive, updates witnesses needed for later spends, and tracks whether owned notes have been consumed. A full viewing key can additionally support outgoing visibility without granting spending authority.

This local discovery model explains both the privacy and the operational cost of shielded wallets. Wallets need synchronized chain state, correct key derivation, reliable scanning, and careful backups. When those pieces work, the public network can settle the payment while the recipient learns the private details that ordinary observers cannot.

FAQ