In the world of blockchain and cryptography, zero-knowledge proofs (ZK, Zero-Knowledge Proofs) have always been regarded as the 'crown jewel'.
It is widely believed that ZK technology is too advanced and the mathematical formulas are too complex for hackers to understand, making it extremely secure. As a result, over the past few years, smart contracts have been treated as 'ATMs' by hackers, while the ZK field has remained stable and has never reported any attack news.
However, those who frequently walk by the river will inevitably get their shoes wet.
Not long ago, a major earthquake occurred in the ZK community—two projects using ZK technology were hacked, one losing 5 Ethereum, and another with a funding pool of up to 1.5 million dollars was nearly drained! (Fortunately, the latter was intercepted by white hat hackers who saved the funds).
Do you think hackers used some extremely advanced mathematical genius methods to crack ZK?
Wrong! The reason is shocking: it’s simply because the programmer was careless and omitted a fundamental step during project deployment, leaving a 'master key' for hackers!
Today, let's see how this so-called 'epic blunder' attack happened!
🧐 1. What is ZK's 'Trusted Setup'?
The two problematic projects both used a mainstream ZK technology called Groth16.
In this technology, if you want the system to operate normally, you must first perform an extremely important ritual called **'Trusted Setup'**.
💡 Simple explanation time:
What is 'Trusted Setup'?
Imagine you want to create a super safe that no one in the world can open. In the blueprints of this safe, there is a set of extremely confidential parameters (known as toxic waste in cryptography).
To prevent the craftsmen who build the safes from pocketing this set of parameters (essentially keeping a master key), the craftsmen invented a two-step process:
Step One (Create the Lock Core): Find thousands of people from all over the world who do not know each other, and each person adds a bit of random metal waste (providing random numbers) to the lock core. As long as one person in these thousands does not secretly record the waste they added, the underlying password of this lock will be impossible to guess.
Step Two (Configure the Dedicated Key): For your specific project (for example, your front door), find a few more people to inject specific parameters into it. This step is extremely critical; it will scramble the two originally identical 'springs' (mathematically called $\gamma$ and $\delta$ parameters) into completely different shapes.
As long as these two steps are completed and all traces of the participants are erased, this safe (ZK system) will be indestructible.
🤦♂️ 2. Incredible blunder: The programmer forgot to take the 'second step'.
The problem lies in that damned 'second step'.
In the two problematic projects (Foom Lottery and Veil Privacy Pool), programmers, while using the development tool (snarkjs), may have skipped the 'second step' because they found it troublesome or simply did not understand the logic behind it!
That is to say, as mentioned above, they did not scramble those two identical 'springs ($\gamma$ and $\delta$ parameters)!
What catastrophic consequences could this lead to?
In the mathematical formula of Groth16 technology, the system performs very complex cross-comparisons when verifying a proof (that is, checking if you have the password). The role of those two 'springs' is to constrain each other.
Because the programmer was lazy and skipped the second step, the values of $\gamma$ and $\delta$ remained completely consistent with the factory defaults!
In the eyes of hackers, this is simply paradise!
After the hackers discovered that these two parameters were the same, they directly constructed a 'negative number' in the mathematical formula using the principle of 'positive and negative cancellation' from elementary school mathematics.
As a result, the complicated verification formula surprisingly turned into '1 = 1' after a series of 'addition and subtraction cancellations'!
What does this mean?
This means that hackers do not need to provide any passwords, do not need to prove they have money, do not need any legitimate certificates, as long as they submit a shell application, the system's security guard will see that the formula is '1=1', and directly allow it, handing over all the money in the safe to the hackers!
💸 3. Crime Scene Restoration: How did the money disappear?
Let's take a look at these two projects that suffered 'looting':
Incident One: Foom Protocol (Funding Pool 1.4 Million Dollars)
This is a x-color project launched on Base and Ethereum. After discovering this vulnerability, the hacker didn't even need to buy a ticket. He wrote a script himself and forged a 'I won' certificate using the vulnerability.
Because the system parameters were not disrupted ($\gamma = \delta$), the system directly determined that he won.
Fortunately, there is a group of kind 'white hat hackers' who have been monitoring the security on the chain. They acted before the malicious hackers could strike, continuously initiating dozens of withdrawal operations, successfully 'rescuing' over 1.4 million dollars to a safe address, preventing users from losing their capital.
Incident Two: Veil Protocol (Funding Pool Approximately 5000 Dollars)
This is a small privacy transfer pool. The attacker was not so polite; he wrote a smart contract himself and continuously called the withdrawal instruction 29 times. Each time, he forged a certificate to withdraw 0.1 Ethereum, instantly draining all the funds (2.9 ETH) from the pool and leaving.
🛡️ 4. Blood and Tears Lessons: Do not blindly trust 'high technology'.
This incident caused a huge stir in the cryptography community in 2026. It revealed three bloody truths to us:
No absolute security:The underlying mathematics of ZK zero-knowledge proofs is indeed impeccable, butthe people who write code and deploy code can make mistakes! Just like you bought a vault door but forgot to remove the key when you left, no matter how thick the door is, it’s useless.
Simple mistakes are the deadliest: We always think that hackers will use extremely advanced techniques to crack the system. However, in reality, the more advanced the system, the more likely it is to fail due to basic 'configuration errors' (not executing phase two instructions).
Code audits cannot skimp on expenses: Many project teams spend a lot of money hiring people to audit core logic, yet they mess up during the final 'deployment phase'. Now, top security companies (like zkSecurity) have made it clear: future audits must thoroughly check the steps involved in your deployment!
💡 Conclusion: No matter how advanced the technology is, it fears 'pig teammates'.
This 'lost key' incident is the first loud alarm for all ZK developers in the Web3 world.
In the future, as ZK technology becomes more widespread, how to use foolproof tools to prevent programmers from making such basic mistakes will be a hurdle the entire industry must overcome.
⚠️
[Disclaimer] The content of this article is only for the dissection of business models and sharing of technical knowledge, with data sourced from the internet. It does not constitute any investment or operational advice, nor does it assume responsibility for the authenticity of the data. Please research independently and make cautious decisions.
🌹 If you like this in-depth analysis, feel free to like, follow, comment, and share! Your support is our greatest motivation for continuous output!