How to Implement a ZK-Proof System for Anonymous Grant Applications

Anonymous grant applications address a critical need in Web3: enabling fair, unbiased funding distribution. Traditional grant processes often require applicants to disclose personal or project details that can lead to bias, doxxing, or sybil attacks. A zero-knowledge proof (ZKP) system solves this by allowing an applicant to cryptographically prove they meet specific eligibility criteria—like holding a certain NFT, having a verified GitHub account, or being a unique human—without revealing the underlying data. This creates a trustless and private application layer for DAO treasuries, ecosystem funds, and public goods funding.

The core technical architecture involves three main components. First, an off-chain prover where users generate a ZK-SNARK or ZK-STARK proof using a circuit. Libraries like Circom or SnarkJS are commonly used to write this circuit logic, which encodes the eligibility rules. Second, a verifier smart contract deployed on-chain (e.g., Ethereum, Polygon) that contains the verification key. This contract has a single function to check the validity of submitted proofs. Third, a user interface that guides applicants through generating their proof locally and submitting only the proof and public outputs to the blockchain, keeping their private inputs secret.

Here is a simplified workflow using the Circom library. First, define a circuit (eligibility.circom) that proves knowledge of a private key corresponding to a public address in a whitelist, without revealing which address.

circomCopy
pragma circom 2.0.0;
template Eligibility() {
    signal input privateKey;
    signal input whitelistRoot; // Merkle root of allowed addresses
    signal input pathElements[levels];
    signal input pathIndices[levels];
    // Derive public address from private key
    component deriveAddr = ECDSAPrivToPub();
    deriveAddr.privKey <== privateKey;
    // Verify the derived address is in the Merkle tree
    component merkleCheck = MerkleTreeChecker(levels);
    merkleCheck.leaf <== deriveAddr.pubKeyHash;
    merkleCheck.root <== whitelistRoot;
    // ... path element and index connections
    signal output valid;
    valid <== 1;
}

This circuit proves membership without disclosing the specific private key or address.

After compiling the circuit and generating a proving key and verification key, you deploy the verifier contract. Using a tool like snarkjs, you can generate a Solidity verifier. The grant application process then works as follows: 1) The user's wallet runs the prover with their private inputs. 2) The prover generates a proof. 3) The user submits a transaction to the verifier contract with the proof and any necessary public signals. 4) The contract's verifyProof function returns true if the proof is valid, registering the anonymous application. The entire process ensures the grant committee only sees a valid, anonymized proof, not the applicant's identity.

Key considerations for production systems include circuit trust assumptions (who generated the trusted setup?), user experience complexity of proof generation, and gas costs for on-chain verification. Optimizations like using Plonk or Groth16 proof systems can reduce verification gas. Furthermore, integrating Semaphore or Interep can provide reusable identity frameworks. For ongoing grants, you can use nullifiers to prevent duplicate applications from the same anonymous identity. Always audit your circuits and contracts, as subtle bugs can compromise privacy or allow invalid proofs.

Implementing this system democratizes access to funding. Projects like clr.fund and MACI (Minimal Anti-Collusion Infrastructure) have pioneered these concepts for quadratic funding. By adopting ZK-proofs, grant programs can minimize administrative overhead, reduce bias, and protect applicants, ultimately allocating capital more efficiently based on merit rather than identity. The next step is to explore specific frameworks like zk-kit or Spartan to streamline development.

Building a ZK-proof system for grant applications requires a solid grasp of core cryptographic concepts. You must understand zero-knowledge proofs (ZKPs), specifically zk-SNARKs (Succinct Non-interactive ARguments of Knowledge) or zk-STARKs, which allow a prover to demonstrate knowledge of a secret (like eligibility criteria) without revealing it. Familiarity with elliptic curve cryptography (e.g., the BN254 or BLS12-381 curves used by Circom and SnarkJS) and hash functions (like Poseidon, optimized for ZK circuits) is essential. A working knowledge of a circuit-writing language, such as Circom or Cairo, is the primary prerequisite for defining the logic of your application.

