Prove what you know without revealing what you know.

Zero-knowledge proofs solve a problem that was previously impossible: prove a statement is true without revealing the information that makes it true.

The ability to prove without revealing enables product designs that were previously impossible: prove you are over 18 without revealing your date of birth, prove your credit score is above 700 without revealing the score or the underlying data, prove you hold a valid ticket without revealing the ticket details, prove a computation was executed correctly without revealing the inputs. These are not niche cryptographic curiosities — they are the foundation of privacy-preserving identity, compliant DeFi, confidential transactions and efficient Layer 2 scaling. ZK technology is moving from research to production rapidly, and the applications built on it will have structural privacy advantages over competitors built on transparent blockchains.

The ZK engineering stack.

System Layers

• Circuit Layer: Constraint system design in Circom/Noir, witness generation, circuit optimisation
• Proof System Layer: Groth16/PLONK/STARK proof generation, trusted setup (for Groth16), prover performance
• Verifier Layer: On-chain Solidity verifier contracts, calldata optimisation, batched verification
• Application Layer: Proof generation APIs, client-side proving (browser/mobile), proof caching
• Integration Layer: Smart contract integration, ZK-enabled dApp frontend, proof pipeline infrastructure

Core Technical Capabilities

• ZK Circuit Design

  Arithmetic constraint systems in Circom (snarkjs) or Noir (Barretenberg backend). Circuit design for: membership proofs (Merkle inclusion), range proofs, hash preimage proofs, signature verification and custom application logic.

• ZK Identity Systems

  Privacy-preserving identity verification — prove nationality, age, accreditation or credential possession without revealing underlying documents. Semaphore protocol for anonymous signalling, Proof of Passport circuits.

• ZK Rollup Components

  Transaction circuit design, state transition proofs, batch proof aggregation, on-chain verifier contracts and data availability strategy for ZK rollup applications.

• Privacy-preserving DeFi

  ZK-enabled private transactions (Tornado Cash-style), confidential DEX orders (hiding trade size), private lending (prove collateralisation without revealing positions) and ZK-based KYC compliance (prove compliance without on-chain identity reveal).

• On-chain Verifier Contracts

  Solidity verifier contracts generated from Circom circuits, gas-optimised PLONK verifiers, batched proof verification, proof validity caching and ZK proof integration in existing smart contract systems.

• Proof Generation Infrastructure

  Server-side proof generation with GPU acceleration, client-side proving with snarkjs/Barretenberg in browser/Node.js, proof caching layer, proof verification API and prover scalability architecture.

How we think about ZK applications.

ZK proofs are a cryptographic tool. Like any tool, they are appropriate for specific jobs and overkill for others. Start with the problem — not the technology.

• ZK is appropriate when privacy is a requirement, not a preference

  ZK proves something is true without revealing why it is true. This is appropriate when: the inputs to a computation are genuinely sensitive and must not be revealed, the computation must be verifiable by untrusted parties, or regulatory compliance requires both auditability and privacy simultaneously. For applications where inputs can be revealed without harm, simpler cryptographic tools (standard hash commitments) are sufficient.

  Axiom:

• Circuit complexity has direct cost implications

  ZK circuits have a constraint count that determines proof generation time and cost. A 10,000-constraint circuit generates a proof in milliseconds. A 10,000,000-constraint circuit requires server-side GPU proving and takes seconds. Complex application logic in circuits is expensive. Circuit design must balance expressiveness with constraint count — use hashes (Poseidon over Keccak for ZK-friendliness) and optimise hot paths.

  Axiom:

• Client-side vs server-side proving is a product decision

  Client-side proving (in the browser or mobile app) maximises privacy — the prover never sees the witness. But it is slow for complex circuits and limited by device compute. Server-side proving is fast but requires the prover to see the witness. The right choice depends on witness sensitivity and circuit complexity.

  Axiom:

• The trusted setup is a one-time ceremony for Groth16

  Groth16 proofs require a "trusted setup" — a multi-party computation that generates proving and verification keys. The security assumption: at least one participant in the setup was honest. Hermez, Zcash and other major projects have run these ceremonies with thousands of participants. PLONK/UltraHONK (Noir) and STARKs are trustless — no trusted setup required.

  Axiom:

ZK system design decisions.

