ZKCash logo ZKCash Whitepaper
@zk_cash

ZKCash (ZKC)

Privacy-first digital currency powered by zero-knowledge cryptography. Fast, borderless, and confidential transactions—without exposing identity or on-chain data.

Abstract

ZKCash is a privacy-first digital currency. It enables fast, borderless, and confidential transactions, allowing anyone to move value freely without exposing identity or on-chain data. Built on advanced zero-knowledge proofs, ZKCash merges the auditability of blockchains with the privacy of modern cryptography: every transaction is verified without revealing personal or financial details—delivering true financial sovereignty.

Core Features

Zero-Knowledge Privacy

Every transaction is protected by zk-proofs, enabling full verification without revealing sender, receiver, or amount. Privacy by default — transparency by choice.

Fast & Borderless

Optimized for efficiency. Send value globally with low fees and no intermediaries.

Confidential by Design

On-chain user data and balances remain encrypted. Only the owner controls disclosure.

Decentralized Money

No central authority, no censorship. Users can own, send, and store value freely.

Interoperable Future

Designed for zk-based ecosystems and Layer-2 networks—enabling private DeFi and cross-chain payments.

System Overview

3.1 Actors

  • Users: Hold ZKC, create shielded notes, and generate proofs.
  • Relayers (optional): Submit transactions on behalf of users to reduce metadata leakage.
  • Provers: Local or decentralized markets generating zk-proofs quickly.
  • Validators / Sequencers: Order transactions and verify proofs (role depends on deployment mode).

3.2 Asset

ZKC is the native currency used for fees and network incentives—private money that is verifiable, transferable, and composable.

3.3 Deployment Modes (Composable by Design)

  • Mode A — zk-Rollup on L1: ZKCash deploys as a zk-rollup (e.g., on Ethereum). Proofs attest to valid state transitions; data availability resides on L1.
  • Mode B — Sovereign Chain: ZKCash runs its own PoS/BFT chain with on-chain SNARK verification and light-client bridges.

Both modes share the same shielded pool and transaction circuits, enabling migration and multi-deployment with consistent privacy guarantees.

Protocol Design

Commitments & Notes

Funds are represented as notes. Each note commits to (amount, asset_id, owner, randomness) using a binding & hiding commitment scheme.

Merkle Accumulator

Commitments are inserted into an incremental Merkle tree, forming the shielded set for efficient inclusion proofs.

Nullifiers

A nullifier uniquely represents a spent note without revealing which note; consensus enforces non-repetition.

Spend Authorization

Proofs attest the spender owns the note (via spend key) and that inputs equal outputs (plus fees).

Proof System

Modern proving systems (e.g., PLONK/Halo-style) with recursion for batch verification. Circuits are audited and parameterized to avoid toxic trusted setups where possible.

Viewing Keys

Cryptographic viewing keys enable incoming-only view, full-view, or scoped disclosures—without degrading overall privacy.

Transaction Lifecycle (high-level)

// 1) Prepare notes & witnesses
inputs   = [note_A, note_B]
outputs  = [note_C, note_D]
witness  = { merkle_paths, spend_key, rnd }

// 2) Prove
proof = Prove( circuit, {inputs, outputs, witness} )

// 3) Submit (direct or via relayer)
tx = { commitments(outputs), nullifiers(inputs), proof, memo? }
Broadcast(tx)

// 4) Verify
assert Verify(proof) && NonRepeat(nullifiers) && BalanceConserved(inputs, outputs)

Selective Transparency & ZK Receipts

Viewing Key Sharing

Users can share an IVK (incoming viewing key) or FVK (full viewing key) with auditors, businesses, or counterparties for scoped visibility.

ZK Receipts

  • Proof of Payment: “A payment ≥ X to domain D occurred before time T.”
  • Ownership / Balance Proofs: “Holder controls ≥ Y ZKC.”
  • Counterparty-private invoices: “Invoice #123 settled,” without leaking amounts or addresses.

zk-KYC Compatibility (optional)

Users can attach proofs that they satisfy policy predicates (e.g., negative membership on sanctions lists) without disclosing identity.

Interoperability

7.1 Cross-Chain Value Flow

  • Bridged Shielded Pools: On supported chains, ZKCash maintains canonical shielded pools. A cross-chain move is modeled as a burn on chain A + mint on chain B, both governed by verifiable proofs.
  • Light Clients / ZK Bridges: Preference for light-client or ZK-verified bridges to minimize trust in multisigs.
  • DeFi Adapters: Private swaps/escrows via adapter contracts accepting shielded proofs—enabling private DeFi flows (e.g., DEX trades without linkable traces).

7.2 Layer-2 Integration

  • Rollups: Circuits and note formats are rollup-friendly. DA may reside on the host L1 or a reputable DA layer.
  • Private Routers: Cross-rollup payments route via privacy-preserving relays that never learn sender/amount.

Economics & Fees

Fees compensate provers, relayers (when used), and network inclusion. ZKCash targets low end-user fees and near-instant confirmation; actual latency and cost depend on deployment (zk-rollup vs sovereign chain), proof market efficiency, and DA layer configuration.

  • Fee sources: proof generation, verification, inclusion.
  • Incentives: staking/validation (sovereign mode) or L1 rollup economics; optional relayer fees.

Security Considerations

  • Soundness: Circuits aim to enforce balance conservation, nullifier uniqueness, and authorization.
  • Parameters: Preference for setups avoiding toxic trust; where unavoidable, use multi-party ceremonies and audited parameters.
  • Audits: Independent audits of circuits, proof system bindings, and bridge/adapter contracts are required prior to mainnet launch.
  • Metadata: Use relayers / network hygiene to reduce linkability; avoid deterministic memo patterns.
  • Upgradability: Protocol upgrades gated by verifiable governance with conservative migration paths for the shielded set.

Compliance & Policy

ZKCash enables optional, user-controlled disclosures via viewing keys and ZK receipts. Policy predicates (e.g., sanctioned-list negative membership) can be proven without identity exposure, supporting compliance use-cases while preserving privacy.

Roadmap

  • Phase 1 — MVP: Core circuits, shielded pool, local proving; dev tooling and docs; testnet with relayer flow.
  • Phase 2 — Rollup Pilot: Mode A (zk-rollup) on L1; DA integration; explorer & wallet support; ZK receipts v1.
  • Phase 3 — Interop: Adapters for private DeFi; light-client/zk bridge pilot; cross-rollup private routing.
  • Phase 4 — Sovereign: Mode B (sovereign chain) with on-chain SNARK verification; staking/sequencing; migration tools.

Glossary

  • Note: Encrypted representation of funds committed to the shielded set.
  • Nullifier: Unique value marking a note as spent—prevents double spends without revealing which note.
  • Viewing Key: Key enabling read-only visibility (inbound/full/scoped).
  • Shielded Pool: Set of commitments representing private funds.
  • DA (Data Availability): Mechanism ensuring necessary data is available to verify state transitions.

Disclaimer

This document describes a technical design in active development and is provided “as is” for informational purposes. Deployment details, parameters, and timelines may change as the system is engineered, audited, and tested.