What Crypto Audits Can and Cannot Prove: Lessons From the Zcash Bug

Crypto audits can prove some things about a project and leave others unproven, and the space between the two is where most beginner mistakes begin. If you have seen labels like "audited by CertiK," "security audit complete," or "formally verified" and felt unsure how much trust those labels deserve, that uncertainty is the right instinct to follow.

What a crypto audit is, and what it is not

A crypto audit is a structured security review of a blockchain-related system, and the single most important word in that sentence is scope. An audit only covers what the reviewers were asked to look at and were able to look at. At Blockready, crypto evaluation is taught as a mechanism-first skill: understand what a security claim reviewed before you decide how much weight to put on it.

The phrase "crypto audit" is also overloaded. Several different reviews share the name, and they prove different things:

• Smart contract audit: a review of contract code, usually before deployment or after a major change. It looks for vulnerabilities, logic errors, and unsafe patterns in the code that runs on-chain.
• Protocol audit: a deeper review of system logic such as consensus rules, transaction validity, upgrade paths, and how components interact.
• Cryptographic or circuit review: a specialist review of proof systems, signature schemes, and zero-knowledge circuits, where a bug may not look anything like ordinary application code.
• Formal verification: a mathematical method that proves a system meets a written specification under stated assumptions.
• Bug bounty: an open program that pays outside researchers to report flaws responsibly. It extends review beyond one team and one deadline.
• Financial statement or proof-of-reserves audit: an accounting-style review of holdings or balances. This is a different discipline from a security audit and proves something else entirely.

Smart contract and protocol reviews matter most in systems that hold value and are hard to reverse once deployed, which is why they sit at the center of how DeFi protocols rely on smart contracts. When a beginner sees "audited," the first useful question is not "is it safe?" but "which of these reviews happened, and on what?"

What a crypto audit can prove

Used well, audits do real work. A good review can document the scope it covered, the findings it identified, the severity it assigned, and whether specific fixes were made and re-checked. Practitioner sources such as Cyfrin's explanation of a smart contract security audit describe an audit as a time-boxed code review tied to a specific commit, with manual and automated analysis, a findings report, a mitigation stage, and a final report.

Formal verification can go further for the properties it targets. As Ethereum.org's documentation on formal verification explains, it can mathematically prove that code satisfies a formal specification, which is stronger than ordinary testing for those exact properties. The honest summary is narrow on purpose: an audit can raise confidence in a defined system under a defined scope. It does not turn a complex crypto system into a risk-free one.

What a crypto audit cannot prove

Here is the part most "audited" badges quietly skip. Review and testing can find bugs, but they cannot conclusively prove that none remain. An audit is also tied to one version, one date, and one commit, so code changed afterward is unaudited code. If only part of a system was scoped, the rest stays unreviewed: front-end code, admin keys, oracle dependencies, bridges, governance processes, and economic design often sit outside a smart contract audit.

An audit is not an investment endorsement either. A token can pass review and still carry weak tokenomics, insider concentration, governance capture, or legal uncertainty. And no protocol audit protects a user from a fake website, a malicious signature request, or a wallet-draining approval, which is exactly why token approvals still create wallet-drain risk even on code that passed review.

The Zcash Orchard bug: what a fix can and cannot prove

A single 2026 incident captures all of this better than any definition. On May 29, 2026, security researcher Taylor Hornby discovered a critical counterfeiting vulnerability in Zcash's Orchard shielded pool during a review commissioned by Shielded Labs, the nonprofit that funds Zcash development. According to the Zcash Community Forum disclosure by Zooko Wilcox, Jason McGee, and Taylor Hornby, the flaw could have allowed the undetectable creation of unlimited counterfeit ZEC inside Orchard. It came from an under-constrained element of the Orchard circuit, and it had been present since Orchard went live in May 2022.

The response was a model of how to handle a critical flaw. The bug was disclosed privately, an emergency network upgrade temporarily disabled Orchard, a corrected circuit was deployed through the NU6.2 hard fork, and the network was restored within days. The researcher had written a working proof-of-concept exploit using AI-assisted tooling, which is why the review found a flaw that years of prior scrutiny had not.

