CRYPTOGRAPHY REVIEWS
Review the cryptography the rest of the system treats as settled.
Manual review of zero-knowledge circuits, custom primitives, signature and threshold schemes, privacy-preserving protocols, and post-quantum designs. We separate what the paper claims from what the circuit, protocol, and implementation actually guarantee.
Review surface
A proof is only as strong as the assumption beneath it.
We review the claim, the construction, and the code. A correct paper does not make a correct circuit, and a correct circuit does not make a safe implementation.
-
01 ZK circuits & proof systems Constraints, completeness, soundness, trusted setup, witnesses, and the gap between the intended statement and what is actually proven. -
02 Custom primitives New constructions, modified standards, parameter choices, and whether the claimed security reduction still holds. -
03 Signatures, threshold & MPC Signature schemes, aggregation, threshold signing, multiparty computation, nonce handling, and key generation. -
04 Privacy-preserving protocols Confidential transactions, anonymous credentials, zkTLS, private computation, and what still leaks under a realistic adversary. -
05 Post-quantum cryptography Scheme selection, parameter sets, hybrid migrations, and implementation of lattice, hash-based, and other quantum-resistant primitives. -
06 Implementation & composition Constant-time behaviour, side channels, API misuse, randomness, domain separation, and unsafe composition of otherwise sound parts.
Timing
When to schedule a review
Before the primitive ships
A new construction, circuit, or protocol is about to be treated as a building block.
Before a privacy feature goes live
Users, counterparties, or regulators will rely on a confidentiality or unlinkability claim.
Before a PQC or scheme migration
The algorithm, parameters, or hybrid transition changes what every caller is trusting.
When primitives are composed
Standard parts are being combined in a new way, and the composition has not been reviewed.
Process
From the claimed guarantee to what actually holds.
- 01
Pin the claim
Write down the properties the system needs: confidentiality, integrity, unforgeability, soundness, privacy, or post-quantum resistance.
- 02
Separate paper, protocol, and code
Identify what is proven, what is assumed, what is inherited from a standard, and what exists only in the implementation.
- 03
Attack the assumptions and the joins
Challenge soundness, parameter choices, composition, leakage, and the ways an implementation can fail a correct design.
- 04
Report and verify
Document what holds, what does not, and the practical remediation. Verify agreed in-scope fixes.
Outputs / What you receive
Clear findings, practical fixes, and a report your team can use.
Assumption map
What is proven, what is assumed, and which guarantees the rest of the system is inheriting.
Prioritized findings
Breaks in the primitive, circuit, protocol, or implementation, with impact and remediation.
Failure scenarios
How a weakened assumption, leaked witness, or implementation flaw becomes a practical break.
Technical report
Scope, methodology, findings, limitations, and final status.
Typical engagement team
Who typically leads this work
The exact team depends on the scope. Every engagement has a principal who owns it from scoping through delivery, joined by the specialists the system calls for, and whoever is assigned is named in your proposal.
Timur Güvenkaya
Founder & Partner
Led a security engineering practice for Rust and non-EVM systems across Substrate and NEAR. Earlier, built vulnerability-detection engines at Invicti used by Fortune 50 and public-sector organizations.
Manuel B. Santos
Specialist Advisor
Cryptography engineer with a Ph.D. in Information Security and 13 published research articles. Worked on post-quantum cryptography at Tectonic and on MPC and zkTLS at Nillion, where he contributed to Nada and wrote technical reports on threshold ECDSA.
FAQ
Questions before scoping
How is this different from a smart contract or protocol review?
Those reviews ask whether the application or the chain behaves as intended. This one asks whether the cryptography those systems rely on actually provides the guarantee they assume. The two often run together: a circuit review next to the contracts that call it, or a signature-scheme review next to the custody path that uses it.
Do you review ZK circuits and proof systems?
Yes. Scope can include the statement being proven, circuit constraints, completeness and soundness, trusted setup or transparency assumptions, witness handling, and the prover, verifier, and recursor implementations around them.
Can you review a custom or unpublished primitive?
Yes. That is often the highest-value case. We examine the construction against the claimed reduction, the parameter choices, and the ways a small change to a standard primitive can void the original proof.
Do you cover post-quantum cryptography?
Yes. Reviews can cover scheme selection, parameter sets, hybrid classical-plus-PQC deployments, and the implementation of lattice, hash-based, and other quantum-resistant primitives.
Do you prove the math, or review the implementation?
Both, to the depth the scope needs. Some engagements are a design review of the construction and its assumptions. Others are an implementation review of circuits, protocols, and production code. Most are some of each, because that is where the breaks usually sit.
Related services
Blockchain & Infrastructure ReviewsReview custom chains, runtimes, nodes, consensus, and bridges beneath the application layer.Smart Contract ReviewsFind flaws in contract logic, permissions, accounting, and upgrades before they put funds at risk.Signing & Custody ReviewsReview how keys are generated, approved, used, and recovered across MPC, HSM, multisig, and custody platforms.
Next step
Put the claim, the circuit, and the code in the same review.
Share the specification, implementation, threat model, and the guarantee you need to defend. We will propose a focused cryptography review.
Discuss your scope