# Intro [Stronghold](https://strongholdsec.io/) is a project that offers a unique hybrid approach to the smart contract audit process by combining the best practices of community-driven and conventional auditing. The community-driven model allows to allocate a large number of solo auditors (up to several dozens) to a project, which ensures maximum code coverage and the use of various audit techniques. This large-scale effect allows to check the maximum number of attack vectors and provides the customer with an exhaustive list of possible vulnerabilities, while the merit-based remuneration scheme in the form of a distributed bounty fund depending on the number of found vulnerabilities and their severity aligns a fair and balanced motivation for both parties. The approach, which is implemented in the conventional audit part, implies the allocation of a full-time Project manager and a Lead auditor to the project, who audit the project on an ongoing basis, provide a high level of service and completeness of communications with the customer, as well as simplify and facilitate communication with the solo auditors community, in terms of validation and triage of a large list of detected vulnerabilities, preparation of a single consolidated audit report, conducting the re-audit stage and issuing the final report. # Community of verified solo auditors Stronghold is not just another marketplace for solo auditors. When creating our community of solo auditors, we have sought to ensure that its members are engineers with high technical expertise and a desire to develop in the field of blockchain security and DeFi. Thus, we have partnered with the [MixBytes Farm](https://mixbytes.io/farm) team, who, through their free educational initiative and the “Smart Contract Auditor” bootcamp produce top-notch smart contract auditors who, upon successful completion of a 1.5-month course, become members of the Stronghold closed community of solo auditors. [MixBytes Farm](https://mixbytes.io/farm) key points: * The Smart Contract Auditor bootcamp program was developed by blockchain researchers, cryptographers, and practicing MixBytes auditors. * The bootcamp is held once a quarter. * The course lasts 1.5 months and includes 13 theoretical lectures on cryptography, blockchain security, and DeFi, as well as practical assignments in the form of CTF and test audits on real public DeFi projects. * On average, 800 applications for training are received, but after passing the entrance test, only up to 150 people enter the course itself (bootcamp), of which only 30-40 make it to the end. * Successful bootcamp graduates become the owners of the Soulbound token (SBT) as a confirmation of its successful completion and high graduation score. * The SBT entitles them to participate in audit contests conducted by Stronghold for its customers. # Soulbound token (SBT) Each successful graduate of MixBytes Farm and member of the Stronghold community is issued a Soulbound token (SBT), which records the entire history of its holder: graduation score from the bootcamp, the results for each audit conducted as part of Stronghold audit contests, the number of valid vulnerabilities detected and their severity level. To more clearly display the track record of each token holder (SBT holder) and solo auditor, a member of the Stronghold community, a [Leaderboard](https://strongholdsec.io/leaderboard/) has been created, which is dynamically updated after each completed audit contest. A more detailed description of SBT can be found [here](https://mixbytes.io/blog/an-overview-of-the-mixbytes-camp-soulbound-token). # Services Stronghold provides 2 formats of smart contract audit services: **Combo audit** is the main format of code review, which involves checking the entire code base by solo auditors of the Stronghold community and parallel checking by a dedicated full-time Lead auditor. Workflow: * The community of solo auditors, in parallel with the full-time Lead auditor, conducts an interim audit to detect all possible vulnerabilities. * Solo auditors provide the Lead auditor with their reports with a list of detected findings by the specified date. * The Lead auditor validates and triages all received bugs and generates a single interim audit report, which is provided to the Customer. * After receiving comments and bug fixing on the Customer’s side, the Lead auditor conducts a re-audit. * Upon completion of the re-audit, the Lead auditor provides the Customer with a final report. \ \ **Private audit** will be the most suitable format for those projects who are not willing to provide access to the smart contracts code to the broad community of solo auditors as part of an open and competitive contest, but who want to take advantage of a more conventional form of private audit with a dedicated experienced team limited by the number of participants to ensure best audit and service practices. Workflow: * The Customer signs NDA with the involved auditors of Stronghold and provides access to the private code base to be audited. * Stronghold estimates the scope, prepares a private audit proposal and selects a dedicated team of 3 full-time auditors (1 Lead auditor and 2 solo auditors from the Stronghold community who have the highest rating according to the [Leaderboard](https://strongholdsec.io/leaderboard/) and the most relevant experience in auditing protocols with similar business logic). * Stronghold ensures that the auditors involved have verified their identity using the eKYC tool and provides the necessary information to the Customer. * The dedicated team, consisting of 1 Lead auditor and 2 auditors, conducts an interim audit to detect all possible vulnerabilities and provides the Customer with an interim audit report. * After receiving the Customer's comments and bug fixing, the dedicated audit team performs a re-audit. * Upon completion of the re-audit, the dedicated audit team provides a final report to the Customer \*Stronghold can arrange an additional iteration of the Audit contest\Interim audit if, after providing an interim audit report to the Client and making changes to the initial code, the actual volume of the scope increases by more than 15% due to the addition of new logic and functionality of smart contracts. In this case, an additional contest\interim audit is to be carried out with the appropriate overhead payment.
# Audit-readiness check-list In order to evaluate the audit scope and get an estimate, the Customer must provide: * a link to the GitHub repository * a list of smart contracts to be audited * the target commit * (for diff audit) the initial commit - the commit from which the fork was made * (for diff audit) a link to the audit report for the initial commit For greater audit efficiency, it's desirable (but not mandatory): * running tests * documentation describing the protocol logic * natspec for functions in smart contracts * compliance with coding style for contracts The timing and budget of the audit contest are based on: * the number of code lines (empty lines, comments are not counted in the evaluation) * the use of known and audited libraries (e.g. OpenZeppelin, these contracts are excluded from the evaluation) * the degree of integration and interaction with other protocols and projects, both known and unknown. (The less interaction there is, the faster it is. The better known the project is, the faster it is.) * (for diff audit) the number and degree of changes to the original code base (small changes in large numbers will be studied faster than a complete rewrite of some contracts) # Lead time & Cost Each project is subject to individual estimation, but from the experience of past projects, the average timeline looks as follows: * Big Combo Audit: More than 3000 sloc\* / 4+ weeks (including triage and reaudit) * Medium Combo Audit: Up to 3000 sloc / 3 weeks (including triage and reaudit) * Small Combo Audit : Up to 1000 sloc / 2 weeks (including triage and reaudit) * Diff audit: 100 - 1000 sloc / up to 1 week. \*sloc (Source lines of code ) - number of lines of code without comments and blanks. The following items are taken into account when pricing an audit contest: * Bounty fund for the community of solo auditors * Lead auditor fee for interim audit, triage, re-audit, final report issuance
# Methodology As part of the ongoing audit contests, the solo auditors community utilizes the widest set of techniques to search for and detect potential vulnerabilities. This diversification, coupled with the unique mindset of each auditor, provides maximum coverage. However, if we aggregate the most commonly applied audition techniques, they can be summarized as follows: **General Code Assessment** The code is reviewed for clarity, consistency, style, and whether it follows code best practices applicable to the particular programming language used, such as indentation, naming convention, commented code blocks, code duplication, confusing names, irrelevant or missing comments, etc. This part is aimed at understanding the overall code structure and protocol architecture. Also, it seeks to learn overall system architecture and business logic and how different parts of the code are related to each other.\ \ **Code Logic Analysis** The code logic of particular functions is analyzed for correctness and efficiency. The code is checked for what it is intended for, the algorithms are optimal and valid, and the correct data types are used. The external libraries are checked for relevance and correspond to the tasks they solve in the code. This part is needed to understand the data structures used and the purposes for which they are used. At this stage, various public checklists are applied in order to ensure that logical flaws are detected. **Entities and Dependencies Usage Analysis** The usages of various entities defined in the code are analyzed. This includes both internal usage from other parts of the code as well as possible dependencies and integration usage. This part aims to understand and spot overall system architecture flaws and bugs in integrations with other protocols. **Access Control Analysis** Access control measures are analyzed for those entities that can be accessed from outside. This part focuses on understanding user roles and permissions, as well as which assets should be protected and how.
# Findings severity levels The audit contest is directed at identifying possible vulnerabilities in the project's code. The result of the audit is a report with a list of detected vulnerabilities ranked by severity level: | Severity | Description | | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | Critical | Vulnerabilities leading to the theft of assets, blocking access to funds, or any other loss of funds. | | High | Vulnerabilities that cause the contract to fail and that can only be fixed by modifying or completely replacing the contract code. | | Medium | Vulnerabilities breaking the intended contract logic but without loss of funds and need for contract replacement. | | Low | Minor bugs that can be taken into account in order to improve the overall quality of the code | After the stage of bug fixing by the Customer, the findings can be assigned the following statuses: | Status | Description | | ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Fixed | Recommended fixes have been made to the project code and no longer affect its security. | | Acknowledged | The Customer took into account the finding. However, the recommendations were not implemented since they did not affect the project's safety. |
# Flow of work The standard audit contest procedure is a sequence of the following steps to check the project code: 1. Stronghold launches an audit enlisting a group of experienced independent security researchers from our decentralized, networked community of solo auditors and setting up an audit contest with a bounty fund to have the project audited and all possible vulnerabilities detected. 2. Stronghold assigns a full-time Lead auditor, a member of our decentralized network who audits the code along with the group of solo auditors and who is in charge of audit process management. 3. Solo auditors check the project code on a competitive basis and submit vulnerabilities that affect its security along with additional recommendations on code improvements. 4. The Lead auditor triages and validates the vulnerabilities submitted by the participants in accordance with the approved methodology and prepares the unified interim audit report. 5. Customer fixes the bugs identified and provides feedback on each finding from the interim audit report. 6. The Lead auditor reaudits the code base after bug fixing and indicates the status of each finding. Customer has 10 business days for bug fixing. If fixes weren’t made within 10 business days after the provision with the interim audit report, Stronghold has the right to postpone the reaudit process for 20 business days (1 month). If fixes weren’t prepared within the additional 1 month, the reaudit stage would be skipped. If, during the reaudit process, new findings are detected, then the Client has 5 business days to fix them. Otherwise, the reaudit of new findings will be skipped. 7. The Lead auditor provides the final audit report upon completion of the reaudit. 8. Stronghold (upon Customer consent) uploads the final audit report on [GitHub Public Audits Repo](https://github.com/strongholdsec/audits) and makes an announcement on [Twitter](https://twitter.com/stronghold_dao).