Developer — Preparation before a Review

If you are close to releasing a DeFi protocol, this article tells you the steps to get ready for a high DeFiSafety review score and ensure your protocol has great transparency for the community.

Your goal in the following is transparency. This means a total stranger who sees your website (then github and docs) can see enough to trust your code. Remember the code is all he is trusting because there is no regulatory safety net. This doc has been revised to our latest process (0.7).

Imagine a Solidity dev being tasked to verify that your contract does what it says it will do. You are giving him enough info to do this (though perhaps not enough to create his own fork)

Addresses

Ensure all the smart contract addresses are clearly in one place and always updated. If some are regularly updated (like AMM strategies) take this into account. A readable text document is better than “network.json” or equivalent.

Software Documentation

Documentation says at the top level what the product will do, how will be used what are its limitations and other pertinent information. For transparency you have to document the actual executing code. The documentation should step down until it is directly connected to the actual functions. If you look at how Synthetix did their documentation, that is the gold standard for me. Admittedly, they spent a lot of time and effort. Put in the time that you can.

Testing

Most DeFi applications appear to have a good test suites. The test suite should be public and available. If you don’t want to publish your tests then read the Private Repo article.

However, as a third-party looking at the repository, I have no idea if the tests passed and when they did how much of the code was covered. Each time you deploy the code, you should put a test report in the test directory.

A test report does not have to be a large or difficult thing. I assume before code is released to the main net, the full test suite is run and all tests pass. Just change the test script so that, for the release only, each test sends a text indicating that it ran and passed. If you are capturing coverage, indicate how much code was covered and which code was not covered. Take the time to look at the “misses” and think about why the code was not tested. Frequently there is a very straightforward and logical reason. Ideally the test should have this reasoning in text. This test report (which is included in the released repo. A rough test report that is just the outputs mentioned above strung into a big text file is acceptable.

Audits

In preparation for an audit, get everything clearly together in one repo. If you have a test network (kovan etc) ensure it is running the latest code. Run as many automated tests on the code (linter Echidna, Mythril, etc) as possible. Clearly indicate the results from the tests. This will make the auditor’s time more efficient (and save you money).

If you have done disaster planning on what you would do if something unexpected occurred with your product when it is live, document it. Even if you want to keep some details private, that is fine but at least indicate that you have reviewed it and you have a plan.

When you get the final audit report ensure that corrections are clearly documented. An audit that indicates problems without fixes does not build confidence. Ensures the fixes are clearly documented.

If you have a bug bounty document on your site.

Access Controls

Access Controls asks for documentation of the power the admins have over the protocol.

If your contracts are truly immutable (meaning not updateable) then indicate this. These get the highest scores.

If your protocol allows updates, then clearly document how much can be updated. Can you replace all the contracts and completely change the protocol? Say so. Your investors deserve to know. Is the update capability limited? Indicate this. Do you have a set of variables that the devs change change without redeploying the code. Indicate this all in language that investors rather than devs can understand.

Next document who has control to make these changes. In this case, don’t mention the DAO unless the DAO code actually executes the deployments. Otherwise is it a multisig, a single address?

Finally pause control. If you have the ability to pause your protocol in order to stop a hack, indicate this.

These steps will make code that is easy to trust, easy to audit and will get an excellent score when werun a full DeFi Safety audit.

That is all I have. Also, remember we run on GitCoin grants. Small donations get multiplied. The button is on our website.

Good Luck and let me know when you are fully released.