0/15 completed

0/15 completed

✓ Task

V1: Architecture, design and threat modeling

0 Verify that the every introduced design change is preceded by an earlier threat modeling.
Verify that the documentation clearly and precisely defines all trust boundaries in the contract (trusted
0
relations with other contracts and significant data flows).
0 Verify that the SCSVS, security requirements or policy is available to all developers and testers.
Verify that there exists an upgrade process for the contract which
0 allows to deploy the security fixes or it is clearly stated that the contract is not upgradeable

0 Verify that the events for the (state changing/crucial for business) operations are defined
Verify that there is a component that monitors the contract activity using events
0
Verify that there exists a mechanism that can temporarily
stop the sensitive functionalities of the contract in case of a new attack.
0
This mechanism should not block access to the assets (e.g. tokens) for the owners
Verify that there is a policy to track new security bugs and to
0 update the libraries to the latest secure version
Verify that the value of cryptocurrencies kept on contract
0 is controlled and at the minimal acceptable level
Verify that if the fallback function can be called by anyone
0 it is included in the threat modelling
Verify that the business logic in contracts is consistent.
0 Important changes in the logic should be allowed for all or none of the contracts

0 Verify that code analysis tools are in use that can detect potentially malicious code.
 Verify that the latest version of the major Solidity release is used
0
Verify that, when using the external implementation of contract,
0 you use the current version which has not been superseded
Verify that there are no vulnerabilities associated with system architecture and design
0
 0/13 completed

0/13 completed

✓ Task

V2: Access control

Verify that the principle of least privilege exists, other contracts should only be able to access functions
0
and data for which they possess specific authorization.
Verify that new contracts with access to the audited contract adhere to the principle of minimum rights
0 by default. Contracts should have a minimal or no permission until access to the new features is
explicitly granted.
Verify that the creator of the contract complies with the rule of least privilege and their rights strictly
0
follow the documentation.
Verify that the contract enforces the access control rules specified in a trusted contract, especially if
0 the dApp client-side access control is present (as the client-side access control can be easily
bypassed).
Verify that there is a centralized mechanism for protecting access to each type of protected resource
0
Verify that the calls to external contracts are allowed only if necessary
0
Verify that visibility of all functions is specified
0
Verify that the initialization functions are marked internal and cannot be executed twice
0
Verify that the code of modifiers is clear and simple. The logic should not contain external calls to untrusted contracts
0
Verify that the contract relies on the data provided by right sender and contract does not rely on tx.origin value
0
that all user and data attributes used by access controls are kept in trusted contract and cannot be manipulated by other contracts unless specifically authorized
0

0 Verify that the access controls fail securely including when a revert occurs.

0 Verify that there are no vulnerabilities associated with access control.

 0/6 completed

0/6 completed

✓ Task

V3: Blockchain data

0 Verify that any data saved in the contracts is not considered safe or private (even private variables).

0 Verify that no confidential data is stored in the blockchain (passwords, personal data, token etc.).
Verify that the list of sensitive data processed by the smart contract is identified, and that there is an
0 explicit policy for how access to this data must be controlled and enforced under relevant data
protection directives.
0 Verify that there is a component that monitors access to sensitive contract data using events.
Verify that contract does not use string literals as keys for mappings. Verify that global constants are
0
used instead to prevent Homoglyph attack.
0 Verify that there are no vulnerabilities associated with blockchain data.
 0/8 completed

0/8 completed

✓ Task

V4: Communications
Verify that libraries which are not part of the application (but the smart contract relies on to operate) are
0
identified.
Verify that contract does not use hard-coded addresses unless necessary. If the hard coded address is
0
used, make sure that its contract has been audited.
Verify that contracts and libraries which call external security services have a centralized
0
implementation.
Verify that delegatecall is not used with untrusted contracts
0
Verify that re-entrancy attack is mitigated by blocking recursive calls from other contracts. Do not use
0
call and send function unless it is a must.
Verify that the result of low-level function calls (e.g. send, delegatecall, call) from another contracts is
0
checked.
0 Verify that third party contracts do not shadow special functions (e.g. revert).
Verify that there are no vulnerabilities associated with communications
0
 0/7 completed

0/7 completed

✓ Task

V5: Arithmetic
Verify that the values and math operations are resistant to integer overflows. Use SafeMath library for
0
arithmetic operations before solidity 0.8.*.
0 Verify that the unchecked code snippets from Solidity 0.8.* do not introduce integer under/overflows.
Verify that the extreme values (e.g. maximum and minimum values of the variable type) are considered
0
and does change the logic flow of the contract.
0 Verify that non-strict inequality is used for balance equality.

