ZK Engineer Portfolio: 3 Projects With Acceptance Criteria

A useful ZK engineering portfolio makes a narrow claim and gives someone else enough evidence to check it. The project does not need to be a new proving system. It needs to show that you understand the statement being proved, the limits of the design, and how to test the implementation.

Below are three editorial project briefs, not hiring requirements from a particular employer. Choose one that matches the work you want. For the broader role distinctions, start with our ZK engineer career guide.

Project 1: a private membership demonstration

Brief: demonstrate that a supplied secret belongs to a committed set without revealing which member it is. Use synthetic data and an existing, documented library for cryptographic primitives. Do not present the prototype as an audited identity product.

Start by writing the statement in ordinary language. Identify the commitment that the verifier trusts, the private witness, and the public output. Explain who creates the set and why a verifier should accept that set in the first place.

Circom's signals documentation is a useful reference for the distinction between witness assignment and enforced constraints. Noir's documentation offers another implementation path. Pick one toolchain and pin versions rather than combining tutorials written for incompatible releases.

Acceptance criteria

• A valid member produces a proof that verifies against the expected commitment.
• A non-member and an incorrect authentication path fail.
• Changing the public commitment causes verification to fail.
• The README identifies everything public, including information revealed by the application outside the proof.
• Setup and tests run from a clean checkout using documented commands.

Extension: add a one-use action only after defining the required replay protection. Explain the scope of uniqueness and how the application enforces it. Membership alone does not establish that someone has not already performed the action.

What to discuss: the difference between proving membership and establishing real-world identity; what happens if the set issuer is dishonest; and whether a public output links separate actions.

Project 2: a reproducible zkVM workload benchmark

Brief: implement a bounded computation, prove its execution, and measure where time and memory go. Use a fixed synthetic input set. The point is reproducibility, not a claim that your selected framework is the fastest.

SP1's introduction describes proving programs compiled for RISC-V. Follow the installed version's supported workflow, and distinguish actual proof generation from execution-only or mock modes.

Acceptance criteria

• The program produces the expected public result for fixed test cases.
• The proof verifies, and a changed public result fails verification.
• Results state the hardware, toolchain, input sizes, build mode, and proof configuration.
• Execution, witness/proving work, and verification are reported separately where the tooling exposes them.
• The report includes repeated runs, not just the fastest observation.

Use a small table with columns for input size, elapsed time, peak memory, and configuration. Leave cells unmeasured when the tooling does not expose a reliable value. Do not invent a benchmark number to complete the table.

Extension: optimize one bottleneck, rerun the same workload, and show that correctness tests still pass. Report any trade-off, such as lower runtime at the cost of higher memory.

What to discuss: whether initialization is included, how caching affects results, which part of the workload scales poorly, and which results another machine should not be expected to reproduce exactly.

Project 3: a verifier integration with failure states

Brief: connect a supported verifier to a small test application. A command-line interface is enough. If you use a chain, use a local or test environment with no valuable assets.

The Ethereum explanation of zero-knowledge proofs provides background on proving and verification. Your project must go further by stating the exact application claim and identifying the boundaries that are not covered by the proof.

Acceptance criteria

• Valid proofs are accepted only for the expected statement and public inputs.
• Wrong inputs, invalid proofs, and an unexpected verification configuration are rejected.
• A verification failure is distinct from a network or service outage.
• The application never labels a pending or failed verification as successful.
• If an action must happen once, replay tests demonstrate the application's enforcement.

Extension: make the verifier unavailable and document recovery behavior. Show how the application avoids silently accepting an unverified result.

What to discuss: who controls the verification configuration, what upgrades change, and how the interface communicates uncertainty without implying that cryptographic validity guarantees real-world truth.

Package the evidence for a reviewer

Keep the first page of your repository focused: the problem, your contribution, one reproducible example, the test command, and the limitations. Put longer derivations and benchmark detail in separate documents.

Include a short review log when someone identifies an issue: what they found, how you reproduced it, and the test you added. Never fabricate an independent review or security audit. An educational project with honest boundaries is a stronger artifact than an unsupported production-security claim.

When applying, connect one requirement in the vacancy to one piece of evidence in the repository. Avoid claiming that completing these projects guarantees an interview, salary, or job.