Developer — Preparation before a Review

Rex Hygate
Jan 11 · 3 min read

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.

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)


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.


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.


Most DeFi applications appear to have a good test suites. 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. 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.


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.

These steps will make code that is easy to trust, easy to audit and will get an excellent score when I run 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.

DeFi Safety

Smart Contract Quality and Transparency for DeFi Protocols

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store