0 Verify that there is a correct order of magnitude in the calculations.

0 Verify that in calculations, multiplication is performed before division for accuracy.

Verify that there are no vulnerabilities associated with arithmetics
0
 0/3 completed

0/3 completed

✓ Task

V6: Malicious input handling

Verify that if the input (function parameters) is validated, the positive validation approach (allowlisting)
0
is used where possible.
0 Verify that the length of the address being passed is determined and validated by smart contract.

0 Verify that there are no vulnerabilities associated with malicious input handling.
 0/12 completed

0/12 completed

✓ Task

V7: Gas usage & limitations

Verify that the usage of gas in the smart contract is anticipated, defined and has clear limitations that
0
cannot be exceeded. Both, code structure and malicious input should not cause gas exhaustion.
Verify that two types of the addresses are considered when using the send function. Sending Ether to
0
the contract address costs more than sending Ether to the personal address.
0 Verify that the contract does not iterate over unbound loops.

0 Verify that the contract does not check whether the address is a contract using extcodesize opcode.
Verify that the contract does not generate pseudorandom numbers trivially basing on the information
0
from blockchain (e.g. seeding with the block number).
Verify that the contract does not assume fixed-point precision but uses a multiplier or store both the
0
numerator and denominator instead.
Verify that, if signed transactions are used for relaying, the signatures are created in the same way for
0
every possible flow to prevent replay attacks.
Verify that there exists a mechanism that protects the contract from a replay attack in case of a hard-fork
0

0 Verify that all library functions that should be upgradeable are not internal.

0 Verify that the external keyword is used for functions that can be called externally only to save gas.

0 Verify that there is no hard-coded amount of gas assigned to the function call (the gas prices may vary in the future).

0 Verify that there are no vulnerabilities associated with gas usage & limitations.
 0/11 completed

0/11 completed

✓ Task

V8: Business logic

0 Verify that the contract logic implementation corresponds to the documentation.
Verify that the business logic flows of smart contracts proceed in a sequential step order and it is not
0
possible to skip any part of it or to do it in a different order than designed.
0 Verify that the contract has business limits and correctly enforces it.
Verify that the business logic of contract does not rely on the values retrieved from untrusted contracts
0
with multiple calls of the same function.
Verify that the contract logic does not rely on the balance of contract (e.g. balance == 0)
0
Verify that the sensitive operations of contract do not depend on the block data (i.e. block hash,
0
timestamp).
Verify that the contract uses mechanisms that mitigate transaction-ordering dependence (front-
0
running) attacks (e.g. pre-commit scheme).
Verify that the contract does not send funds automatically but it lets users withdraw funds on their own
0 in separate transaction instead.
Verify that the inherited contracts do not contain identical functions or the order of inheritance is
0 carefully specified
Verify that the business logic does not compare the extcodehash return value with 0 to check whether
0
another address is contract (the hash of empty data is returned in such case).
Verify that there are no vulnerabilities associated with business logic
0
 0/8 completed

0/8 completed

✓ Task

V9: Denial of service

Verify that the self-destruct functionality is used only if necessary. If it is included in the contract, it
0
should be clearly described in the documentation.
Verify that the business logic does not block its flows when any of the participants is absent forever.
0
Verify that the contract logic does not disincentivize users to use contracts (e.g. the cost of transaction
0 is higher that the profit).

Verify that the expressions of functions assert or require to have a passing variant.
0
Verify that if the fallback function is not callable by anyone, it is not blocking the functionalities of
0 contract and the contract is not vulnerable to Denial of Service attacks.
Verify that the function calls to external contracts (e.g. send, call) are not the arguments of require and
0 assert functions.
Verify that the function declarations are callable by the used compiler version (see the Uncallable
0 function example link below).

Verify that there are no vulnerabilities associated with availability.

0
 0/6 completed

0/6 completed

✓ Task

V10: Token
Verify that the token contract follows a tested and stable token standard.
0

Use the approve function from the ERC-20 standard to change allowed amount only to 0 or from 0.
0

Verify that the contract does not allow to transfer tokens to zero address.
0
Verify that the re-entracy attack has been considered when using the token contracts with callbacks
0 (e.g. ERC-777).
Verify that the transfer business logic is consistent, especially when re-sending tokens to the same
0 address (msg.sender == destination).

Verify that there are no vulnerabilities associated with Token.