• Circom vs Noir vs Cairo?

  Impact: Noir for most new ZK applications — better developer experience than Circom, no trusted setup with UltraHONK, active development. Circom for applications targeting existing Groth16 ecosystem. Cairo for StarkNet-deployed applications.

  • Circom + snarkjs/SnarkJS — most widely used, Groth16 and PLONK, larger community
  • Noir (Aztec) — Rust-like syntax, easier than Circom, Barretenberg backend (PLONK)
  • Cairo (StarkNet) — STARK proofs, no trusted setup, fastest for complex computations
  • Halo2 (ZCash) — no trusted setup, powerful but complex

• Proof system?

  Impact: PLONK (via Noir/Barretenberg) for applications where trustlessness matters more than proof size. Groth16 for applications where proof size and verification gas cost are paramount. STARKs for applications requiring post-quantum security or StarkNet deployment.

  • Groth16 — smallest proof size (128-192 bytes), requires trusted setup, fastest verification
  • PLONK/UltraPLONK — no trusted setup, larger proof, moderate verification cost
  • STARK — no trusted setup, no trusted hardware, larger proof, post-quantum secure
  • Nova — recursive proofs, efficient for incrementally verifiable computation

• Client-side vs server-side proving?

  Impact: Client-side for witness data that must never leave the user's device (identity documents, private keys). Server-side for complex circuits where proving time would degrade UX. Hybrid based on witness sensitivity per circuit.

  • Full client-side — maximum privacy, slow for complex circuits, limited by device
  • Server-side with encrypted witness — privacy via encryption, server sees ciphertext
  • Server-side — fastest, server sees witness, privacy depends on server trust
  • Hybrid — simple proofs client-side, complex proofs server-side

• On-chain verification gas cost?

  Impact: Batched proof verification amortises verifier gas cost across many proofs — appropriate for high-volume applications. For L1, Groth16's constant verification cost is advantageous.

  • Groth16 verifier (~250K gas) — constant cost regardless of proof complexity
  • PLONK verifier (~300-500K gas) — slightly higher than Groth16
  • STARK verifier (1M+ gas) — expensive for Ethereum L1, viable on L2s
  • Batched verification — amortise cost across many proofs

• ZK-friendly hash function?

  Impact: Poseidon in circuits where possible — it uses ~50x fewer constraints than Keccak256 for the same computation. Use Keccak256 only when EVM compatibility is required (Merkle tree roots that must match on-chain Keccak trees).

  • Poseidon — ZK-optimised, significantly fewer constraints than Keccak256
  • MiMC — ZK-friendly but older, less used now
  • Keccak256 — EVM standard, high constraint count in ZK circuits, expensive
  • Pedersen — efficient in some ZK systems, less general-purpose

• Recursive proofs needed?

  Impact: Recursion for applications that need to aggregate many proofs (ZK rollups, batch verification). Nova for incrementally verifiable computation (proving a sequence of state transitions efficiently). Most applications do not need recursion.

  • No recursion — single proof per computation, simpler
  • Recursive proofs — compress many proofs into one, complex, enables rollups
  • Folding schemes (Nova) — efficient incremental verifiable computation
  • STARK recursion — native to STARK-based systems (StarkNet)

What PROPELOO builds with ZK.

• ZK Identity Verification

  Privacy-preserving age, nationality or credential verification — prove attributes without revealing underlying documents. Semaphore-based anonymous signalling.

• Compliant DeFi (ZK KYC)

  On-chain KYC proof — prove regulatory compliance once, use across multiple DeFi protocols without repeated KYC or on-chain identity exposure.

• Private NFT Gating

  Prove you own a specific NFT or belong to a set without revealing which token — token-gated access without surveillance.

• ZK-Merkle Proofs

  Off-chain merkle tree with on-chain ZK membership proofs — efficient airdrop claim verification, whitelist systems, private voting.

• ZK Game State Proofs

  Prove valid game moves without revealing strategy — chess, poker and other information-asymmetric games that benefit from cryptographic fairness.

• Proof Generation Infrastructure

  Scalable proof generation service — GPU-accelerated server-side proving, proof caching, queue management and verification API for high-throughput applications.

The ZK engineering stack.

• Circuit Languages

  Stack: Circom, Noir (Aztec/Barretenberg), Cairo (StarkNet), Halo2

• Proof Systems

  Stack: snarkjs (Groth16/PLONK), Barretenberg (UltraHONK), STARK (StarkNet), Nova-Scotia

• Libraries

  Stack: Semaphore (anonymous signalling), Merkle tree libraries, Poseidon hash, circom-ecdsa

