Onchain Atlas

On-Chain Proof Verification

A smart contract can check a cryptographic proof that a statement is true — like 'this person is over 18' or 'this address belongs to a group' — without ever seeing the private data behind it.

Also called: zero-knowledge proof verification · on-chain ZK verification · proof-based attestation

What it is

On-chain proof verification lets a smart contract confirm that a claim is valid by checking a compact cryptographic proof, typically a zero-knowledge proof, instead of receiving and checking the underlying private data itself. A user (or their wallet) generates the proof off-chain based on secret information they hold, and submits only the proof to the contract, which runs a verification function and accepts or rejects it in one transaction.

How it works

  1. A user holds some private data — a credential, a secret, a set membership fact — that they want to prove something about without revealing the data itself.
  2. Off-chain, the user's device runs a proving algorithm that takes the private data and a public statement (like "my age is over 18" or "I am one of these 10,000 group members") and produces a proof, a piece of data much smaller than the underlying secret.
  3. The user submits the proof (and any public inputs, like the statement or a group's Merkle root) to a verifier smart contract on-chain.
  4. The contract runs a verification algorithm — typically involving elliptic curve pairing checks or polynomial commitment checks — that mathematically confirms the proof could only have been generated by someone who actually knows valid private data satisfying the statement.
  5. If verification passes, the contract executes the intended action: minting a credential, allowing a vote, granting access, or emitting a "nullifier" that prevents the same secret from being used twice (stopping double-voting or double-claiming).
  6. The private data itself never touches the blockchain, so nothing about the user's actual credential or identity is exposed, only the fact that they satisfy the statement.

Why designers use it

  • Enables privacy-preserving compliance: proving eligibility (age, KYC status, group membership) without exposing the actual sensitive document or identity.
  • Supports anonymous but sybil-resistant participation — a user can prove "I am a unique member of this group" for voting or airdrops without revealing which member they are.
  • Keeps verification cheap and fast on-chain (checking a proof is far cheaper than checking a full private dataset), since blockchains are poor at storing or processing private data anyway.
  • Lets credentials be reused across many contexts (once issued, a proof can be generated repeatedly) without re-exposing the original data each time.

Failure modes

  • Trusted setup risk: some proof systems require an initial ceremony to generate public parameters, and if that ceremony's secret data isn't properly destroyed, false proofs could theoretically be forged.
  • Circuit bugs: the "circuit" defining what the proof actually checks is complex code; a subtle bug can let invalid claims pass verification (proving something false) even though the cryptography itself is sound.
  • Front-running and replay: if nullifiers or proof submissions aren't handled carefully, an observer could front-run a transaction or a proof could be replayed in an unintended context.
  • Off-chain issuance trust: the mechanism only proves something about credentials the user was issued — if the issuer itself is compromised or issues fraudulent credentials, verification will happily confirm falsehoods.
  • Usability and gas costs: generating proofs can be computationally heavy on user devices, and on-chain verification, while cheaper than raw data checks, still carries real gas costs that can be significant depending on the proof system.

What to check before using it

  • Confirm whether the proof system requires a trusted setup, and if so, whether the ceremony was conducted transparently with verifiable destruction of toxic waste.
  • Check whether the circuit logic has been audited separately from the underlying cryptographic library, since bugs live in the circuit, not just the math.
  • Understand the trust assumptions on credential issuance — verification is only as good as what's being proven about.
  • Test gas costs and proof generation time on real user devices, especially mobile, before assuming this is production-ready UX.
  • Verify nullifier design prevents replay or double-use across the specific contexts your application cares about.

Experiments that used it · 2

Shown oldest first, so you can watch the design evolve.

Semaphore
A zero-knowledge protocol from Ethereum's PSE team that lets members of an on-chain group broadcast signals (votes, endorsements, messages) provably as group members without revealing which member they are.
2019 major success
Polygon ID
Polygon's zero-knowledge self-sovereign identity stack (built on iden3/Circom) that let users prove claims about themselves on-chain without revealing the underlying data, later spun out as Privado ID.
2022 partial success