0
 0/15 completed

0/15 completed

✓ Task

V11: Code clarity

Verify that the logic is clear and modularized in multiple simple contracts and functions.
0
Verify that the inheritance order is considered for contracts that use multiple inheritance and shadow
0 functions.
Verify that the contract uses existing and tested code (e.g. token contract or mechanisms like ownable)
0 instead of implementing its own.
Verify that the same rules for variable naming are followed throughout all the contracts (e.g. use the
0 same variable name for the same object).

Verify that variables with similar names are not used.

0

Verify that all variables are defined as storage or memory variable.

0

Verify that all storage variables are initialised.

0
Verify that the constructor keyword is used for Solidity version greater than 0.4.24. For older versions of
0 Solidity make sure the constructor name is the same as contract's name.

Verify that the functions which specify a return type return the value.
0

Verify that all functions are used. Unused ones should be removed.
0

Verify that the require function is used instead of the revert function in if statement.
0

Verify that the assert function is used to test for internal errors and the require function is used to
0
ensure a valid condition on the input from users and external contracts.
 Verify that assembly code is used only if necessary.
0
Verify that there is a description in the form of 1-2 short sentences of what the contract is for at the
0 beginning of the contract.
Verify that if the system uses a ready-made implementation of the contract, it has been marked in the
0 comment. If it contains changes from the original, those have been specified.
 0/4 completed

0/4 completed

✓ Task

V12: Test coverage

Verify that considered as sensitive functions of verified contract are covered with tests in the
0 development phase.
Verify that the implementation of verified contract has been checked for security vulnerabilities using
0 static and dynamic analysis.

Verify that the specification of smart contract has been formally verified.
0

Verify that the specification and the result of formal verification is included in the documentation.
0
 0/45 completed

0/45 completed

✓ Task

V13: Known attacks

Verify that the contract is not vulnerable to Integer Overflow and Underflow attacks.
0
[5.1] Verify that the values and math operations are resistant to integer overflows. Use SafeMath library
0 for arithmetic operations.

[5.2] Verify that the extreme values (e.g. maximum and minimum values of the variable type) are
0
considered and does change the logic flow of the contract.
Verify that the contract is not vulnerable to Reentrancy attack.
0

[4.5] Verify that the re-entrancy attack is mitigated by blocking recursive calls from the other contracts.
0
Do not use call and send functions unless it is a must.
Verify that the contract is not vulnerable to Access Control issues.
0
[2.1] Verify that the principle of least privilege exists - other contracts should only be able to access
0 functions or data for which they possess specific authorization.
[2.2] Verify that new contracts with access to the audited contract adhere to the principle of minimum
rights by default. Contracts should have a minimal or no permission until access to the new features is
0
explicitly granted.
[2.3] Verify that the creator of the contract complies with the rule of least privilege and his rights strictly
0 follow the documentation.
[2.4] Verify that the contract enforces the access control rules specified in a trusted contract, especially
if the dApp client-side access control is present (as the client-side access control can be easily
0
bypassed).
[2.5] Verify that there is a centralized mechanism for protecting access to each type of protected
0 resource.

[2.6] Verify that the calls to external contracts are allowed only if necessary.
0
 [2.7] Verify that visibility of all functions is specified.
0

[2.8] Verify that the initialization functions are marked internal and cannot be executed twice.
0

[2.9] Verify that the code of modifiers is clear and simple. The logic should not contain external calls to
0
untrusted contracts.
[2.10] Verify that the contract relies on the data provided by right sender and contract does not rely on
0
tx.origin value.
[2.11] Verify that all user and data attributes used by access controls are kept in trusted contract and
0 cannot be manipulated by other contracts unless specifically authorized.

[2.12] Verify that the access controls fail securely including when a revert occurs.
0

[3.4] Verify that there is a component that monitors access to sensitive contract data using events.
0
[7.4] Verify that the contract does not check whether the address is a contract using extcodesize
0 opcode.

Verify that the contract is not vulnerable to Silent Failing Sends and Unchecked-Send attacks.
0

[4.6] Verify that the result of low-level function calls (e.g. send, delegatecall, call) from another
0
contracts is checked.
[4.7] Verify that the third party contracts do not shadow special functions (e.g. revert).
0

Verify that the contract is not vulnerable to Denial of Service attacks.

0

[7.3] Verify that the contract does not iterate over unbound loops.
0

[9.1] Verify that the self-destruct functionality is used only if necessary.

