Abstract
There is a persistent assumption in adversarial security work that sufficiently deep analysis will always uncover a critical flaw. In practice, this is false. This article documents a full-scope, invariant-driven audit of a modern cryptographic protocol combining zero-knowledge proofs, distributed execution, and commitment-based state. The result was not a high-severity vulnerability, but something arguably more valuable: a system that resisted structured attempts to produce a “valid proof of an invalid reality.” The goal here is not to celebrate robustness blindly, but to analyze what prevented failure and where pressure should be applied next.
The Wrong Mental Model of Auditing
A surprising number of audits are still conducted as pattern-matching exercises. People look for known bug classes, run fuzzers, skim code, and hope something breaks. This works on immature systems.
It does not work on systems that are explicitly designed around layered correctness:
- off-chain execution
- cryptographic validation
- on-chain enforcement
At that point, bugs do not live in functions. They live in inconsistencies between models.
The correct adversarial question is not:
“Can this function be exploited?”
It is:
“Can the system accept a state that is locally valid but globally invalid?”
If the answer is yes, you have a real vulnerability. If the answer is no, you are dealing with something that was at least partially engineered with invariants in mind.
The Target: A Multi-Layer Cryptographic System
The system under analysis had three distinct layers of truth:
- a private execution layer producing results
- a zero-knowledge layer proving validity of transitions
- an on-chain verifier enforcing those proofs
State was represented as commitments, transitions were proven, and settlement was executed under contract-level constraints.
At a glance, this architecture appears robust. In reality, it introduces a new class of failure modes:
each layer can be internally correct while the composition is wrong.
This is where meaningful vulnerabilities tend to exist.
The Audit Strategy: Invariants First, Code Second
Instead of starting from code, the audit started from invariants.
Three categories were defined:
Arithmetic invariants
No inflation, no rounding-based value creation, no divergence between representations.State invariants
Single-use nullifiers, consistent Merkle inclusion, valid transitions between states.Cross-layer invariants
The most critical class:
- execution result == proof input
- proof output == contract state
- contract state == economic reality
The entire audit reduces to one objective:
find a transition that satisfies all local constraints but violates at least one global invariant.
Where We Tried to Break It
Several attack surfaces were explored in depth.
Fixed-Point Arithmetic Across Layers
Arithmetic is often the weakest link in multi-layer systems. Here, the same operation was implemented:
- natively
- inside zero-knowledge constraints
- inside distributed execution
The expectation was divergence. Instead, all layers implemented the same semantics:
floor(x) = x >> precision
With constraints enforcing the remainder range, the result was uniquely determined. No alternate witness existed, and no rounding drift could be amplified into a meaningful exploit.
This is rare. It means someone actually aligned representations instead of hoping they matched.
Constraint Soundness
Zero-knowledge systems often fail through underconstrained gadgets.
A typical failure pattern is:
- multiple valid witnesses satisfy the same constraint
- the prover chooses the one that benefits them
The floor constraint was analyzed formally and reduced to:
0 ≤ repr - 2^M * integer < 2^M
Which uniquely defines the integer as the floor.
No ambiguity. No slack. No exploit.
Circuit–Contract Boundary
This was the most promising area.
The circuit intentionally delegated certain checks to the contract:
- bit length constraints
- ordering constraints
- fee computation
- execution bounds
This creates a trust boundary. If the contract diverges from the circuit’s assumptions, the system breaks.
However, the design used conservative validation:
- circuits validated worst-case outputs
- contracts recomputed actual values deterministically
This asymmetry is important. It means:
the system checks more than it needs to before settlement, not less.
That direction matters. One direction is exploitable. The other is not.
Rounding and Price Inversion
Rounding errors often create silent value leakage.
The system used:
- floor operations for outputs
- integer-based inversion for reciprocal pricing
This introduces bounded rounding loss.
The key observation was that rounding always favored safety:
- outputs were rounded down
- inputs were rounded up when needed
No direction allowed value creation. Only bounded loss.
Loss is acceptable. Creation is not.
The Result: No Critical Path Found
After full analysis, no scenario satisfied all of the following:
- reachable through real execution
- accepted by the proof system
- accepted by the contract
- violating economic or state invariants
This is an important distinction.
It does not mean the system is perfect.
It means the first-order invariant surface is intact.
Why This Matters
Security discussions often focus on exploits found.
There is value in understanding why exploits were not found.
In this case, three design decisions stood out:
Consistent arithmetic semantics across layers
No hidden conversions, no implicit scaling mismatches.Conservative validation strategy
Circuits validate upper bounds, contracts compute exact values.Explicit trust boundaries
Responsibilities are separated and documented, not mixed implicitly.
These reduce the space where contradictions can emerge.
Where the System Should Still Be Pressured
A system that resists first-order attacks still has deeper surfaces.
The next phase of analysis should focus on:
- proof composition and linking correctness
- ordering and dependency between multiple proofs
- contract-side enforcement of delegated constraints
- adversarial execution with boundary values and extreme inputs
The question evolves from:
“Can a single transition break invariants?”
to:
“Can a sequence of valid transitions produce an invalid state?”
That is where most mature systems eventually fail.
Final Thought
There is a quiet misconception in this field that not finding a vulnerability means the audit failed.
The opposite is often true.
If you can:
- define invariants precisely
- attempt to violate them systematically
- and fail under realistic constraints
you have learned something far more useful than a one-off exploit.
You have identified a system that, at least for now, does not contradict itself.
And in distributed cryptographic systems, that is a higher bar than most ever reach.
Top comments (0)