Skip to main content

EVM Checklist (Solidity Vyper Yul)

Release: Version 2.0

#ItemTypeDescription
1Default VisibilitySWC-100 SWC-108Functions and state variables visibility should be set explicitly. Visibility levels should be specified consciously.
2Integer Overflow and UnderflowSWC-101If unchecked math is used all math operations should be safe from overflows and underflows.
3Outdated Compiler VersionSWC-102It is recommended to use a recent version of the Solidity compiler.
4Floating PragmaSWC-103Contracts should be deployed with the same compiler version and flags that they have been tested thoroughly.
5Unchecked Call Return ValueSWC-104The return value of a message call should be checked.
6Access Control & AuthorizationCWE-284Ownership takeover should not be possible. All crucial functions should be protected. Users could not affect data that belongs to other users.
7SELFDESTRUCT InstructionSWC-106The contract should not be self-destructible while it has funds belonging to users.
8Check-Effect-InteractionSWC-107Check-Effect-Interaction pattern should be followed if the code performs ANY external call.
9Assert ViolationSWC-110Properly functioning code should never reach a failing assert statement.
10Deprecated Solidity FunctionsSWC-111Deprecated built-in functions should never be used.
11Delegatecall to Untrusted CalleeSWC-112Delegatecalls should only be allowed to trusted addresses.
12DoS (Denial of Service)SWC-113 SWC-128Execution of the code should never be blocked by a specific contract state unless it is required.
13Race ConditionsSWC-114Race Conditions and Transactions Order Dependency should not be possible.
14Authorization through tx.originSWC-115tx.origin should not be used for authorization.
15Block values as a proxy for timeSWC-116Block numbers should not be used for time calculations.
16Signature Unique IdSWC-117 SWC-121 SWC-122 EIP-155Signed messages should always have a unique id. A transaction hash should not be used as a unique id. Chain identifier should always be used.
17Shadowing State VariableSWC-119State variables should not be shadowed.
18Weak Sources of RandomnessSWC-120Random values should never be generated from Chain Attributes or be predictable.
19Incorrect Inheritance OrderSWC-125When inheriting multiple contracts especially if they have identical functions a developer should carefully specify inheritance in the correct order.
20Calls Only to Trusted AddressesEEA-Level-2 SWC-126All external calls should be performed only to trusted addresses.
21Presence of unused variablesSWC-131The code should not contain unused variables if this is not justified by design.
22EIP standards violationEIPEIP standards should not be violated.
23Assets integrityCustomFunds are protected and cannot be withdrawn without proper permissions or be locked on the contract.
24User Balances manipulationCustomContract owners or any other third party should not be able to access funds belonging to users.
25Data ConsistencyCustomSmart contract data should be consistent all over the data flow.
26Flashloan AttackCustomWhen working with exchange rates they should be received from a trusted source and not be vulnerable to short-term rate changes that can be achieved by using flash loans. Oracles should be used.
27Token Supply manipulationCustomTokens can be minted only according to rules specified in a whitepaper or any other documentation provided by the customer.
28Gas Limit and LoopsCustomTransaction execution costs should not depend dramatically on the amount of data stored on the contract. There should not be any cases when execution fails due to the block gas limit.
29Style guide violationCustomStyle guides and best practices should be followed.
30Requirements ComplianceCustomThe code should be compliant with the requirements provided by the Customer.
31Environment ConsistencyCustomThe project should contain a configured development environment with a comprehensive description of how to compile build and deploy the code.
32Secure Oracles UsageCustomThe code should have the ability to pause specific data feeds that it relies on. This should be done to protect a contract from compromised oracles.
33Tests CoverageCustomThe code should be covered with unit tests. Test coverage should be 100% with both negative and positive cases covered. Usage of contracts by multiple users should be tested.
34Stable ImportsCustomThe code should not reference draft contracts that may be changed in the future.