In the following post, I look at the recent hack on Uranium Finance (Binance Smart Chain), identify points of failure and make suggestions for performing adequate due diligence in the context of making investments in DeFi smart contracts.
Early April 28th (UTC), the Uranium Finance liquidity pools were drained. As highlighted in others posts, the source of the hack was a simple typo in the smart contracts. While there is some speculation that the typo was deliberate, in this post, I’m going to assume it was an honest mistake.
According to a post published by the Uranium team,
The audit included private peer review by Defiyield.info and code review by Hyperjump who are both very active in the AMM/farm space and a full audit by BSC Gemz. Not one of these audits picked this up as a critical vulnerability, but BSC Gemz did highlight an associated low level risk. The complete code base was available with not only these groups but was available on our GitHub and viewable on BSCscan.
How could three independent auditors have missed such a glaring problem?
Let’s look at each audit independently:
Defiyield.info
One of two anonymous Uranium developers (“Cataldo”) has been active in the Uranium Telegram chat since the hack occurred.
From those posts, it’s not even clear who performed this “private peer review”. (Note that this was not a formal audit and all parties agree that no one was paid.) On Telegram, “Farming Lord³ / DefiYield.info” denies the assertion that he did any kind of peer review or “lite audit”.
In response, Cataldo @ Uranium posts the interactions with “DefiYield.info”:
To which “Farming Lord³/ Defiyield.info” responds on the Uranium chat:
From these interactions, it seems that:
- The Uranium team had only a vague idea who was auditing their code
- The Uranium team had little evidence that “defiyield.info” did anything
- At best, “defiyield.info” ran Uranium’s test suite, which obviously is a far cry from a legit audit
After I originally published this post, “Farming Lord³/ Defiyield.info” reached out to me to clarify certain points. Apparently, a certain “Wendel” — a volunteer in the defiyield.info Telegram channel — checked the code for just “20 minutes”. Moreover, the faulty AMM code apparently wasn’t even included in that review.
Hyperjump
Hyperjump’s audit appears to have been the only paid audit completed before Uranium v2 was deployed. Here’s the entire audit report:
Observations:
- As with defiyield.info, Hyperjump is a DeFi project in its own right, not a professional auditing firm.
- There is no discussion in the Hyperjump audit report of the methodology employed to stress test the contracts; in fact, the audit comments imply that they only did a high-level review of the code.
BSC Gemz
According to the Uranium team, the BSC Gemz audit was all but complete (albeit never published) a few days before the hack and is what tipped them off to the bug. (Cataldo at Uranium mentioned that a person named Ogle was involved in this audit in some way, who discusses the hack here.) One thing to note here is that the Uranium team released v2 before the audit was complete. In other words, they released v2 based on the incredibly inadequate reviews by “defiyield.info” and Hyperjump. (Note: as stated earlier, “defiyield.info” was apparently just a moderator named Wendel on the defiyield.info Telegram group.)
Points of Failure
There are a few points of failure that made this project almost doomed to fail:
- The Uranium team is anonymous. With minimal reputation risk, they seem to have hacked away at code in an irresponsible way. Moreover, Cataldo at Uranium has admitted that he thinks that someone in his team leaked knowledge of the hack to an acquaintance (perhaps to protect them from the exploit), but he refuses to identify individuals’ names to authorities.
- The Uranium team did the real audit — the one by BSC Gemz — after they deployed the smart contracts. Obviously, this makes almost no sense whatsoever and was clearly motivated by a desire to ship as quickly as possible. Moreover, any number of people at BSC Gemz and the 7 members of the Uranium team knew that there was a vulnerability. And any of these people might be the hacker or might have tipped off the hacker.
- The Uranium team didn’t have a clear game plan when they discovered a bug. Ideally, they should have drained the LPs themselves and immediately and return the money to LP stakers. (Note that doing this competently is not trivial.) Instead, they decided to do something really crazy. They announced the release of v2.1 just ~10 days after the release of v2. In traditional software development, x.1 generally indicates that bugs are being fixed relatively to x.0. There is no such thing as x.1 in DeFi! They implicitly announced to the entire world that they found a bug.
Due Diligence for Investors
Based on the above, I’d suggest the following due diligence rules for investing in DeFi smart contracts:
- Has v1 of the protocol has been around for at least 3 months? Don’t be one of the first people to ape into a project.
- Has the most recent version of a protocol been around for at least 2 weeks? As seen with the recent Pancakeswap v2 release, upgrades are likely points of failure.
- Did the development team spend at least 3 months working on the project prior to deployment of v1? (Check the commit history in their public repo and the age of the domain name on whois.domaintools.com.)
- Is there any other indication of sloppiness in the code? Is the repo poorly maintained? Was the code written rapidly during a hot market? Check the repo commit timeline. (Uranium’s token & LP designs were very ambitious, but they had just two devs and seem to have made changes at a breakneck pace.)
- Is the project a simple fork of a battle-tested protocol or is the project’s scope to be too ambitious for the development team? If the latter, the smart contracts are more likely to have bugs.
- Are the developer identities known? As mentioned earlier, a known developer simply can’t afford to deploy irresponsible code.
- Have the developers received sponsorship from a reputable institution? e.g., a grant or a Series A from Binance, Ethereum Foundation, Pantera, etc.
- Is the TVL greater than $100mm?
- Are the returns reasonable relative to other DeFi platforms? (Some of the Uranium LPs had returns north of 1,000% APY.)
- Was the audit done before deployment or is it “in progress”?
- Did the audit actually run a battery of tests or was it a casual review?
- Is the audit report professionally done? Is their methodology explained?
- Does the project have more than 100k Twitter followers or is at least one reputable Twitter account (>100k followers) promoting it?
- Is the project a fork? If so, diff the code vs the source repo and ask the developers why they made certain changes.
- Download the code and run the tests. How do the tests compare to the source repo’s tests? Do they seem to have taken shortcuts or did they go above and beyond to find weaknesses?
- Is the project audited by a reputable company? Needless to say, auditors associated with prior hacks are probably not reputable.
- Was the project hacked before? What were the details? In almost all cases, don’t touch a project that was previously hacked. Check the Rugsteemer group on Telegram.
- Is the project’s token listed on Coingecko? Uranium’s token, U92, was not. As Coingecko does minimal due diligence on projects, not being on Coingecko is a reg flag.
- Can you answer all the above diligence questions relatively easily? Is the development team transparent in their documentation and Telegram group?
If you choose to overlook these guidelines for some reason, consider that investment to be speculative and limit exposure to 5% of your portfolio.
Lessons for the Industry
Industry titans like Binance and the Ethereum Foundation should come together and:
- Establish clear guidelines on how good audits should be done. Audit firms should attest that they’ve followed those guidelines. To date, I haven’t seen any DeFi audit reports that strike me as comprehensive and thorough.
- Establish clear guidelines for how project devs should handle bugs that are discovered after deployment.
Moreover, projects can implicitly self insure by publicly stating the reward amount for white hats. It is much better if 10% is lost in a white hat reward than 100% lost to a criminal hacker. Since the incentives are relatively high to legally hack the contracts (as there would be no legal repercussions), white hats are likely to exploit protocols before a criminal.
Finally, I think we’ll eventually see decentralized KYC protocols implemented for law enforcement purposes. For example, a new KYC protocol called SecureFi might offer users the opportunity to voluntarily KYC. The KYC data would be encrypted and not accessible even by members of the SecureFi development team. Then a new DeFi protocol (like Uranium) could require that users are whitelisted with SecureFi. If there is a hack, SecureFi token holders could vote to decrypt the KYC data associated with the hacker’s account, but only if requested by law enforcement authorities. Such a protocol would be a deterrent to would-be hackers while protecting most users’ identities.
References:
Fork of the flawed Uranium v2 code (the original repo is no longer public): https://github.com/3v3rt0n/DextroFinance