The system architecture is divided into three core, off-chain components that interact with a smart contract on-chain. First, the Circuit defines the application's rules in code (e.g., "prove citizenship without revealing your ID number"). Second, the Proving System (like Groth16 or PLONK) uses this circuit to generate a trusted setup, creating proving and verification keys. Finally, the Prover/Client Application takes a user's private inputs, runs them through the circuit with the proving key, and generates a succinct proof. This proof is the only data sent on-chain.

On-chain, a Verifier Smart Contract holds the verification key. Its sole function is to check the validity of submitted proofs. When a user submits their proof for a grant application, the contract runs the verify function. If it returns true, the application is cryptographically validated as meeting all hidden criteria, and the user's eligibility can be recorded—all without exposing their private data. This separation keeps complex computation off-chain while maintaining trust via on-chain verification.

For development, you will need a specific toolchain. We recommend using Circom 2.x for circuit writing and SnarkJS for proof generation and setup. A local development environment like Hardhat or Foundry is necessary for testing the verifier contract. You will also need access to a blockchain testnet (like Sepolia or Goerli) for deployment. All system components must be designed to handle the trusted setup ceremony securely, as compromising its toxic waste compromises the entire system's security.

A practical example for a grant circuit might prove that a user's wallet balance was above a threshold at a specific past block, using a Merkle proof of their inclusion in a historical state root. The circuit would verify the Merkle proof and the balance check without revealing the actual balance or the wallet address. This architecture ensures selective disclosure, where the application reveals only the boolean result (eligible/not eligible) derived from the hidden facts.

A ZK-SNARK circuit is a set of arithmetic constraints that define a computational statement. For anonymous grant applications, the statement is: "The applicant holds a valid credential from an approved issuer." The circuit's public inputs are the Merkle root of the approved issuer registry and the nullifier (a unique identifier to prevent double-spending). The private inputs, known only to the prover, are the actual credential, a secret, and the Merkle proof linking it to the public root.

The circuit must perform several cryptographic checks. First, it verifies the provided credential's cryptographic signature against the public key of the issuer claimed in the credential. Second, it validates that this issuer's public key is included in the approved registry by checking the supplied Merkle proof against the public root. Finally, it generates the nullifier, typically by hashing the credential ID with the applicant's secret, ensuring the same credential cannot be used to apply twice.

To implement this, developers use domain-specific languages (DSLs) like Circom or Noir. In Circom, you define templates for components like signature verification and Merkle tree inclusion. Here's a simplified conceptual outline of the main circuit template:

codeCopy
template GrantEligibility(nLevels) {
    signal input root;
    signal input nullifier;
    signal private input credential;
    signal private input secret;
    signal private input merklePath[nLevels];

    // Verify credential signature
    component sigCheck = VerifyCredentialSig();
    sigCheck.pubKey <== credential.issuerKey;
    sigCheck.message <== credential.data;
    sigCheck.signature <== credential.sig;

    // Verify issuer is in approved registry
    component merkleCheck = MerkleProof(nLevels);
    merkleCheck.root <== root;
    merkleCheck.leaf <== credential.issuerKey;
    for (var i = 0; i < nLevels; i++) {
        merkleCheck.path[i] <== merklePath[i];
    }

    // Generate nullifier to prevent double-applications
    component nullifierHash = Poseidon(2);
    nullifierHash.inputs[0] <== credential.id;
    nullifierHash.inputs[1] <== secret;
    nullifierHash.out === nullifier;
}

Design considerations are critical for security and efficiency. The choice of hash function (e.g., Poseidon for SNARK-friendly hashing), the depth of the Merkle tree, and the signature scheme (e.g., EdDSA) directly impact the circuit's size and proving time. A larger circuit is more expensive to generate proofs for. The circuit must also be designed to be non-malleable; the nullifier must be uniquely and deterministically tied to the specific credential and user secret.