Now the lesson, and it is not academic. Reading this case well is the difference between trusting a "no exploit detected" statement at face value and knowing what it can and cannot support. The Zcash team reported no evidence the bug was exploited on the live network and no unauthorized value created. But the same disclosure added a caveat that most headlines dropped: because of Orchard's privacy properties, there is no way to prove with cryptography alone whether the flaw was exploited before it was patched. The market reaction was severe, with ZEC falling sharply after the news, as Decrypt reported on the disclosure. Yet the durable lesson has nothing to do with price.

This is not even the first time. In 2019, Electric Coin Company disclosed a counterfeiting vulnerability in an earlier Zcash shielded pool that had gone undetected for years and was fixed through the Sapling upgrade. That earlier flaw was also never known to have been exploited. Two separate cases, years apart, point to the same uncomfortable fact: subtle cryptographic bugs can survive expert review for a long time, and a clean fix does not rewrite the past.

Why "no evidence of exploitation" is not proof

Three phrases get blurred together in security write-ups, and keeping them apart is most of the skill. "No evidence of exploitation" means no one has found a sign of misuse, which depends on what is observable. "Fixed" or "remediated" means the flaw is closed going forward. "Proof that no exploitation happened" is a far stronger claim, and it is often impossible to make, especially in systems designed to hide transaction details.

This is where a common and understandable mistake happens. Someone reads "no exploit detected" or "supply integrity preserved" and hears "proven safe, nothing ever went wrong." That reading feels natural, because in daily life a fixed problem signals the problem is over, and the technical gap between detection and proof stays invisible unless you look for it. Closing that gap before you weigh an "audited" or "patched" claim is the literacy that separates calm evaluation from false confidence. A transparent ledger may let you check a supply anomaly directly. In a privacy-preserving system, the feature that protects users can also limit what anyone can verify after the fact.

Formal verification: stronger, but still scoped

Formal verification deserves its own note because it is the most over-read label in the list. It can prove that a contract or protocol component satisfies a property you have written down precisely, such as "total supply can never exceed this rule" or "this function cannot be called by an unauthorized address." For those exact properties, it is genuinely stronger than testing.

The limit is the specification. A proof is only as complete as the properties it was asked to check and the assumptions it was built on. If the specification leaves out a risk, omits an environmental assumption, or fails to model economic behavior, the proof says nothing about that gap. The accurate phrasing is simple: formal verification proves a system meets a specific specification. It does not prove the specification captured every real-world risk. If a term in a report is unfamiliar, the crypto glossary is a faster way to decode it than guessing.

How to read an audit claim: the AUDIT Check

Instead of asking whether a project is audited, ask what the audit covered and what it left unproven. The following five-part check turns a vague badge into a set of answerable questions. None of them require you to read code.

Reading an audit claim is one branch of a wider research habit. Blockready's Investment module treats due diligence as a structured process covering whitepapers, market context, and risk management, rather than a single check on a single badge. The same instinct applies to project claims more broadly, and a framework for evaluating crypto project claims beyond the audit badge is a natural next step once you can read a security review without overtrusting it.

The Zcash case is one protocol-level story. For the wider pattern across many projects, why audited crypto projects can still get hacked is worth understanding alongside it, because it shows how operational and human-layer failures sit outside most code reviews.

Where audits fit in honest security thinking

Here is the editorial view, stated plainly. Audits are valuable, and dismissing them is as wrong as overtrusting them. The Zcash response showed exactly what good security work looks like: a flaw found, disclosed responsibly, and closed quickly. But the same case showed why "audited," "fixed," and "formally verified" are evidence, not certainty. The right posture is neither cynicism nor blind trust. It is to read each claim for what it covers, when it applied, and what it leaves open.

So Blockready does not recommend treating an audit badge as a reason to skip your own evaluation. A badge is an invitation to ask better questions, not a substitute for asking them. The reader who gets value from an audit reads the scope, checks the date, separates findings from fixes, and remembers that one review is a single layer in a system that also depends on operations, governance, and the user's own habits. That habit, not the badge, is what actually lowers risk.

Frequently Asked Questions