ZK Engineer / Cryptography Researcher
One page with two distinct tracks: ZK Engineers implement proving systems, circuits, compilers, and integrations; Cryptography Researchers develop or analyse primitives, proof systems, assumptions, and formal security arguments.
New to this area? Learn the foundations before building proof.
Also listed as
ZK Engineer · Zero-Knowledge Engineer · Cryptography Researcher · Applied Cryptographer
What this role actually does
This is hands-on work. The role may need to implement or analyse proofs, read papers and code, run benchmarks, and review assumptions.
The boundary matters: it owns proof-system implementation or research, circuits and constraints, and performance and correctness, not generic smart contract development and security guarantees without peer review.
Where the role sits
ZK Engineer / Cryptography Researcher usually sits inside Engineering, Protocol, Security, Infrastructure, or Developer Experience teams. Common reporting lines include Engineering Manager, Protocol Lead, Security Lead, Infrastructure Lead, or Head of Developer Experience. Core-team employment is common for production ownership. Audits, specialist research, DevRel, and infrastructure work also appear through consultancies, grants, contractors, and open-source contribution. The role usually collaborates with Protocol Engineer, Smart Contract Auditor, Protocol Researcher, Smart Contract Developer.
Core responsibilities
- For the ZK Engineer track: implement circuits, provers, verifiers, compilers, tooling, benchmarks, and integrations
- For the Cryptography Researcher track: study primitives, proof systems, security models, reductions, assumptions, and new constructions
- Write tests, formal or semi-formal arguments, benchmark methodology, and design notes
- Review soundness, completeness, trusted setup, recursion, hardware, and performance trade-offs
- Collaborate with protocol, systems, security, and academic teams
- Publish or communicate limitations clearly
Daily, weekly, and reactive work
A typical day
Implement or analyse proofs, read papers and code, run benchmarks, and review assumptions.
Weekly or monthly
Discuss designs, reproduce results, improve tooling or arguments, and document trade-offs.
When conditions change
Respond to soundness concerns, benchmark discrepancies, setup compromise, implementation bugs, or a new result that changes the security assumption.
Deliverables
How success is judged
- Correctness
- Reproducibility
- Performance with honest methodology
- Clear assumptions
- Peer review quality
- Usable implementation or novel research value
Read signals in context. Read correctness together with reproducibility. Neither signal is meaningful without the relevant launch, incident, market, workload, or attribution context.
Tools in practice
- Rust, C++, Python, or relevant languages
- Collect and analyse the evidence used in circuit or proof-system implementation and benchmark suite, with definitions and reproducible steps.
- proof-system frameworks
- Implement circuits, proving and verification flows, recursion, and integration tests in the selected proof system.
- formal tools
- Check selected algebraic, logical, or security properties and document the limits of the verification.
- GitHub
- Review source, manage branches and pull requests, run tests, and leave implementation or security decisions in a traceable history.
- paper and benchmark tooling
- Reproduce published results, record hardware and parameter assumptions, and compare performance with a transparent methodology.
- specialized hardware where relevant
- Benchmark proving workloads on GPUs, FPGAs, or other accelerators when hardware materially affects cost or latency.
Skills and prerequisite knowledge
Hard skills
- ZK engineering or advanced cryptography
- Algorithms
- Linear algebra and probability
- Systems programming
- Research communication
Working skills
- Technical communication
- Careful review
- Incident composure
- Collaboration through written artifacts
- Ownership without hiding uncertainty
Prerequisite knowledge
Shared foundation: strong mathematics, computer science, cryptography basics, and proof-system literacy. ZK engineering hiring weighs implementation, performance, and systems work more heavily. Cryptography research hiring often expects deeper formal background, publications, or research experience.
Expectations by level
Entry level
At entry level, a candidate should be able to complete a scoped assignment with review. That includes the ability to for the ZK Engineer track: implement circuits, provers, verifiers, compilers, tooling, benchmarks, and integrations, to for the Cryptography Researcher track: study primitives, proof systems, security models, reductions, assumptions, and new constructions, and to produce reviewable artifacts such as a circuit or proof-system implementation and a benchmark suite.
Mid level
At mid level, the practitioner normally owns proof-system implementation or research, circuits and constraints, and performance and correctness without constant supervision. They can coordinate adjacent teams and improve the workflow behind a circuit or proof-system implementation and a benchmark suite, including when the role must respond to soundness concerns, benchmark discrepancies, setup compromise, implementation bugs, or a new result that changes the security assumption.
Senior
At senior level, the work shifts toward standards, decision rights, and review quality. A senior ZK Engineer / Cryptography Researcher defines how proof-system implementation or research, circuits and constraints, and performance and correctness are handled, reviews high-risk cases, and builds systems that do not depend on one person.
Proof of work and portfolio
Reviewers should be able to inspect a circuit or proof-system implementation and a benchmark suite, trace the inputs or decisions behind the work, and understand what the candidate personally owned.
Strong proof
- A small circuit and benchmark
- An implementation contribution
- A paper reproduction
- A research note explaining assumptions and trade-offs
Weak evidence
- A tutorial copied without understanding
- Benchmark claims with no hardware or method
- Using 'cryptographer' for routine integration work
Common mistakes and misconceptions
- Taking responsibility for generic smart contract development and security guarantees without peer review without the mandate or approval to do so
Common misconception
ZK Engineer / Cryptography Researcher may overlap with Protocol Engineer, but the hiring evidence is different. This role is judged on proof-system implementation or research, circuits and constraints, and performance and correctness, not on ownership of generic smart contract development and security guarantees without peer review.
Scope boundaries
Usually owns
- Proof-system implementation or research
- Circuits and constraints
- Performance and correctness
- Cryptographic assumptions
- Technical documentation and review
Usually does not own
- Generic smart contract development
- Security guarantees without peer review
- Product marketing
- All protocol engineering
- Treating the two tracks as interchangeable
Interview focus
Expect questions about ZK engineering or advanced cryptography, algorithms, and linear algebra and probability, plus a scenario where the role must respond to soundness concerns, benchmark discrepancies, setup compromise, implementation bugs, or a new result that changes the security assumption. Interviewers are looking for evidence that the candidate knows where proof-system implementation or research and circuits and constraints stop and generic smart contract development and security guarantees without peer review begin.
Where do ZK engineering and cryptography research overlap, and where do they require different evidence?
What does a proof establish, and what does it not establish about the surrounding system?
How would you evaluate a performance claim across proving systems?
Compensation and role risks
Published samples are small and highly specialist. Listing examples may be shown as examples, not a market range. Confidence remains low; academic, research, startup, and systems-engineering compensation differ substantially.
No reliable role-specific range
KRAFT did not find a reliable role-specific range that meets the evidence standard. Compensation may still exist through salary, contract fees, retainers, grants, commissions, token or equity packages, creator revenue, or business economics. These models are described separately rather than compressed into an invented number.
Wider Web3 market, for scale
Typical advertised averages $65,000 – $200,000 / year
Individual postings run from about $40,000 to $350,000.
Across the role categories this index tracks, advertised averages sit between roughly $65,000 and $200,000 per year, with individual postings from about $40,000 to $350,000. This is whole-market scale from advertised roles - not a figure for this specific role, and not verified paid compensation.
Role risks
- Small and noisy hiring market
- Deep specialization
- Incorrect assumptions with large downstream impact
- Benchmark theatre
- Rapidly changing systems
Compensation can change materially by geography, seniority, employment model, company stage, market cycle, and the mix of cash, bonus, commission, equity, token, vesting, royalties, or fees. A published range is useful only when those dimensions match the role being considered.
How to read compensation evidence
- Direct
- Evidence from the same or a materially equivalent role.
- Adjacent
- Evidence from a neighbouring occupation, used only for context.
- Broad market
- Category-level Web3 or labour-market evidence.
- Unverified
- Estimates without enough source or methodology detail.
Confidence reflects the quality and comparability of the evidence, not the value or legitimacy of the role.
Career path and role fit
Common progression
May fit people who
People with strong mathematical or systems foundations who enjoy difficult correctness questions and long feedback cycles.
May not fit people who
People seeking an entry-level shortcut based only on using a ZK framework.
Practical next steps
How this guide is built. Role content is drawn from current first-party hiring material and reputable industry evidence, with compensation labelled by confidence and evidence tier rather than a single number.
Turn this role into evidence.
Choose a proof-of-work project, package the result, and practice the questions this role is likely to ask.