After the circuit logic is written, it is compiled into a set of constraints (often represented as R1CS or a similar format) and a proving key/verification key pair. This compilation step is done using the DSL's compiler (like circom). The resulting artifacts are what the prover (the applicant's client) and the verifier (the grant platform's smart contract) will use. The circuit design is the foundation—any flaw here compromises the entire system's privacy and security guarantees.

The off-chain prover is a standalone application, typically written in Rust or JavaScript, that uses a ZK-SNARK proving system like Groth16 or PLONK. Its primary function is to generate a cryptographic proof that a user's private inputs satisfy the public verification logic, known as the circuit. For a grant application, this circuit would encode rules such as citizenship == CountryX AND annualIncome < $50,000 AND hasDegree == true. The user provides their secret data (e.g., a cryptographic hash of their passport and tax documents) as private witness inputs to the prover.

To generate a proof, the prover needs two key artifacts compiled from the circuit: the proving key and the verification key. The proving key is used locally by the applicant to create the proof, while the verification key is used on-chain by the verifier contract. Using libraries like snarkjs, circomlib, or arkworks, the prover executes the computation. For example, a command might look like: snarkjs groth16 prove circuit_final.zkey witness.wtns proof.json public.json. This generates a proof.json file containing the actual proof points (A, B, C) and a public.json file with the public signals (e.g., the hash of the eligible criteria).

Managing these artifacts securely is critical. The proving key must be distributed to users through a trusted channel, as a compromised key could allow fake proofs. The verification key is small enough to be embedded into the on-chain verifier contract. The proof itself is compact, often less than 1 KB, making it cheap to submit in a blockchain transaction. This off-chain generation model ensures that the heavy computational load of proof creation is borne by the user's machine, keeping gas costs on the main chain minimal and scalable.

A robust implementation must handle edge cases and errors gracefully. The prover application should validate the witness data format before attempting proof generation to avoid wasted computation. It should also provide clear feedback if the private inputs do not satisfy the circuit constraints, indicating to the user why they are ineligible. For production systems, consider integrating this prover into a user-friendly desktop application or a secure web backend service that never sees the user's raw private data, only the generated proof.

The on-chain verifier is the core component that validates the applicant's zero-knowledge proof without revealing their identity. For this guide, we'll implement a verifier for a Groth16 proof system using the snarkjs library and the circom compiler. The contract's primary function is to check that a submitted proof corresponds to a valid public input, confirming the applicant meets the grant's eligibility criteria (e.g., holding a specific NFT or token) while keeping their wallet address private. We'll write this contract in Solidity, targeting the Ethereum Virtual Machine (EVM).

First, you must generate the verifier's Solidity code from your compiled circuit. After writing your circuit in circom (e.g., eligibility.circom) and performing a trusted setup, use snarkjs to export the verifier: snarkjs zkey export solidityverifier circuit_final.zkey verifier.sol. This command creates a Verifier contract with a verifyProof function. This function accepts the proof parameters (a, b, c) and an array of public inputs. The contract uses pre-compiled elliptic curve pairing contracts (usually at fixed addresses like 0x8 for BN254) to perform the cryptographic verification.

Deploy the generated Verifier.sol contract to your chosen network. The main integration point for your grant application dApp will be the verifyProof function. Your frontend, after generating a proof locally with snarkjs, will call this function with the proof data. A return value of true means the proof is valid. It is critical to ensure the public inputs passed to the contract match exactly those used to generate the proof; even a single bit of difference will cause verification to fail. Always test verification on a testnet before mainnet deployment.

For enhanced security and gas efficiency, consider using a verifier registry pattern. Instead of having your main grant contract inherit from the verifier, create a separate registry contract that holds the address of the deployed verifier. Your grant contract can then call IVerifier(registry.getVerifier()).verifyProof(...). This pattern allows you to upgrade the verifier logic or circuit without migrating the entire grant system. Remember that verification gas costs are significant (often 200k-500k gas) and are a key constraint for user experience.

Finally, your grant contract must use the verification result to gate application submissions. A typical function might look like:

solidityCopy
function submitApplication(bytes calldata _proof, uint[] calldata _publicInputs) external {
    require(verifier.verifyProof(_proof, _publicInputs), "Invalid proof");
    // Map the nullifier (derived from a public input) to prevent double-spending
    require(!nullifierSpent[_publicInputs[1]], "Application already submitted");
    nullifierSpent[_publicInputs[1]] = true;
    // Process the anonymous application
}

This ensures each eligible identity can apply only once, preserving anonymity through the nullifier hash while preventing Sybil attacks.

A zero-knowledge proof (ZKP) system allows a prover (the applicant) to convince a verifier (the committee) that a statement is true without revealing the underlying data. For grant reviews, this means proving an application meets specific criteria—like holding a minimum token balance, belonging to a DAO, or having completed prerequisite tasks—while keeping the applicant's wallet address and associated on-chain history private. This shifts the review from assessing who applied to validating what was submitted against objective, programmatically defined rules.

The core technical workflow involves two main components: a circuit and a verification contract. First, you define the eligibility logic in a ZK circuit using a framework like Circom or Noir. For example, a circuit could take a private input (the applicant's secret identity) and public inputs (the eligibility parameters) to prove: I own > 100 GOV tokens as of block #X, and my identity is a member of Snapshot space Y, without revealing my address. The circuit compiles into a verifier smart contract and a proving key.

Applicants then generate a ZK-SNARK proof locally using their private data and the proving key. They submit only this proof and the necessary public inputs to the grant platform. The verifier contract, deployed on-chain, can validate the proof in a single gas-efficient operation. A successful verification confirms the application is eligible, but reveals no link between the proof and the applicant's real-world identity. This process is similar to Semaphore's signaling or zkProof of Humanity mechanisms, but tailored for grant criteria.

Implementing this requires careful design of the circuit constraints to match grant requirements. Common constraints include: Merkle proof inclusion for DAO membership lists, token balance verification via state proofs, and proof of prior transaction non-existence. Since all logic is public in the circuit code, the review process becomes fully transparent and deterministic. The committee's role evolves to curating the eligibility rules and auditing the circuit, rather than scrutinizing personal applicant data.

For development, you can use libraries like @zk-kit/protocols for identity groups or circomlib for cryptographic primitives. A basic proof generation script in JavaScript might use the SnarkJS library. The on-chain verifier, often generated automatically from the circuit, is a lightweight contract with a single verifyProof function that returns a boolean. This setup ensures the heavy computational work of proof generation is done off-chain, keeping transaction costs minimal.

This architecture fundamentally enhances grant fairness by eliminating implicit bias. It allows for sybil-resistant and retroactive funding rounds where contributions are proven anonymously. The next step involves integrating this proving mechanism into your application front-end and designing a secure process for applicants to manage their private inputs without compromising their anonymity throughout the review period.

The implemented system demonstrates a fundamental privacy-preserving pattern: proving eligibility without revealing the underlying data. By using Circom for the arithmetic circuit and SnarkJS for proof generation, you created a ProofOfGrantEligibility circuit that validates a user's credentials against a hidden Merkle root. The Hardhat project structure, complete with a verifier contract, shows how to integrate this proof into an Ethereum application. The key takeaway is that zero-knowledge proofs shift the trust from the data itself to the correctness of the computation.

For production readiness, several critical next steps are required. First, audit your Circom circuit for logical errors and side-channel vulnerabilities; consider using tools like Picus or Verilog for formal verification. Second, optimize the proving key size and verification gas costs, potentially by exploring alternative proving systems like PLONK or Halo2 which offer different trade-offs in trust setup and performance. Third, implement a robust backend service for managing the trusted setup ceremony, generating proofs, and handling the Merkle tree updates off-chain.

To extend this prototype, explore integrating with existing identity frameworks. You could use **zk-SNARKs to prove membership in a Semaphore group or attestations from a Verifiable Credential issued by Disco.xyz. Another advanced direction is implementing nullifier schemes to prevent double-spending of anonymous applications. Always reference the latest documentation for libraries like circomlib and snarkjs for updates and security best practices.

The landscape of ZK tooling is rapidly evolving. Stay informed about new developments from teams like Polygon zkEVM, zkSync, and Scroll, as they often release improved proving libraries and more efficient verifier contracts. Participating in communities such as the 0xPARC forum and ZKValidator can provide valuable insights into cutting-edge techniques and common pitfalls in ZK application development.