Security Audit Methodology

A group of security engineers are involved in working on the audit. The security engineers check the provided source code independently of each other in accordance with the methodology described below:

1. Project architecture review

• Project documentation review.

• General code review.

• Reverse research and study of the project architecture based on the source code alone.

Stage goals:

• Build an independent view of the project's architecture.

• Identify logical flaws.

2. Checking the code in accordance with the vulnerabilities checklist

• Manual code check for the vulnerabilities listed on the Contractor's internal checklist. The Contractor's checklist is constantly updated based on the analysis of hacks, research, and audit of the clients' codes.

• Code check with the use of static analyzers (i.e., Slither, Mythril, etc.).

Stage goal:

• Eliminate typical vulnerabilities (e.g., reentrancy, gas limit, flash loan attacks, etc.).

3. Checking the code for compliance with the desired security model

• Detailed study of the project documentation.

• Examination of contracts tests.

• Examination of comments in the code.

• Comparison of the desired model obtained during the study with the reversed view obtained during the blind audit.

• Exploits PoC development with the use of such programs as Brownie and Hardhat.

Stage goal:

• Detect inconsistencies with the desired model.

4. Consolidation of the auditors' interim reports into one

• Cross-check: each auditor reviews the reports of the others.

• Discussion of the issues found by the auditors.

• Issuance of an interim audit report.

Stage goals:

• Double-check all the found issues to make sure they are relevant and the determined threat level is correct.

• Provide the Customer with an interim report.

5. Bug fixing & re-audit

• The Customer either fixes the issues or provides comments on the issues found by the auditors. Feedback from the Customer must be received on every issue/bug so that the Contractor can assign them a status (either "fixed" or "acknowledged").

• Upon completion of bug fixing, the auditors double-check each fix and assign it a specific status, providing a proof link to the fix.

• A re-audited report is issued.

Stage goals:

• Verify the fixed code version with all the recommendations and its statuses.

• Provide the Customer with a re-audited report.

6. Final code verification and issuance of a public audit report

• The Customer deploys the re-audited source code on the mainnet.

• The Contractor verifies the deployed code with the re-audited version and checks them for compliance.

• If the versions of the code match, the Contractor issues a public audit report.

Stage goals:

• Conduct the final check of the code deployed on the mainnet.

• Provide the Customer with a public audit report.