checklist for secure smart contract development

CHECKLIST FOR SECURE SMART CONTRACT DEVELOPMENT WWW.LBMSOLUTIONS.IN

1. Create a new GitHub organization to exclusively house production-related contracts. For example, our repo is parity-contracts. All contracts in this dedicated repo should be actively maintained or in use, or be under active development for production. There should be no obsolete or legacy projects in this repo. 2. Put every contract in a separate repo in your new dedicated organization. (“Every contract” can also mean a “logical unit” of a few tightly coupled contracts—for example Operations.sol and OperationsProxy.sol, which clearly go together and cannot be reasonably expected to be used separately.) 3. Embed dependencies to make the code coverage metric more meaningful and make it easier to programmatically reason about the contract’s entire codebase. All duplicated sources should be explicitly listed as such (with cross-links!) in every repo’s README they’re copied into. WWW.LBMSOLUTIONS.IN

4. Ensure every contract repo has its up-to-date bytecode and API in master branch. It is the duty of the PR submitter to ensure that API and bytecode are updated appropriately. 5.Every contract should have a README that lists its deployment addresses in all networks. Where applicable, that address should link to a blockchain-exploring service (e.g., Etherscan), which should contain a “verified code” tab for this address and contract source. 6. Ensure the README contains a separate “Update Strategy” section. In that section, enumerate what needs to be done to properly do a (possibly security- critical) update to the contract. WWW.LBMSOLUTIONS.IN

7. At the top of the README, put a clear indication of the “production readiness” state of the contract (like a badge): - alpha — contracts which are under active development and may not yet be in proper shape. - beta — contracts which are feature-ready and possibly ready for testnet use, but are not yet audited. These SHOULD NOT be used on the mainnet. - stable — contracts that are properly audited, deployed to mainnet, and are in active use. - deprecated — contracts no longer supported and used, but you want to keep around for some reason. (Avoid keeping these around! Deleting a repository is almost always a better idea, if only to discourage other parties from repeating your possible mistakes.) 8. Incorporate all the applicable points into a PULL_REQUEST_TEMPLATE.md file in the repo. Format this file as a checklist. It is the submitter’s duty to ensure all checkboxes are checked prior to merging. WWW.LBMSOLUTIONS.IN

9. Ensure every contract’s main file has its URL in the comment header section. This is to make it possible for anyone to trace the code back to the repo, even when copying or re-hosting the code. 10. Ensure contracts have view or pure functions (or just public constant definitions, which would create corresponding getters automatically) with contract_name and contract_version defined. Those functions should have the following properties: a. contract_name should correspond to the organization/repository part of the repository. Because we’re following a “one contract per repo” policy, this identifier should be unique enough. b. contract_version should contain monotonically increasing integer versions. It’s mandatory to bump this version in every PR to master. 11. Ensure deployed versions on master have matching versioned git tags (gpg-signed if possible). These tags should be created/uploaded only after the actual deployment happened in order to not wipe out tags during possible redeployment cycles (especially possible in complicated migration cases). 12. Ensure each contract repo has a clearly defined license. WWW.LBMSOLUTIONS.IN

LBM Solutions is the most reputable Smart Contract Development Company, providing the best Smart Contract Development to assist businesses in improving their operations. WWW.LBMSOLUTIONS.IN