• Verifiers

  Stack: snarkjs Solidity verifier, Noir Solidity verifier, Batched verifier contracts

• Infrastructure

  Stack: GPU prover server (AWS G4dn), Proof caching (Redis), Snarkjs WASM (browser), Proof generation queue (SQS)

• Frameworks

  Stack: Aztec.nr (private smart contracts), StarkNet (Cairo), Polygon Miden, Aleo (Leo language)

ZK proof security depends on correct circuit design.

• Under-constrained circuits

  ZK circuits that do not fully constrain the witness allow invalid witnesses to produce valid proofs. An under-constrained circuit is a critical vulnerability — an attacker can generate valid proofs for false statements. Circuit review must verify that every signal is fully constrained.

• Trusted setup ceremony

  Groth16 requires a trusted setup where the security assumption is that at least one participant was honest. Use established ceremonies (Hermez, Zcash Powers of Tau) as the universal phase, with a ceremony-specific phase conducted with public participation.

• Witness generation security

  In client-side proving, the witness (private inputs) is generated in the browser. Malicious scripts with access to the page could exfiltrate witness data. Witness generation should happen in a isolated Worker or wasm context.

• Verifier contract correctness

  Auto-generated Solidity verifiers are generally correct. Custom verifier optimisations are a source of verification bypass bugs. Any manual modification to generated verifier contracts requires expert review.

• Nullifier uniqueness

  Many ZK applications use nullifiers to prevent double-spending or double-voting. Nullifier construction must guarantee uniqueness and prevent prediction or collision. Nullifier from hash(secret, topic) where secret is unknown to the verifier.

• Side-channel attacks on proving

  Server-side provers that see witness data can leak it via timing attacks, logs or memory dumps. Prover infrastructure must treat witness data as sensitive: encrypted at rest, not logged, isolated compute environment.

From concept to ZK-enabled product.

1. 01. Problem Analysis

   Determine if ZK is the right tool, define the statement to prove, identify public/private inputs.

2. 02. Circuit Design

   Constraint system design in Circom/Noir, ZK-friendly primitives selection, constraint count estimation.

3. 03. Circuit Implementation

   Circuit development with test vectors, trusted setup (if Groth16), proving key generation.

4. 04. Verifier Contract

   Solidity verifier contract generation, gas optimisation, integration with application contracts.

5. 05. Proof Infrastructure

   Proof generation API, client-side or server-side proving setup, caching layer.

6. 06. Application Integration

   dApp frontend integration, proof submission to contracts, user flow for witness input.

7. 07. Security Review & Launch

   Circuit audit (under-constrained check), verifier contract review, performance testing.

ZK Solutions Engagements

Zero-knowledge proof systems built for privacy, scalability and compliance.

• ZK-based KYC Credential System

  Challenge: DeFi protocol required KYC compliance without storing user PII on-chain or with the protocol.

  Architecture: Trusted KYC issuer generates credential Merkle leaves. User generates Semaphore nullifier to prove credential membership without revealing identity. On-chain verifier contract checks proof and nullifier for uniqueness. Credential revocation via Merkle root updates.

  Outcome: Protocol achieved regulatory KYC compliance. Zero PII stored on-chain or by protocol. 50,000 verified users across the system. Proof generation time under 3 seconds in browser.

• Custom ZK Rollup for Payment Settlement

  Challenge: Payment network processing 100,000 daily transfers needed Ethereum finality with costs 100x lower than L1.

  Architecture: Noir circuits for transfer validity proofs. Batch of 1,000 transfers compressed into a single PLONK proof. On-chain verifier contract accepting batch proofs with 250K gas. Off-chain sequencer with anti-censorship forced inclusion mechanism.

  Outcome: Per-transfer settlement cost reduced from $2.50 to $0.003. Ethereum finality within 15 minutes per batch. System handles 100,000 daily transfers without L1 congestion impact.

• Private DeFi Transaction Compliance Layer

  Challenge: Institution needed to participate in DeFi while keeping transaction amounts private from competitors yet maintaining audit trail for regulators.

  Architecture: Pedersen commitment scheme for amount privacy. ZK proof of transaction validity (positive balance, authorised sender) without revealing amounts. Encrypted audit log with regulator key sharing. On-chain nullifier tracking for replay prevention.

  Outcome: Institution executes DeFi transactions with competitor-private amounts. Regulator audit capability maintained via encrypted logs. No regulatory findings in post-implementation audit.

Frequently Asked Questions