Architecture, design and threat modeling in the context of creating secure smart contracts. Consider all possible threats before the implementation of the smart contract.
Ensure that a verified contract satisfies the following high-level requirements:
Category “V1” lists requirements related to the architecture, design and threat modeling of the smart contracts.
| # | Description |
|---|---|
| 1.1 | Verify that the every introduced design change is preceded by an earlier threat modeling. |
| 1.2 | Verify that the documentation clearly and precisely defines all trust boundaries in the contract (trusted relations with other contracts and significant data flows). |
| 1.3 | Verify that the SCSVS, security requirements or policy is available to all developers and testers. |
| 1.4 | Verify that there exists an upgrade process for the contract which allows to deploy the security fixes or it is clearly stated that the contract is not upgradeable. |
| 1.5 | Verify that the events for the (state changing/crucial for business) operations are defined |
| 1.6 | Verify that there is a component that monitors the contract activity using events. |
| 1.7 | Verify that there exists a mechanism that can temporarily stop the sensitive functionalities of the contract in case of a new attack. This mechanism should not block access to the assets (e.g. tokens) for the owners. |
| 1.8 | Verify that there is a policy to track new security bugs and to update the libraries to the latest secure version. |
| 1.9 | Verify that the value of cryptocurrencies kept on contract is controlled and at the minimal acceptable level. |
| 1.10 | Verify that if the fallback function can be called by anyone it is included in the threat modelling. |
| 1.11 | Verify that the business logic in contracts is consistent. Important changes in the logic should be allowed for all or none of the contracts. |
| 1.12 | Verify that code analysis tools are in use that can detect potentially malicious code. |
| 1.13 | Verify that the latest version of the major Solidity release is used. |
| 1.14 | Verify that, when using the external implementation of contract, you use the current version which has not been superseded. |
| 1.15 | Verify that there are no vulnerabilities associated with system architecture and design. |
For more information, see also: