Principles for securely building smart contract systems collaboratively or individually.
The number one thing we are focusing on and optimizing, before anything else, is security. This means that before adding a line of code both the granular and the system-wide implications of that change must be deeply understood.
It is recommended to always use tools like the Olympix VSCode extension, and regularly run security analyzers like Mythril, Slither, etc.
The whole system must be regularly examined for complex, multi-step attacks like oracle or price manipulation.
All smart contracts containing external functions must have a corresponding interface file. All external functions must have clear documentation in the interface file, explaining their expected behavior, inputs, and outputs.
Before writing any new piece of smart contract code, look for existing implementations on Github. If possible, always use the battle-tested, popular implementations. The flip side is: don't import any random contract from Github, especially not without understanding every single line of code in that contract.
We break down the contracts into smaller, modular components that can be reused across different components. This promotes code reuse, reduces redundancy, and makes the contracts easier to maintain.
Every important piece of code must be tested extensively, accounting for expected failures, successes, and also fuzz testing important functionality.
The TDD approach is recommended for building any production smart contract.
The correct development steps are:
- Interfaces, structs, events
- Bare-bones smart contracts confirming to interfaces (no logic)
- All test cases as described above
- Actual smart contract code
If there are multiple smart contract developers on the team, consider the following approach:
- developer 1 implements the interfaces
- developer 2 implements the unit tests
- developer 3 (or developer 1 if there're only 2 devs) implements the first iteration of the logic
- everyone dives deep into the code, trying to break it
- group discussion analyzing findings
- select a new developer 1: this person implements the agreed upon changes
- rinse and repeat until the whole team is satisfied with the outcome
Minimize the use of state mutations whenever possible to reduce complexity and potential vulnerabilities.
We build upgradeable smart contracts to allow for future mechanism changes, fixes, etc.
No mainnet deployment without a successful security audit of all smart contracts.
All team members and the team as a whole must adhere to strict on-chain hygiene to prevent compromising the system. This involves using multisigs, hardware or cold wallets, etc.