└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # smart-contracts-audit-checklist 2 | 3 | ### **General Security** 4 | - [ ] **Audit**: Has the contract been reviewed by a third-party security audit? 5 | - [ ] **Review external contracts**: Does the contract interact securely with other external contracts? 6 | - [ ] **Check admin permissions**: Are administrative functions restricted to authorized users only? 7 | - [ ] **Secure contract upgrade process**: Is there a secure method for upgrading or migrating the contract? 8 | 9 | ### **Input Validation** 10 | - [ ] **Validate user inputs**: Are all inputs from users properly validated to prevent issues like **injection** or **overflows**? 11 | - [ ] **Reentrancy**: Is the contract vulnerable to **reentrancy attacks**? Ensure functions update their internal state before making external calls. 12 | - [ ] **Test for Reentrancy**: Use automated tools like Slither to test for reentrancy vulnerabilities. Ensure functions update internal state before making external calls. 13 | - [ ] **Validate All Inputs**: Ensure all user inputs, including transaction amounts, addresses, and IDs, are validated to avoid common issues like overflow, underflow, or invalid entries. 14 | - [ ] **Test Invalid or Out-of-Order Transactions**: Test the contract’s ability to handle invalid transaction sequences, especially grouped transactions. 15 | 16 | ### **Access Control** 17 | - [ ] **Check access restrictions**: Are only authorized users able to access critical functions or sensitive data? 18 | - [ ] **Correct function visibility**: Are functions marked with the correct visibility (`private`, `internal`, `public`)? 19 | - [ ] **Admin function protection**: Are critical administrative functions like `mint`, `burn`, and `pause` properly secured? 20 | - [ ] **Check Ownership and Admin Privileges**: Ensure that only authorized addresses can perform critical operations like minting, burning, staking, and withdrawal. 21 | - [ ] **Multisig Program**: Implement multisig mechanisms for key administrative operations to prevent malicious actions by a single admin. 22 | - [ ] **Role-based Function Access**: Test if the contract properly limits access to certain functions based on roles, like signatory and validator. 23 | 24 | ### **Integer Overflows/Underflows** 25 | - [ ] **Validate arithmetic calculations**: Are all arithmetic operations protected from **overflows** and **underflows**? Is `SafeMath` or equivalent being used? 26 | 27 | ### **Timestamp Dependency** 28 | - [ ] **Check usage of `block.timestamp`**: Does the contract rely on `block.timestamp` in a way that could be manipulated by miners? 29 | 30 | ### **Time-Based Attacks** 31 | - [ ] **Timestamp Dependence**: Check for reliance on `block.timestamp` and ensure it cannot be manipulated by miners to gain unfair advantages. 32 | - [ ] **Pool Start and End Date Validation**: Confirm that pool start dates are properly validated to prevent issues where a pool starts in the past. 33 | 34 | ### **Arithmetic Safety** 35 | - [ ] **Integer Overflow and Underflow**: Verify that arithmetic operations in the contract are protected using libraries like `SafeMath` or similar mechanisms. Check for missing underflow protection as identified in Yieldly audits. 36 | 37 | ### **Governance** 38 | - [ ] **DAO and Governance Attacks**: Test for possible governance manipulation where attackers could execute critical actions like upgrading contracts, minting new tokens, or changing protocol rules. 39 | - [ ] **Threshold Validation for Voting**: Verify that threshold limits are properly defined and applied in voting mechanisms for signatory and validator roles. 40 | 41 | ### **External Call Failures** 42 | - [ ] **Validate external calls**: Does the contract properly check the return values of external calls to ensure execution halts on failure? 43 | - [ ] **Call and Delegatecall**: Are functions using `call()` or `delegatecall()` implemented securely to avoid malicious code execution? 44 | - [ ] **Unchecked External Calls**: Ensure that external calls are properly validated and that the contract does not proceed after failed external calls. 45 | - [ ] **Proxy Contract Validation**: Verify that the contract utilizes proxy contracts securely. Ensure that transactions routed through the proxy cannot be bypassed. 46 | 47 | ### **Gas Manipulation** 48 | - [ ] **Gas limits**: Are contract functions designed to stay within gas limits? Are long-running loops avoided to prevent gas exhaustion? 49 | - [ ] **Efficient gas usage**: Ensure that gas is not wasted unnecessarily, particularly in critical functions. 50 | 51 | ### **Token Management** 52 | - [ ] **ERC20/721 compliance**: Are the token contracts (ERC20, ERC721) following the proper standards? 53 | - [ ] **Transfer permissions**: Can transfer functions be manipulated? Does the contract handle permissions and limits correctly? 54 | 55 | ### **Insecure Randomness** 56 | - [ ] **Randomness generation**: If the contract generates random numbers, are they generated securely to avoid manipulation? 57 | 58 | ### **Denial of Service (DoS)** 59 | - [ ] **Test DoS resistance**: Can the contract be locked or rendered unusable by malicious transactions that consume excessive gas or halt critical functions? 60 | - [ ] **Loops in functions**: Ensure that functions looping over arrays or lists do not allow attackers to exhaust gas limits. 61 | 62 | ### **State Management** 63 | - [ ] **Storage and data access**: Ensure the contract is storing and accessing data efficiently. 64 | - [ ] **State updates**: Does the contract correctly update its state after each transaction? 65 | 66 | ### **Front-running Attacks** 67 | - [ ] **Prevent front-running**: Can important transactions be manipulated or reordered by front-running attacks? 68 | 69 | ### **Phishing Attacks** 70 | - [ ] **Protect against phishing**: Test how the contract handles interactions with user interfaces that may deceive users. 71 | 72 | ### **Randomness Vulnerabilities** 73 | - [ ] **Test randomness sources**: Are random numbers generated using secure and unpredictable sources to prevent manipulation? 74 | 75 | ### **Emergency Functions** 76 | - [ ] **Implement Emergency Withdraw**: Confirm that users have access to emergency withdrawal functions to recover funds if a contract enters an unexpected state. Ensure admin privileges on emergency actions are not overly restrictive. 77 | 78 | ### **Staking, Pools, and Rewards** 79 | - [ ] **Reward Calculation Verification**: Test if staking rewards and pool ratios are calculated correctly after staking and withdrawing actions. Ensure that updates to rewards are triggered as expected. 80 | - [ ] **Dynamic Testing for Pool Operations**: Perform dynamic tests to ensure that pool ratios and user claimable amounts are updated correctly. 81 | 82 | ### **Oracle Manipulation** 83 | - [ ] **Secure oracle usage**: If the contract relies on external oracles, are they protected against manipulation? 84 | - [ ] **Secure Randomness**: Ensure that random number generation is not predictable or manipulable, especially in lottery or staking functionalities. 85 | - [ ] **Oracle Manipulation**: Test contracts for potential oracle manipulation that could lead to pricing or staking rewards being incorrectly calculated. 86 | 87 | ### **OWASP-related Vulnerabilities for Smart Contracts** 88 | - [ ] **Proper data validation**: Are inputs and outputs validated properly to prevent data integrity issues? 89 | - [ ] **Correct cryptography implementation**: Are cryptographic methods and hashing applied according to best practices? 90 | - [ ] **Access control and authentication**: Are there any vulnerabilities allowing unauthorized users to access restricted functions? 91 | - [ ] **Injection mitigation**: Ensure the contract is not vulnerable to data or command injection. 92 | 93 | ### **Manual Testing Considerations** 94 | - [ ] **Admin Bypass Testing**: Attempt to bypass admin privileges or role restrictions by manipulating function parameters or transaction sequences. 95 | - [ ] **Test Role-based Enhancements**: Verify that role-based enhancements are structured properly, ensuring that only authorized users can perform specific actions. 96 | 97 | ### **Tools to Automate Smart Contract Testing** 98 | - [ ] **MythX**: Automatically analyze contracts for common vulnerabilities. 99 | - [ ] **Slither**: Detect logic vulnerabilities, reentrancy issues, and gas optimizations. 100 | - [ ] **Manticore**: Symbolic execution and fuzzing tool for smart contracts. 101 | - [ ] **Oyente**: Static analyzer to find issues like reentrancy, uncontrolled loops, and others. 102 | 103 | ### **Smart Contract Best Practices** 104 | - [ ] **Adhere to Versioning**: Ensure the contract explicitly defines the Solidity or Algorand version (`pragma version`) being used to avoid unintended behavior during compilatio. 105 | - [ ] **Boundaries for Function Parameters**: Check that input values for functions have well-defined boundaries, such as ensuring array sizes or transaction amounts are reasonable. 106 | --------------------------------------------------------------------------------