├── .gitignore ├── LICENSE.md ├── README.md ├── TEMPLATE.md └── UTILS.md /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | MIT license 2 | 3 | Copyright (C) 2016 Miguel Mota 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy of 6 | this software and associated documentation files (the "Software"), to deal in 7 | the Software without restriction, including without limitation the rights to 8 | use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies 9 | of the Software, and to permit persons to whom the Software is furnished to do 10 | so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 |

2 |
3 | Solidity Audit Checklist 4 |
5 |
6 |
7 |

8 | 9 | > A checklist of things to look for when auditing Solidity smart contracts. 10 | 11 | This is not a comprehensive list and solidity is quickly evolving so please do due dilegence on your part. 12 | 13 | Not all listed items will apply to your specific smart contract. 14 | 15 | In no particular order: 16 | 17 | - [ ] All functions are `internal` except where explictly required to be `public`/`external`. [[?](https://blog.zeppelin.solutions/on-the-parity-wallet-multisig-hack-405a8c12e8f7)] 18 | - [ ] There are no arithmetic overflows/underflows in math operations. 19 | - [ ] Using the OpenZeppelin safe math library [[?](https://github.com/OpenZeppelin/openzeppelin-solidity/tree/master/contracts/math)]. 20 | - [ ] Ether or tokens cannot be accidentally sent to the address `0x0`. 21 | - [ ] Conditions are checked using `require` before operations and state changes. 22 | - [ ] State is being set before and performing actions. 23 | - [ ] Protected from reentry attacks (A calling B calling A). [[?](https://medium.com/@gus_tavo_guim/reentrancy-attack-on-smart-contracts-how-to-identify-the-exploitable-and-an-example-of-an-attack-4470a2d8dfe4)] 24 | - [ ] Properly implements the ERC20 interface [[?](https://github.com/ethereum/eips/issues/20)]. 25 | - [ ] Only using modifier if necessary in more than one place. 26 | - [ ] All types are being explicitly set (e.g. using `uint256` instead of `uint`). 27 | - [ ] All methods and loops are within the maximum allowed gas limt. 28 | - [ ] There are no unnecessary initalizations in the constructor (remember, default values are set). 29 | - [ ] There is complete test coverage; every smart contract method and every possible type of input is being tested. 30 | - [ ] Performed fuzz testing by using random inputs. 31 | - [ ] Tested all the possible different states that the contract can be in. 32 | - [ ] Ether and token amounts are dealt in wei units. 33 | - [ ] The crowdsale end block/timestamp comes after start block/timestamp. 34 | - [ ] The crowdsale token exchange/conversion rate is properly set. 35 | - [ ] The crowdsale soft/hard cap is set. 36 | - [ ] The crowdsale min/max contribution allowed is set and tested. 37 | - [ ] The crowdsale whitelisting functionality is tested. 38 | - [ ] The crowdsale refund logic is tested. 39 | - [ ] Crowdsale participants are given their proportional token amounts or are allowed to claim their contribution. 40 | - [ ] The length of each stage of the crowdsale is properly configured (e.g. presale, public sale). 41 | - [ ] Specified which functions are intented to be controlled by the owner only (e.g. pausing crowdsale, progressing crowdsale stage, enabling distribution of tokens, etc..). 42 | - [ ] The crowdsale vesting logic is tested. 43 | - [ ] The crowdsale has a fail-safe mode that when enabled by owner, restricts calls to function and enables refund functionality. 44 | - [ ] The crowdsale has a fallback function in place if it makes reasonable sense. 45 | - [ ] The fallback function does not accept call data or only accepts prefixed data to avoid function signature collisions. 46 | - [ ] Imported libraries have been previously audited and don't contain dyanmic parts that can be swapped out in future versions which can be be used maliciously. [[?](http://swende.se/blog/Devcon1-and-contract-security.html)] 47 | - [ ] Token transfer statements are wrapped in a `require`. 48 | - [ ] Using `require` and `assert` properly. Only use `assert` for things that should never happen, typically used to validate state after making changes. 49 | - [ ] Using `keccak256` instead of the alias `sha3`. 50 | - [ ] Protected from ERC20 short address attack. [[?](https://vessenes.com/the-erc20-short-address-attack-explained/)]. 51 | - [ ] Protected from recursive call attacks. 52 | - [ ] Arbitrary string inputs have length limits. 53 | - [ ] No secret data is exposed (all data on the blockchain is public). 54 | - [ ] Avoided using array where possible and using mappings instead. 55 | - [ ] Does not rely on block hashes for randomness (miners have influence on this). 56 | - [ ] Does not use `tx.origin` anywhere. [[?](https://vessenes.com/tx-origin-and-ethereum-oh-my/)] 57 | - [ ] Array items are shifted down when an item is deleted to avoid leaving a gap. 58 | - [ ] Use `revert` instead of `throw`. 59 | - [ ] Functions exit immediately when conditions aren't meant. 60 | - [ ] Using the latest stable version of Solidity. 61 | - [ ] Prefer pattern where receipient withdrawals funds instead of contract sending funds, however not always applicable. 62 | - [ ] Resolved warnings from compiler. 63 | 64 | 65 | ## Resources 66 | 67 | - [Smart contract best pracitices](https://github.com/ConsenSys/smart-contract-best-practices) 68 | - [Solidity idiosyncrasies](https://github.com/miguelmota/solidity-idiosyncrasies) 69 | - [Solidity security considerations](http://solidity.readthedocs.io/en/develop/security-considerations.html) 70 | - [Methodological security review of a smart contract](https://ethereum.stackexchange.com/questions/8551/methodological-security-review-of-a-smart-contract) 71 | - [List of helper/utility functions](./UTILS.md) 72 | 73 | ## License 74 | 75 | MIT -------------------------------------------------------------------------------- /TEMPLATE.md: -------------------------------------------------------------------------------- 1 | ## Disclaimer 2 | 3 | The audit makes no statements or warrantees about utility of the code, safety of the code, suitability of the business model, regulatory regime for the business model, or any other statements about fitness of the contracts to purpose, or their bug free status. The audit documentation is for discussion purposes only. 4 | 5 | ## Synopsis 6 | 7 | The focus of this review was to ensure the following properties: 8 | 9 | Security: identifying security related issues within each contract and within the system of contracts. 10 | 11 | Sound Architecture: evaluation of the architecture of this system through the lens of established smart contract best practices and general software best practices. 12 | 13 | Code Correctness and Quality: a full review of the contract source code. The primary areas of focus include: 14 | 15 | - Correctness (does it do was it is intended to do) 16 | - Readability (how easily it can be read and understood) 17 | - Sections of code with high complexity 18 | - Improving scalability 19 | - Quantity and quality of test coverage 20 | 21 | ## Severity of Findings 22 | 23 | ### Critical 24 | 25 | Critical issues are directly exploitable bugs or security vulnerabilities. 26 | 27 | Left unaddressed these issues are highly likely or guaranteed to cause major problems or potentially a full failure in the operations of the contract. 28 | 29 | ### Major 30 | 31 | Major issues will be things like bugs or security vulnerabilities. These issues may not be directly exploitable, or may require a certain condition to arise in order to be exploited. 32 | 33 | Left unaddressed these issues are highly likely to cause problems with the operation of the contract or lead to a situation which allows the system to be exploited in some way. 34 | 35 | ### Medium 36 | 37 | Medium issues are generally objective in nature but do not represent actual bugs or security problems. 38 | 39 | These issues should be addressed unless there is a clear reason not to. 40 | 41 | ### Minor 42 | 43 | Minor issues are generally subjective in nature, or potentially deal with topics like "best practices" or "readability". Minor issues in general will not indicate an actual problem or bug in code. 44 | 45 | The maintainers should use their own judgement as to whether addressing these issues improves the codebase. 46 | 47 | ## Summary 48 | 49 | Brief summary of audit. 50 | -------------------------------------------------------------------------------- /UTILS.md: -------------------------------------------------------------------------------- 1 | # Utils 2 | 3 | > some utils/helpers for when auditing 4 | 5 | ## File count of solidity files 6 | 7 | ```bash 8 | $ find . -name '*.sol' | wc -l 9 | 70 10 | ``` 11 | 12 | ## Lines of code per solidity file 13 | 14 | ```bash 15 | $ find . -name '*.sol' | xargs wc -l 16 | 48 ./contracts/token/ExampleToken.sol 17 | 116 ./contracts/whitelist/Whitelist.sol 18 | 23 ./contracts/Migrations.sol 19 | 284 ./contracts/models/LinearSale.sol 20 | 176 ./contracts/vesting/DiscreteVesting.sol 21 | 107 ./contracts/vesting/ContinuousVesting.sol 22 | 23 | ... 24 | 25 | 31 ./node_modules/zeppelin-solidity/contracts/LimitBalance.sol 26 | 35 ./node_modules/zeppelin-solidity/contracts/MerkleProof.sol 27 | 28 ./node_modules/zeppelin-solidity/contracts/AddressUtils.sol 28 | 4371 total 29 | ``` 30 | 31 | ## Number of external calls in solidity files 32 | 33 | ```bash 34 | $ egrep '\.\w*\(.*\)' contracts/* -nr 35 | contracts/Migrations.sol:1:pragma solidity ^0.4.17; 36 | contracts/Migrations.sol:8: if (msg.sender == owner) _; 37 | contracts/Migrations.sol:12: owner = msg.sender; 38 | contracts/Migrations.sol:21: upgraded.setCompleted(last_completed_migration); 39 | contracts/models/LinearSale.sol:1:pragma solidity ^0.4.21; 40 | contracts/models/LinearSale.sol:3:import 'zeppelin-solidity/contracts/math/SafeMath.sol'; 41 | 42 | ... 43 | 44 | contracts/models/LinearSale.sol:176: uint256 tokensRemaining = totalTokensDistributable.sub(numTokensDistributed); 45 | contracts/models/LinearSale.sol:177: uint256 weiRemaining = totalWeiReceivable.sub(totalWeiCollected); 46 | contracts/models/LinearSale.sol:178: return endRate.add(TWO.mul(tokensRemaining.sub(previousWeiSubmitted.mul(previousRate)).sub(endRate.mul(weiRemaining))).div(weiRemaining)); 47 | contracts/models/LinearSale.sol:185: require(block.timestamp > endTimestamp); 48 | ``` 49 | 50 | ## SHA256 hash of files 51 | 52 | ```bash 53 | $ shasum -a 256 contracts/*.sol 54 | 98a2f9cf3f6d74d71d23374f6b118f9a4ecc12e0b2b701f3b7ba1fb7d5bc8026 contracts/Migrations.sol 55 | ``` 56 | --------------------------------------------------------------------------------