0
[9.2] Verify that the business logic does not block its flows when any of the participants is absent
0 forever.
[9.3] Verify that the contract logic does not disincentivize users to use contracts (e.g. the cost of
0 transaction is higher that the profit).

[9.4] Verify that the expressions of functions assert or require have a passing variant.
0
[9.5] Verify that if the fallback function is not callable by anyone, it is not blocking the functionalities of
0 contract and the contract is not vulnerable to Denial of Service attacks.
 [9.6] Verify that the function calls to external contracts (e.g. send, call) are not the arguments of require
0 and assert functions.

Verify that the contract is not vulnerable to Bad Randomness issues.

0
[7.5] Verify that the contract does not generate pseudorandom numbers trivially basing on the
0 information from blockchain (e.g. seeding with the block number).

Verify that the contract is not vulnerable to Front-Running attacks.

0
[8.7] Verify that the contract uses mechanisms that mitigate transaction-ordering dependence (front-
0 running) attacks (e.g. pre-commit scheme).

0 Verify that the contract is not vulnerable to Time Manipulation issues.

[8.6] Verify that the sensitive operations of contract do not depend on the block data (i.e. block hash,
0 timestamp).

Verify that the contract is not vulnerable to Short Address Attack.

0

[6.2] Verify that the length of passed address is determined and validated by smart contract.
0

0 Verify that the contract is not vulnerable to Insufficient Gas Griefing attack.
[7.1] Verify that the usage of gas in smart contracts is anticipated, defined and have clear limitations
0 that cannot be exceeded. Both, code structure and malicious input should not cause gas exhaustion.
[7.2] Verify that two types of the addresses are considered when using the send function. Sending
0 Ether to contract address costs more than sending Ether to personal address.

[7.3] Verify that the contract does not iterate over unbound loops.
0
[7.4] Verify that the contract does not check whether the address is a contract using extcodesize
0 opcode.
[7.10] Verify that the external keyword is used for functions that can be called externally only to save
0 gas.
 0/12 completed

0/12 completed

✓ Task

V14: Decentralized Finance

Verify that the lender's contract does not assume its balance (used to confirm loan repayment) to be
0 changed only with its own functions.
Verify that the functions which change lender's balance and lend cryptocurrency are non-re-entrant if
the smart contract allows to borrow the main platform's cryptocurrency (e.g. Ethereum). It blocks the
0
attacks that update the borrower's balance during the flash loan execution.
Verify that the flash loan function can call only a predefined function on the receiver contract. If it is
0 possible, define a trusted subset of contracts to be called. Usually, the sender (borrower) contract is the
Verify
one to that the receiver's
be called back. function that handles borrowed ETH or tokens can be called only by the pool
and within a process initiated by the receiver's owner or other trusted source (e.g. multisig), if it
0
includes potentially
Verify that dangerous
the calculations operations
of the share in a(e.g. sending
liquidity poolback more ETH/tokens
are performed with thethan borrowed).
highest possible
precision (e.g. if the contribution is calculated for ETH it should be done with 18 decimals precision - for
0
Wei,
Verifynot Ether).
that The dividend
the rewards cannotmust be multiplied
be calculated and by the 10 towithin
distributed the power of thefunction
the same numbercall
of decimals (e.g.
that deposits
dividend
tokens (it*should
10**18also
/ divisor).
be defined as non-re-entrant). That protects from the momentary fluctuations in
shares.
Verify that the governance contracts are protected from the attacks that use flash loans. One possible
security is to require the process of depositing governance tokens and proposing a change to be
0
executed in different transactions included in different blocks.
Verify that, when using an on-chain oracles, the smart contract is able to pause the operations based
0 on the oracle's result (in case of oracle has been compromised).
Verify that the external contracts (even trusted) that are allowed to change the attributes of the smart
contract (e.g. token price) have the following limitations implemented: a thresholds for the change (e.g.
0
no more/less
Verify that thethan 5%)
smart and a attributes
contract limit of updates (e.g.
that can beone update
updated byper
the day).
external contracts (even trusted) are
monitored (e.g. using events) and the procedure of incident response is implemented (e.g. the
0
response to an ongoing attack).
Verify that the complex math operations that consist of both multiplication and division operations firstly
0 perform the multiplications and then division.
Verify that, when calculating conversion price (e.g. price in ETH for selling a token), the numerator and
denominator are multiplied by the reserves (see the getInputPrice function in UniswapExchange
0
contract as an example).
https://github.com/sirhashalot/SCV-List