In line with The Defiant’s security awareness mission, I will outline a few pointers on how to identify a potential disaster before it unfolds. I spend my days identifying how projects conduct development and measuring how they end up deploying their code. After assessing over 200 protocols, we’ve picked up a few insights to identify poor development practices in DeFi.
Inverse Finance and Axie Infinity recently suffered exploits resulting in significant losses of funds. Katana, the only decentralised exchange on Axie’s Ronin chain that was developed by the same team (with the same development practices), scored 5% in our appraisal. Inverse scored much better but still lagged in some critical areas. Both were unaudited, had no bug bounties and provided extremely limited proof of testing or none at all. Katana was especially opaque when it came to explaining how it worked. Despite identifying these issues, these exploits still happened and users still lost their life savings.
With this checklist, I want to arm you – the humble ape/farmer/degen – with a few tips and tricks that are personalised to your risk profile as you navigate the DeFi minefield.
Note that none of these checks are the perfect solution that can ensure a completely safe DeFi experience. DeFi remains an incredibly risky place and a protocol could easily meet all of these checks and yet still be exploited. Please use this checklist as a non-prescriptive list and make sure you always conduct your own due diligence before apeing.
Can I find the GitHub repository? Is it well fleshed out?
Let’s start with the most fundamental question you should ask yourself before interacting with any contract. Can I find the GitHub repository the protocol uses?
For the uninitiated, GitHub is a website that teams use to coordinate software development. You should be easily able to find a team’s GitHub by searching for a protocol’s name, followed by GitHub.
The main question you should ask here is if it is public. Let’s compare the examples of Bancor’s GitHub repository and that of Grim Finance, which was exploited for $30M in December 2021. Look at how well fleshed out Bancor’s repository is: multiple folders, a README.md overview of the protocol, public collaborators, 4000+ submissions. Compare that to Grim Finance’s – it’s private. You have no idea what contracts you are interacting with.
What is especially important to note is that private repositories make audits useless, because you can never be sure that the contracts the developers deployed are the same ones that the auditors looked at if you can’t verify them yourself. Transparency is an important part of DeFi development: it leads to stronger code by letting everyone scrutinise it. Private repositories prevent transparency and undermine the open-source spirit of web3.
Is the protocol well-documented? Is contract ownership identified?
A second step is to browse through the documentation of the protocol. This is usually linked from the main page of their website and could be written in GitBook or a similar medium. It should provide a high-level overview of how the protocol works and other relevant information written in simple language so that you or I can understand what it is we’re about to use.
A good example of this is PancakeSwap: look how cute and comprehensible the little wabbits are!
Good documentation means the protocol knows its code inside out. Protocols can easily fork other protocols with little idea of how things operate, which can increase the likelihood of an incident. Relevant documentation usually means that they do understand it, as they can synthesise the information into something more digestible.
A key area to remain especially vigilant about is whether or not the owners and permissions of the contracts you’re interacting with are listed. Some contracts can be changed at will, which can expose your funds to new risks. Make sure you feel comfortable with who’s in control: just because you see others trusting a protocol does not mean it is safe. See how Tracer explicitly states that its DAO owns their contracts.
You should also remain vigilant for contract addresses. Double-check that they’re the same as the ones you’re interacting with on the protocol’s website. Gearbox explicitly states and links them to etherscan so you can verify them yourself. This simple action could have helped users avoid BadgerDAO’s frontend attack in which $120m was taken.
Is the code audited?
A third check you should perform is seeing if the code has been audited. Audit firms provide a valuable fresh pair of eyes on the code that you want to use. The audit should be public and the contracts reviewed by the auditors should be listed. See if the audit highlighted any problems and if they were resolved, such as 0x Protocol’s audit where a problem was identified and then fixed. Highlighted in red is a major issue that was identified, and in green that it was fixed. Major issues could result in the loss of user funds, so it’s pivotal that 0x Protocol got a second pair of eyes to double-check their code.
Other questions you might consider asking are:
- Is the audit detailed or a cursory inspection?
- How many people worked on the audit?
- How long did the audit take to perform?
- Was the audit conducted before the code was deployed?
- Is there a technical breakdown of the issues found?
While audits aren’t foolproof, they provide an added layer of security.
Is there a Bug Bounty?
The penultimate check you should run is if there is a bug bounty. Protocols often set aside funds so that hackers have a way to identify exploits to developers without actually using them. In running these programs, armies of white hat hackers are directed to stress test the protocols. Larger bounties attract more attention leading to more testing and eventually better code. These amounts are often eye-watering to ensure that hackers use these programs.
As proof of the effectiveness of these programs, look at how armor.fi raised their bounty from $27K to $700K. A day later, a bug that could have potentially crashed the protocol was identified and fixed. These programs go a long way in making sure that code becomes safer, meaning your funds will be safer too.
Is the development team public and do they proactively engage with their community?
The final check you should make is on the development team itself. Some developers remain anonymous, whereas others reveal their identities. Public development teams will hesitate before stealing your funds since their names will be tainted by it forever. Anonymous teams do not have the same disincentive. While it is important to remember that some anonymous developers are the most valuable contributors to DeFi, you must balance this with their ability to disappear. In short, public devs are held accountable through their public identities.
Good teams should also value communication and make it easy for you to get in touch with them. It’s an important release valve for grievances and suggestions – all of which make a protocol stronger. A community discord or telegram channel should be linked on their website allowing you to ask questions. Can you see someone trying to get in touch with a community manager or even a developer? Are they helpful/friendly? Do they dismiss their concerns? These are all important considerations.
Using this guide you should be able to complete some quick last-minute checks before approving your transactions, and hopefully, be a little safer as a result.
Thanks for reading, and happy apeing.
river0x works for defisafety.com, which reviews DeFi protocols and measures development practices. This is done by scoring them entirely on a variety of quantitative data points, contacting the development team for clarifications and then releasing the report for free. Generally speaking, the higher the score, the less likely a protocol is to suffer some form of exploit.