# Audit preparation

Author: Frances He
Notice: IN PROGRESS

# Section 1: Auditing: The client's perspective
## Preparing for audit:
1. Documentation:
example: 0X Protocol
2. Clean Code:
a. Run a linter:
- fix any erros or warnings unless have a good reason not to.
- For solidity, recommend linter:
- https://www.npmjs.com/package/ethlint
- https://github.com/PaulRBerg/hardhat-template
b. if the compiler address any warnings, address them
c. Remove any comments in which indicate unfinished work(TODO or FIXME)
d. Remove any code that has been commented out
e. Remove any code you don't need
f. Add helpful comments: explain the intent
g. Using Natspec(https://docs.soliditylang.org/en/v0.8.10/natspec-format.html)natural specification comments.
3. Testing:
* a. A good test is a test suite with 100% code coverage.
* https://en.wikipedia.org/wiki/Code_coverage
* b. **IMPORTANT ** You README should give clear instructions for running the test suite.
4. Automated Analysis:
Some good security analysis tools which help to find most common issueL
* MythX suites(https://mythx.io) is a good start
* [Ethereum Smart Contract Best Practices](https://consensys.github.io/smart-contract-best-practices/security-tools/)
* Useful plugins for Remix such as Mythx
* In VScode [Solidity Metrics](https://marketplace.visualstudio.com/items?itemName=tintinweb.solidity-metrics)gives useful info
* The [Solidity 2 UML tools ](https://github.com/naddison36/sol2uml) is good for visualisation
*
6. Frozen code
7. **Use a checklist**:
* [Audit prep checklist](https://gist.github.com/maurelian/13831f1940340e0dcd0482555eb5c4fe)

## More reference
* https://scsfg.io/developers/deployment/
* [Simple security toolkit](https://github.com/nascentxyz/simple-security-toolkit)

# Section 2: The following is from auditor's pespective
## The process:
* phase 1: audit or audits. current we partner with Runtime Verification.
* Phase 2: Remediation Period: the client will get the audit report, and report fixes in which will be verified and documented by the team.
* phase 3: followed by a well funded bug bounty program that is open for sufficient time to build confidence in project: => 7 days,$ X reward

## code freeze

## Request from auditor:
* The auditor will request a commit and stick to it.
* Statement of intended behaviro:
* a succint doc which outlines the goal of the application, what is allowed and what is prevented.
* Team efforts: engineering + business => input from business would also bring clearer view of ** how the system should behave**.
* What the specs should include:
* Goal of the application
* Main flow
* The actors/roles and why they do
* Access restrictions
* Failure states to be avoided

## Specifying the intended behavior

## Categorization of the severity
* The most prominent of these is the OWASP(Open Web Application security Project) risk classification standards, which is used by the Ethereum Foundation.
* OWASP:
* Risk = Likelihood * impact

## Methodology:
* increase the probability of finding bugs

## Bug bounty program
* why:
* evan valuable after audits and formal verificaiton

## Estimating and price quote
* while assessing key factors that affect the actual hours, line count(quantity) could be poor indicator but rather ** Complexity**
is a better indicator of actual time required for audit process.
* the following are good indicators:
* the number of external calls: eg. what if you call untrusted contracts
* the count of public/external functions: These are the points of entry. Execution starts from here. They will determine the number of paths possible during execution
* Use of solidity Assembly:
* which takes longer to audit
* Code is harder to read

## bug bouty:
* In bug bounties, the hunters tend to look for critical bug but **not**
look over the whole codebase. They are most likely to spend time in which areas at high risk.