Balancer, an old and well-audited protocol, was recently "hacked." Similarly-well-audited Yearn Finance was too. Years ago Euler Finance was "hacked" via a function introduced in response to an earlier audit . USPD was audited pre-deployment and then the unaudited deployment process itself was hacked leading to a total write-off within about 3 months of launch. Nobody that has been paying attention believes audits are a guarantee something is secure. Many question if they are worth anything at all.
This is not new. This is not a web3 issue. And, really, this is not a particularly deep observation. But audits are still very much a thing. Projects pay for audits. Projects tout audits. People pretend to read audits. Often when an audited product is exploited people ask why and how that happened.
Rather than answering any of that directly we are going to work through a few recent audits for recently-launched products. The goal here is not to make fun of or criticize anyone. These are randomly selected, mainly because of the focus on recent things. That does not mean they are particularly bad. They are not even that bad!
Our point here is not that the auditors are doing anything wrong. The auditors are doing what the projects that engage them ask for. Audit scope is set by the project. As but one extreme example: if Do Kwon had engaged auditors for his stablecoin scheme they would have noted it was potentially unstable. The issue would have been marked "acknowledged" and nothing would have been done or different.
This problem has absolutely nothing to do with studies like those that claimed Do's Terra-LUNA ecosystem was highly robust . It is hard to predict the future and those sorts of studies are rightly viewed as self-serving marketing which, in the limit, acknowledges the core problems . Project-sponsored research is expected to paint things in a positive light. The entire point of audits is to provide an objective third-party perspective. Puffery is not to be trusted and audits are not guarantees or insurance. Such is life.
The point of this survey is to hammer home that the real problem here is not basic programming errors of the type auditors are well-situation to identify and the audit process is well-designed to resolve. Auditors are pretty good at catching those. So, for that matter, are the programmers building these things in the first place. Empirically this sort of feedback makes it to the right people and narrow issues are fixed.
No, the real problem is products that work exactly as intended and where a known "risk" materializes to take everything down. What you are going to see now are auditors trying to protect themselves against any and all future known-unknown problems. As a protection-from-liability-and-mocking exercise maybe this is valuable thing. But, in a general sense, it helps nobody.
And then at the end we are going to discuss what a range of parties can do that would both help and serve their own narrow self-interests. If your prescription for how to improve audits involves altruism then, well, it is not a very useful.
Jovay
Jovay is an L2 associated with Ant Financial or Alibaba or something in that general area. But it does not really matter what Jovay does. It is a thing built of software out of a large and well-funded organization. This audit lists eight issues:
- A legitimate programming mistake that was subsequently fixed.
- That the protocol is not trustless. This is a problem of sorts but it is also a core part of the design.
- The "fake-recharge" attack that applies to a broad swathe of the ecosystem and is not specific to the project.
- The RPC servers use HTTP rather than HTTPS. These interfaces do not process secret information. This applies to billions of perfectly safe read-only websites.
- Quantum computing poses a risk to Ethereum. OK. Very on-topic that one.
- EVM smart contracts can be vulnerable. No seriously. It says "Evm smart contracts are susceptible to various attack vectors due to immutable code deployment and complex interactions, potentially leading to fund theft,.." Ok. Again really respecting the narrow focus of this audit.
- The sequencer design is subject to MEV. Like the entire rest of the Ethereum ecosystem. It is also too dark at night.
- The code quality could be improved. Unlike most other code written since the dawn of computing.
Only one of these is a real issue. Yes it is worth noting the product itself is not trustless if the documentation otherwise states that it is trustless. But this product is pretty much fine on that front. Noting that quantum computing potentially poses a future risk and smart contacts can be risky...those are either attempts to make the report longer by finding made-up issues or they are an attempt to provide some kind of "it is not our fault" if something is eventually hacked. Probably a mix of the two.
In the spirit of those point we propose as a ninth problem that the network will go down when the sun dies unless we become an interstellar species and somehow figure out faster-than-light communication. Otherwise relativity limits the useful life of this system to about 5 billion years. Honestly that is more useful than stating the code quality could be improved because even after the Sun dies there will still be bad code executing somewhere. But we kid.
Hyperliquid
Hyperliquid has published a few audit reports . The first audit report found six problems and the second report confirmed those were resolved. But the scope of the audit excluded:
- Other smart contracts part of the Hyperliquid system
- Off-chain components, such as validators
- Front-end components
- Infrastructure relating to the project
- Key custody
Those seem like potential problem areas! All that was audited was a single bridge contract. But the system is, well, it is a lot more complicated than that .
Auditing one tiny corner of the system that does only a few tightly-defined things is pretty useless. The way Hyperliquid is designed the audited contract is the external ingress and egress point for everyone. So it would be a serious problem if that contract were riddled with errors. But confirming the contract works provides little-to-no comfort.
Ondo
This audit highlights "CENTRALIZATION RISK FOR TRUSTED ENTITIES AND ROLES" which the team acknowledged. It is capitalized like that in the report. Right.
This audit notes that the system might collapse if an involved stablecoin depegs too hard. They phrase that as the system "will allow excessive OUSG token minting during USDC depeg event." In the end the "solution" they put in was a reference to a Chainlink oracle and an off-switch in case the price is reported as too low. So rather than imploding with the value crashing the protocol will halt with the value crashing. Right. This is not a solvable problem in that there is no mechanism to avoid a value-loosing outcome if USDC blows up. And, in line with that fact, the solution does not really fix anything.
Those audits are relatively recent. But to give some context this audit from October 2022 identifies a lot of real issues. Almost 200 of them. Most were fixed, some were similar to the above and just acknowledged. The point is that auditing used to do something concrete and substantive: look for programming errors that could not have been the programmer's intention. The programmers used to fix these errors because they were, you know, genuine mistakes not just questionable design decisions built into the product.
And then by 2024 we see audits that find relatively few technical problems and declare as out of scope financial-related attacks . The only sensible way to interpret this change over time is that the programmers, and programmers-as-auditors, recognized that functioning code was not the only risk. Sure programming bugs got exploited from time to time. But by mid-2024 everyone could see that defective economic mechanisms were also a massive risk. They were the biggest risk.
Projects that worked exactly as intended – not as dreamed, as intended in reality – explode from time to time because the designers dreams of stability break when faced with the real world.
You can see this evolution in the audits of this one project.
Mutuum Finance
Now we have the reductio ad absurdum of audits. This one identifies a single issue:
The issue is the lack of transparency around the initial token distribution and how that might be related to centralization problems. It has been "mitigated" because:
Then there are a lot of multisig details. And finally the auditor's response:
So the risk with the project is that a small team controls everything and the way in which that control will be, or maybe will not be, dispersed is completely non-transparent. And the team's proposed solution of writing a blog post to clarify their intention does not, in any strict sense, fix this.
For the record the team has published a detailed list of what tokens will go where when. And they acknowledge this is incomplete with comments like "We are considering either a block-by-block or a weekly distribution model." They also acknowledge everything will be managed out of manual multisigs. So they are being honest. It is just that the honesty amounts to "yeah we can still do whatever we want and you have to trust us."
What is the purpose of this audit? If the code had no identifiable bugs the auditor could just write that. Sometimes a trip to the doctor or mechanic produces a clean bill of health. So we are left wondering if only a trivial amount of code was audited? Or maybe the project itself is just a trivial amount of code? Did the auditor feel a need to put something in the report because it was all too vacuous otherwise? Why did anybody bother with any of this?
Again we are not really blaming the auditors here. To the extent anyone is doing anything wrong here it is almost certainly an incentives problem with whoever commissioned the audit. And the fact they are spending investor money to produce a mostly-useless document for a marketing purpose. That is not the auditor's doing!
Improvements
It is an unequivocal good thing that more bugs are caught, less broken code is released to production and more proposed fixes are implemented. And we are not immature enough to suggest the problem is that users and investors care about the wrong things like, for example, placing value and trust on audits that do not mean much. People care about what they care about and trying to change that is a fool's errand.
But there are a few real improvements we can suggest. Ethena led the way by explaining some of the many failure modes of their product up front. The team was consistent with the message that USDe was not riskless. And they outlined ways it could have trouble. The product has survived, with a few bumps, and is quite large today. This gives us an action point for investors: insist projects are honest about any "financial-related attacks" that might exist.
Ethena shows that being honest does not doom the project! You can argue that by being more honest the project attracted more interest. Honesty also has the added bonus of providing more legal cover if something does go wrong. Projects should want to do this already.
Auditors, too, can rearrange the way they do analysis to make their work more useful. Or at least less useless and potentially misleading. Do not put economic incentive problems or general concerns like quantum safety in the same section as bugs. As of now these are normally labelled in a way that slightly differentiates them from coding errors. Or they are listed as "informational" as opposed to "critical."
But this misses the point. Quantum safety may well be a "critical" risk for a system – but it is of an entirely different character than a bad signature check or errant minus sign! Put these things in separate sections. Similarly "this stablecoin scheme is unstable under reasonably-likely conditions" is nothing like a logic bug in code. Clearing up this confusion should improve the appearance of the audit documents and burnish the auditor's reputation.
Finally, exchanges can help this. The large exchanges get a lot of stick for listing terrible projects, or wildly gyrating risky memecoins that cost people money, or all other manner of loss-inflicting strange business decisions. What if exchanges insisted on reasonable audits that cover economic stability honestly and do not conflate risks like "smart contracts can be vulnerable" with real logic checks?
One way to interpret an auditor padding their results with this sort of filler is that nobody will take an empty audit result seriously. Fair enough that such a document would raise questions. But if a major exchange listed a token with, say, two matching "empty" audit results that included no project-specific issues and took the position this was a good thing...that might help move the ball down field a bit. We are also at a point in the cycle where being a more "honest" and "reasonable" exchange should get you more customers than the lack of ridiculous too-the-moon marketing costs you.
Similarly, there should be no stigma attached to auditing a project and saying it looks fine. This one is on auditors. Maybe a bunch of auditors could issue some joint statements in this area. Yes, we can understand that auditors will want to put in caveats for potential problems that were ruled out of scope when the engagement began. Also fair enough. But padding results with pointless general potential problems is not the answer. Nor is saying the team mitigated centralization risk by making a blog post about the token distribution they intend to sort out manually, soon, on some schedule that is still to be determined.
Audits can be useful. Audits can help. And the truth is that web3 audits have caught real problems and, for a significant period of time, were packed with useful and interesting content. But engineers have improved over time because they are, you know, engineers and that is what they do. Auditors need to keep pace and, to borrow a word, innovate a bit. And many larger parts of the ecosystem, like the exchanges, can help move this along too.
