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:
Project architecture review
Project documentation review.
General code review.
Reverse research and study of the project architecture based on the source code alone.
Build an independent view of the project's architecture.
Identify logical flaws.
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.).
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.
Detect inconsistencies with the desired model.
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.
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.
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.
Verify the fixed code version with all the recommendations and its statuses.
Provide the Customer with a re-audited report.
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.
Conduct the final check of the code deployed on the mainnet.
Provide the Customer with a public audit report.
See Public Audit Reports
What data does an audit report include?
The report describes all types of logical errors, inconsistencies, and vulnerabilities detected through the audit, as well as recommendations to address each of them.
Is the report confidential?
Yes, we always provide a confidential original audit report, so that you can correct any errors found. With your permission, we would like to publish a report on our blog. We strongly recommend to make your report public, as this demonstrates increased security to your partners.
What are overall costs and conditions?
Audit timing and costs depend on its complexity and code volume. We will promptly prepare a full quotation after you contact us and provide the code. It is impossible to determine the terms of the audit without examining the code.
How do the parties interact during the audit?
For large projects we provide updates every 2 weeks. If there are critical and major errors, we immediately give notifications via GitHub.