This repository captures reusable design patterns for integrating zero-knowledge proofs on Cardano/Plutus V3. Each pattern has its own detailed write-up; this README provides a quick synopsis and directs you to the primary documents.
When a single zk verifier (Plonk, Halo2) exceeds Plutus size or budget limits, split it into multiple minting policies (“segments”). Each segment verifies a portion of the proof and mints a receipt token tied to a shared InputHash. A main verifier script checks that all required receipts exist for the same input before authorizing the final action. Result: arbitrarily large verifiers become feasible by composing smaller scripts.
Mint a non-fungible token (NFT) only when a zk proof succeeds, and lock it in a validator whose datum stores the proven information. The NFT cannot leave the UTxO unless another proof updates the datum while keeping the token, so any protocol can trust the datum simply by requiring the NFT. This pattern turns zk proofs into reusable on-chain “proof capsules”.
Collect many local proof UTxOs (each marked valid by their own verifier) and feed them into an aggregator circuit/validator that proves a global predicate over their outputs. Useful for rollups, batched state updates, or multi-step protocols. Contrasts with segmentation: aggregation reasons about many proofs, not one split across scripts.
Use the bilinear accumulator from perturbing/plutus-accumulator to commit to large sets in a single G2 element. Contracts can enforce membership/non-membership with constant-size proofs and support batched additions/removals. Ideal for registries, rollup queues, and any situation where on-chain storage must stay tiny while the off-chain set grows large.
Each markdown document dives into requirements, interfaces, security considerations, and sample workflows. Start from the summaries above to pick the pattern that matches your application.*** End Patch