Zero-knowledge systems are not a guarantee: why verified execution can still be incorrect
Zero-knowledge systems prove constraint compliance, not real-world correctness; we examine the gap between verified execution and true mathematical security.
Zero-knowledge systems have become a cornerstone claim in modern cryptography and blockchain engineering, held up as embodiments of mathematical security. Yet that label can be misleading: proving that a prover satisfies an encoded constraint system does not by itself prove that the encoded system captures the full, intended semantics of an application. When teams conflate verified execution with correct execution they create a gap between what is mathematically proven and what actually matters in production, and that gap has material consequences for developers, auditors, and anyone who relies on these systems for financial or critical workflows.
Distinguishing verification from correctness
At the component level, verification means demonstrating that an implementation or circuit satisfies a formal property or set of constraints. Correctness, by contrast, is an assertion about intended behavior: that the system’s observable outcomes match the designer’s specification and the expectations of its users across all relevant states and inputs. The two overlap when the formal model fully and faithfully represents the intended semantics, but they diverge when the model is partial, ambiguous, or omits external assumptions.
Zero-knowledge proof systems excel at the former: they establish that a statement—expressed as arithmetic circuits, rank-1 constraint systems, or other formal encodings—holds for a hidden witness without revealing the witness itself. That is a powerful cryptographic primitive. However, it is only as powerful as the model it protects. If the constraint system does not capture a particular business rule, an off-chain dependency, or an edge-case transition, a valid proof can still assert an outcome that is inconsistent with the broader system semantics.
How zero-knowledge proofs and constraint languages operate
Zero-knowledge frameworks transform computations into a language of constraints that can be efficiently checked by a verifier. Typical steps include expressing the computation as a set of arithmetic relations, compiling those into circuits, and generating a proof that a private witness satisfies those relations. Verifiers then accept or reject proofs based on the encoded relations, and the cryptographic guarantees ensure soundness, completeness, and zero-knowledge under specified assumptions.
This pipeline produces strong local guarantees: a verifier will not accept an incorrect witness with high probability, and a prover cannot easily forge proofs about statements that violate the encoded constraints. But the pipeline presumes that the constraints are the authoritative expression of the system’s semantics. If they are not—because of incomplete modeling, mismatched types between implementation and constraints, or implicit external assumptions—the proof system is doing exactly what it should: confirming compliance with the encoded rules, not validating that those rules reflect real-world requirements.
Semantic entropy and the proliferation of unintended states
One way to think about the discrepancy is semantic entropy: the existence of multiple internal states or execution witnesses that map to identical public outputs but differ in ways that matter later. When intermediate variables are unconstrained, when rollback or exception paths are modeled only partially, or when the implementation uses types and behaviors that do not translate cleanly into the constraint language, the system gains degrees of freedom. Each additional degree of freedom increases the set of valid internal states—many of which will never have been evaluated for safety.
These benign-seeming multiplicities are dangerous because they expand the state space beyond what designers and auditors have reasoned about. A proof that a certain postcondition holds does not exclude hidden divergences that change future behavior. Over time, as the system interacts with other components, or as incentives and attacker strategies evolve, those unexamined states can interact in unexpected ways, producing emergent failures that are very difficult to detect with conventional testing or pen tests.
When “no funds lost” becomes a misleading safety signal
Many projects use the absence of observed losses or exploits as an informal safety metric. While a clean incident history is worth noting, it is not equivalent to a proof of correctness. Empirical resilience—hardening through audits, fuzzing, bug bounties, and real-world operation—tends to reduce local fragility, but it cannot substitute for guarantees about parts of the state space that were never specified.
The problem is especially acute in environments that combine off-chain systems, oracles, and stateful smart contracts with cryptographic proofs. If a proof verifies a transition under certain assumptions about oracle data or timing, but those assumptions are not enforced in the model, then “no loss” might simply mean that the particular adversarial scenario has not yet occurred or been discovered. Reliance on such a metric risks complacency and misaligned incentives between builders and users.
Common technical pathways to incorrect yet verified behavior
Several recurring technical patterns produce systems that are provably consistent but not correct with respect to intent:
-
Unconstrained witnesses: Intermediate or auxiliary values used during proving may remain under-specified, allowing a prover to choose any value that satisfies the final observable conditions without upholding intended invariants.
-
Incomplete modeling of state transitions: Systems that do not formalize full lifecycle behaviors—such as rollbacks, retries, or error handling—leave room for proofs that accept illegal transitions as valid.
-
Type and semantics mismatch: High-level languages and runtime behaviors (e.g., integer overflows, floating point differences, or signed/unsigned distinctions) can diverge from the assumptions made when compiling into constraint systems, producing discrepancies that proofs do not catch.
-
Implicit external dependencies: If constraints assume an external property (like monotonic oracle timestamps or unique identifiers from a ledger) but the system does not enforce them end-to-end, proofs can validate outcomes under those assumptions while real-world operations violate them.
- Non-unique witnesses: When multiple witnesses lead to the same public output, the verifier cannot distinguish which internal path occurred, yet those paths may have consequences for future state or access privileges.
Recognizing these patterns helps teams focus formalization where it matters.
Engineering practices to shrink the gap between proof and intent
Bridging the distance between verified execution and correct execution is a practical engineering challenge. It requires more than formal proofs on isolated modules; it requires disciplined system design, documentation, and verification strategies that surface and limit semantic entropy.
-
Explicit state models: Capture the state machine of the application in a machine-readable, versioned specification that includes expected invariants, transition preconditions, and edge-case behavior.
-
Formalize trust boundaries: Record which components are trusted, under which assumptions, and what guarantees they provide. Embed those assumptions in the verification model rather than leaving them implicit.
-
Prove global invariants where feasible: Move beyond per-circuit proofs to properties that span components—e.g., conservation of assets, impossibility of double-spending, or monotonicity of certain counters.
-
Tighten witnesses: Reduce degrees of freedom in witness construction by adding constraints that codify intended semantics for intermediate values, not just final outputs.
-
Model external interactions: Where proofs rely on external data, use formal adapters that capture oracle semantics and failure modes, and reason about adversarial manipulations of those inputs.
-
Continuous verification in CI: Integrate constraint-generation, prover runs, and property checks into continuous integration and deployment pipelines to ensure models track implementation changes.
-
Property-based and differential testing: Use fuzzing and property-driven tests to probe unexpected state combinations and compare behavior across implementations and constraint encodings.
- Transparent documentation for users and auditors: Publish precise descriptions of what has been proven, what is assumed, and what remains unformalized. Clear documentation aligns incentives and informs users of residual risk.
These practices are not magic—they raise engineering effort—but they convert ambiguous assertions into concrete artifacts that can be audited, discussed, and iterated.
Economic and organizational incentives that encourage the simulation of certainty
Technical gaps often persist because incentives favor shipping and signaling over exhaustive formalization. Fundraising, market adoption, and customer confidence reward visible indicators—audits, proof-of-concept demos, performance metrics—rather than the slow work of global formal modeling. Audits and bounty programs create meaningful safety value, but they are evidence of responsive hardening, not proof of absence of conceptual gaps.
Project teams and their investors can accelerate a product roadmap by claiming “formal guarantees” even when those guarantees apply only to limited models. That claim benefits marketing and short-term adoption, but it externalizes the longer-term risk to users who may lack the expertise to parse the nuance. Correcting this misalignment means changing what stakeholders reward: insistence on transparent formal models, incentivized verification of cross-component invariants, and product-level documentation of assumptions.
Who needs to care and how these issues affect different audiences
-
Developers and protocol designers: They must internalize the difference between encoding constraints and encoding intent. For designers, this means treating constraints as a specification language and auditing for semantic coverage rather than only circuit efficiency.
-
Auditors and security teams: Auditors should expand their scope from checking cryptographic soundness to assessing model completeness, external assumptions, and witness entropy. Security assessments should include scenario modeling that explores unformalized regions of state space.
-
Businesses and product managers: When a financial product uses cryptographic proofs, the product team must translate formal guarantees into contractual and operational obligations that users and counterparties can rely on.
-
Regulators and compliance officers: Regulators evaluating risk profiles of cryptographic products should request explicit statements of assumptions and boundaries of formal guarantees to avoid being misled by surface claims.
- End users and custodians: Non-technical stakeholders deserve clear disclosures about what a proof covers and what it omits, especially when funds or legal rights are involved.
Interactions with broader software ecosystems and adjacent technologies
The problem of partial formalization is not isolated to zero-knowledge tech. It intersects with developer tools, CI/CD systems, observability stacks, security software, and even AI-driven code generation. For example, automation tools that generate constraint code or translate high-level logic into circuits must themselves be verified or tightly specified, because mistakes in those generators can inject semantic gaps at scale. Similarly, integrating proofs into product stacks—wallets, exchanges, middleware—creates boundary points where assumptions can leak.
AI tools that suggest code or documentation can help surface implicit assumptions, but they can also propagate misunderstandings unless they are trained or prompted with precise specifications. Developer tooling that supports model-aware debugging, property-driven test generation, and versioned constraint artifacts can materially reduce the risk of divergence between implementation and model.
Natural internal link phrases that teams could use to guide readers to related material include formal verification, constraint systems, protocol design, property-based testing, and oracle security.
What successful mitigation looks like in practice
A project that genuinely narrows the gap will combine clear artifacts and engineering practices:
-
A published state model that maps contract storage, off-chain data, and lifecycle events.
-
A formal statement of invariants and threat models that auditors can test against.
-
Constraint encodings that explicitly reference and enforce those invariants, including constraints on intermediate witnesses.
-
Automated checks in CI that prevent mismatches between code and constraint-generation logic.
-
Monitoring and on-chain detectors that flag anomalous internal-state patterns that the proof system cannot distinguish.
- Transparent changelogs that record when model assumptions change and the migration steps needed to maintain proven properties.
These elements create a defensible posture: proofs remain valuable, but they sit within a deliberately reduced and audited surface for ambiguous behavior.
Broader implications for the software industry and cryptographic engineering
The distinction between verified and correct execution has ramifications beyond individual projects. For the industry, it highlights the need to elevate modeling discipline and to develop standards for expressing the scope of formal guarantees. For developers, it means adopting greater rigor in how requirements translate into constraint encodings and proof artifacts. Businesses must rethink how they represent risk when marketing cryptographic assurances, and auditors need new methodologies that combine cryptographic checks with system-level modeling.
As cryptographic tooling matures, there is also an opportunity to build higher-level languages and frameworks that reduce the likelihood of semantic gaps—languages that preserve type and behavior semantics through compilation into constraints, or that make assumptions explicit at compile time. Investment in such developer tools will pay dividends by making proofs more tightly coupled to intent and by lowering the cognitive burden on engineers.
Standards, documentation, and the ethics of representation
When a system operates with financial consequences, ethical obligations emerge. Public-facing claims of “security by construction” should be accompanied by accessible explanations of what is proven, what is assumed, and what remains unformalized. Standards bodies and industry consortia can accelerate this by defining minimal disclosure requirements for projects that advertise formal guarantees, including model artifacts, invariant lists, and the provenance of external trust assumptions.
Transparent disclosures reduce information asymmetry and give auditors, researchers, and users the context needed to evaluate residual risk. That transparency is not merely bureaucratic—it is an engineering lever that incentivizes teams to formalize the right things.
A continuing path toward more honest cryptographic engineering
The engineering community does not need perfect formalization for every system overnight. What is needed is a cultural and technical shift toward clear modeling, disciplined boundaries, and meaningful disclosure. Zero-knowledge systems and other cryptographic primitives are powerful tools, but their value depends on accurate mappings between formal models and operational semantics. By tightening that mapping—through better tools, more rigorous specifications, and aligned incentives—developers can preserve the practical benefits of proofs while reducing the systemic risk that arises from unexamined state.
Looking ahead, we can expect several parallel developments that will influence how the industry approaches this problem: improved languages and compilers that maintain semantics across the translation into constraint form; richer CI tooling that integrates proof generation and property checks; standardized disclosure formats for formal guarantees and their assumptions; and greater collaboration between security researchers, auditors, and protocol teams to stress-test models rather than just implementations. Together, these advances will make mathematical security a more reliable guide to real-world correctness rather than a rhetorical badge.
