Zcash was discovered to have a bug where it can be infinitely issued for four years, causing the token to plummet by 30%. What's even more frightening about this matter is that the bug was discovered independently by researchers using Opus 4.8 automated auditing. The author has an agent framework called zcash full stack auditor. On May 28th (the day Opus 4.8 was released), he initiated an automated audit of the implementation of halo2 (Zcash's zero knowledge proof base), covering Orchard circuits. The framework first runs an "initialization phase" to enumerate all relevant code locations, specification terms, security properties, and failure modes. At around 2pm on May 29th, after initialization was completed, he launched the "audit phase" - the framework assigned the corresponding type of audit agent to each item in the list. This time, he ran Opus 4.8 and adjusted it to max effort. At around 6pm that day, an auditing agent reported a serious vulnerability in the Orchard circuit, claiming that it could double suspend Orchard notes. The author only noticed this discovery later that night and gradually verified, reported, and conducted PoC: He first asked Claude to write the first PoC for a simplified circuit similar to "diversified address integrity", confirming that the vulnerability had a high probability of being true. That night at 11:53, he reported it to Daira Emma Hopwood and Kris Nuttycombe through Signal. 2. Claude was asked to write a second PoC for the real Orchard circuit, demonstrating "revealing multiple different nullifiers for the same note" to achieve double spending. It was delivered at 2:06 am on Saturday and it was suggested to urgently stop Orchard. 3. Finally, an RPC test was developed to double the value of an Orchard note until the balance in the regtest wallet exceeded 10 million ZEC, proving that the issuance attack could indeed be exploited (regtest used the same rules and zero knowledge proof verification as the main network, and the transaction was not broadcasted to the test network or main network). It is worth noting that regarding the "discoverability" section: the author previously used the same framework but ran Opus 4.7 xhigh and did not find this bug; Later it was confirmed that 4.7 can only be found when it is very specifically guided. Even with 4.8, when using more generalized prompts, it only hits once out of four tests. One possible difference is that this time he fed the halo2 book into the initialization phase (previously only feeding protocol specifications and ZIP). The vulnerability has been present for over 4 years since Orchard went live, and even in-depth manual audits conducted before its launch did not detect it - indicating that it is quite difficult to find for humans. What role does Opus 4.8 play It is essentially the core of the entire chain, deeply involved from discovery to verification: Self discovery: The audit agent running under max effort identified this serious vulnerability on its own, which was the starting point of the entire event. Independent derivation of mathematics: The vulnerability lies in the fact that the circuit does not impose constraints on the base of scalar multiplication, allowing attackers to arbitrarily select this base. Given the target values of pk-d, d_d, and ivk, it is necessary to deduce what value the base should be set to in order for [ivk] d_d to be equal to pk-d. The report clearly states that this step of algebra was calculated entirely by Opus 4.8 himself, without any hint from the author, and that without AI, it would take a long time. Write PoC and RPC tests: Both PoC and the final issuance test were written by Claude. The development of RPC testing took about 6 hours, during which Opus 4.8 hardly required manual guidance. The author only provided two tips (how to handle the reordering of action bundles and multiple passes when the prover generates proofs). Auxiliary analysis and mitigation: The author also asked Claude to conduct a statistical analysis of on chain transactions within the vulnerability exposure window to see if there were any signs of actual exploitation (the conclusion is uncertain because blocking transactions themselves has high variance); In the long-term mitigation suggestion, AI was also used to run a check on whether it is possible to change the value of a certain assign_device to something else without violating any constraints. An interesting behavioral detail: The report states that Opus 4.8 is extremely skeptical about whether the vulnerabilities it has found are true - it tends to believe that the upstream code has been audited and should be correct, or that it is looking at a version deliberately implanted with backdoors, and the author needs to "push" to take this discovery seriously.