Security at Unstoppable
An insight into our development and security processes.
Writing secure smart contracts isn’t an easy task, as we have witnessed by the multitude of hacks in DeFi over the years.
Yet it’s absolutely necessary since smart contracts, unlike a lot of other software, are often responsible for securing tremendous amounts of money.
Traditional software development is already incredibly complex, but smart contracts have a few extra peculiarities that make it even more challenging to write good and secure code.
One of them is, that code on the blockchain is immutable. Once a contract is deployed its code cannot be changed anymore. Now on the one hand that gives users a lot of safety, since they know the devs can’t simply change what the contract does or who has access to the funds in it overnight, but it also means any bug that might have found its way into the code, cannot be easily patched.
In web2 the famous Facebook motto “Move fast and break things” that advocated for iterative development and deployment worked really well. You are always just one quick patch away from fixing that small mistake you accidentally pushed to production. Updating your software 100 times a day is not uncommon.
With smart contracts and immutable code, that becomes “a bit” more difficult. You only get one shot to get it right, and your code must be perfect before you deploy it on chain.
Not making even a single mistake can be quite difficult with any task, especially a complex one such as writing code and with the stakes so high.
That’s why it is essential, that the processes before, during and after development are absolutely rigorous and enforce best practices, discipline and reviews before even getting to the stage where you consider a deployment.
Experienced Developers
Experienced developers are one of the first, absolutely essential requirements for any team considering developing in DeFi.
If you haven’t been around for long enough (and have made enough mistakes and learned from them), you most likely won’t be able to deliver the quality of code needed in this environment.
We at Unstoppable are very lucky to have more than 30 years of combined developer and CTO experience with our two senior core devs already. And then there is another 10–15 from our external security reviewer and auditor to top it off.
Security First Mindset
Again we are lucky, that all our devs have a background in IT security.
Having been exposed to that industry for a while changes the way you look at things. It makes you default to an adversarial mindset where you are always on the lookout for what could go wrong or how something could be used in an unintended way.
Securing your software does not become an afterthought that you “bolt on” once you got your software working, it makes sure security is built into everything right from the start.
Architecture and Design
Secure software starts even long before you write the first line of code.
A well designed system will be modular, always working on a “least privileged access” principle.
One part of the code handles user funds, while another needs to interact with a 3rd party protocol? Great, let’s separate the two into different contracts and keep the one handling user funds as simple as possible. Now any unforeseen circumstances in the interactions with the 3rd party contracts cannot affect or lead to a loss of user funds.
You can see an example of this in action in the GLP Autocompounder we recently built:
As you can see, the GlpVault contract is the one who holds the user funds. It is built on the open source, fully audited and battle tested OpenZeppelin ERC4626 reference implementation and we only added a few lines of custom code to handle some specifics about GLP and to add the functionality to harvest the yield.
The more complex code minting new GLP, checking ETH and GLP prices and interacting with a lot of other contracts, is outsourced into the Strategy Contract. This contract does not have any access whatsoever to the users GLP funds, it only ever holds a little bit of the yield ETH at a time and executes the more complex interactions.
Even if something would go wrong there, it can never have an effect on the funds the users put into the vault contract.
Spending time to develop a good architecture and system design, that breaks everything down into its most simple pieces and separates different concerns as far as possible, is another core aspect of our development process. We will spend a lot of time to get this right long before we start writing the first line of code.
Test Driven Development
One way to make sure your code is doing what it’s supposed to do, is write automated tests for it. Just as important though, is to make sure your code doesn’t do more than it’s supposed to (leading to unintended side effects, bugs and possibly vulnerabilities).
One way to ensure that every single line of code you write is properly tested, is to use Test Driven Development.
This basically means, you write the test before you write the code. The test will be the specification of what exactly your soon-to-be-written code is supposed to do. Once the test is ready, you then write the minimum amount of code to pass the test. Rinse and repeat and you will end up with not only 100% test coverage, but also with a well documented specification in test form and you can be fairly confident that you didn’t miss testing unintended side effects.
When interacting with other ecosystems on the blockchain, it can sometimes be tough to set up the testing environment initially, but in our opinion it is always worth it.
100% test coverage is one of our core philosophies at Unstoppable.
Checks, Effects, Interactions
Checks, Effects, Interactions is possibly the most important mantra to keep in mind for a smart contract developer.
It defines the correct sequence in which you have to perform certain actions in your code.
The reason why it is so important, is because it will prevent one of the most serious bugs that could be exploited by malicious actors, the Reentrency Attack.
This type of bug is especially dangerous because it won’t be caught by your tests. Even if you violate the Checks, Effects, Interactions pattern, your code will do exactly what you want it to do and nothing more. All your meticulous tests will pass and assure you that everything is fine until you release your contract into the harsh adversarial environment of a live blockchain.
A reentrency side effect will only occur when a malicious actor purposefully executes your code in a very unusual way. But the effect could be literally loss of all funds.
So the Checks, Effects, Interactions pattern is a mantra we not just always have in mind, but that we specifically look for during any reviews.
Four Eyes
Everybody makes mistakes, no exceptions.
Reviewing everything, from early design drafts, to flow diagrams, to tests, to code is therefore absolutely essential.
It gives us confidence that not just the parts that are there are correct and working as intended, but also ensures we didn’t miss any blindspots.
State of Security
Especially with something that is still as new and developing as fast as blockchain technology, it is of utmost importance to stay up to date on the latest developments and security incidents.
We not just keep up with the news on that on a realtime basis, but also regularly review recent hacks and incidents to ensure we fully understand what happened, why it happened and how a similar issue could occur in the context of what we are building.
Unfortunately there is no shortage of things to review these days and sometimes it can be hard to keep up with yet another 9 figure bridge hack every other week, a brute-forceable private key on vanity addresses and even view only reentrency attacks.
External Reviews
Last but not least, the final step of any contract that handles user funds and that makes it to production, will be reviewed by external reviewers.
This ensures that there is a fresh pair of eyes that is not biased by the knowledge of what the contract “should” do but only sees what the contract actually does.
We are lucky to have one of the most experienced auditors of the space work as a freelancer for us in this respect who will give us the final check in the form of an internal audit to ensure we only release highest quality code to production.
We just published on of those internal audits for you to check out: Unstoppable GLP Autocompounder Audit.
This is it, a small insight into our development processes and security practices. We hope it is interesting for you to get some transparency and insight into the behind-the-scenes at Unstoppable, if you have any questions, head over to our discord and let us know.
