Audit Process Details

Our Auditing Process Explained

Step 1: Free Initial Consultation

We arrange a call for an initial discussion with the customer. The discussion is usually general and we ask some generic questions about their basic smart contract business logic, preferred timeline and any specific pain point that we should be aware beforehand.

Step 2: Scope Details Gathering

After initial consultation round, we email client the common questionnaire form, which they need to fill-up and send us back to us. Though, it is not mandatory to answer all questions, but more information the client will provide via our questionnaire form, more it will helps us to estimate the approximate timeline and price estimation for auditing.

Once the interested client submits the scoping details via form submission, we take maximum 24 hours (excluding holidays) from our side to get back to the client at provided contact information with estimated timeline and pricing.

Below are the questions which client need to answer via form submission

Q1: Please upload and commit the code on github, and share with us the link

Q2: How many contracts are in scope?

Q3: How many external imports are there?

Q4: How many separate interfaces and struct definitions are there for the contracts within scope?

Q5: Does most of your code generally use composition or inheritance?

Q6: How many external calls?

Q7: Are automated test cases provided?

Q8: Test Coverage Percentage?

Q9: Does Automated Tests cases include integration test, or unit test, or both?

Q10: Is there a need to understand a separate part of the codebase / get context in order to audit this part of the protocol? If so, please describe required context:

Q11: Does it use an oracle? If so, explain briefly.

Q12: Does the token confirm to the ERC20 standard?

Q13: Which category your smart contract business logic generally falls into? For example: DEFI, NFT, DAO, Play-to-Earn or mixture of all?

Q14: Is it a fork of a popular project? If so, provide link of that forked project

Q15: Does it use rollups?

Q16: Is it multi-chain?

Q17: Does it use a side-chain?

Q18: Total no. of lines in the code?

Q19: Any common automated auditing tool you run?If yes, request you to let us know the tools.

Q20: Request you to provide your preferred contact information via which we should contact you back. It could be email, phone, discord, telegram, skype or other.

Q21: Request you to provide your Polygon chain Wallet Address for the purpose of receiving NFT certificate.

Q22: Request you to choose your preferred auditing level: (Dropdown) Tier-I, Tier-II, TIER-III

Step 3: Agree on Scope of Work and Timeline

If after Step-2, the client agrees with the timeline and our scope of audit, we start our audit process.

Step 4: Reviewing Automated Test Cases

This is related to our internal audit process. We first read and review the automated test cases provided by the client.
This helps us to get a good grasp on overall business and logical flow of the contract. This especially helps us in Tier-II and Tier-III level audits.

Step 5: Identify Vulnerability

After Step-4, we began auditing. Remember ,by this stage we freeze the client's final committed code. After this, we do not accept any updated code until we share our initial audit report. If in between, a client needs to update his/her code, we have to again go to Step 3.

First, we do a manual audit. We have our own checklist that we go through. Once we're done with the manual audit, we run some of the automated tools to verify our findings.

We do a manual check first and then automated tools to detect missed issues instead of the other way around. It helps maintain a good workflow so that the results generated by automated tools do not mislead our own judgment. These audit tools are also new and fickle, yielding false positives from time to time. So we mostly rely on manual auditing.

We also believe that the smart contract developer must have run some popular automated tools himself and could fixed these common problems.

So we mostly rely on our manual audit process. To know more about what we mainly check in our audit process, we ask you to refer to our sample audit report.

Some of the automated tools that we mostly uses are :

Slither
Mythril
Surya

Step 6: Share Initial Audit Report to Client

Once we have completed step 5, we share our initial findings report with the client. In the report itself the client must fill in which findings he accepted and which he rejected. They are free to refuse or accept. There is no hard and fast rule in smart contract auditing. Some of our findings may be subjective, and it depends on the context. Some findings involve compromises/trade-offs

Step 7: Vulnerability Fix by Client

Whatever findings the client accepts in step 6, it must update the code accordingly. Once they do, they need to share the updated code again. We will then review these updated changes again.

Step 8: Re-Audit by us

After the client has updated the code based on our findings in Step 7, we review the code again.

Step 9: Final Audit Report Submission

We will then forward the final updated audit report to the client.

About Our Auditing Tiers:

We have divided our auditing process in three tiers:

About Dolphin Package :

This is the Tier-III package. You can choose this particular package separately. The pricing will be lowest, and timeline of auditing would also be less. All the gas optimization and quality related Low Risk, Non-Critical, Informational findings will be provided.

Gas optimization in smart contract refers to techniques and strategies that are used to minimize the amount of gas required to execute a contract, thus reducing the overall cost of executing the contract. This can be achieved in several ways.

Optimizing gas consumption is an important aspect of smart contract development, as it can greatly reduce the cost of executing the contract and make it more cost-effective for users.

Information issues or low-risk findings are categories of issues that are typically related to maintaining a proper coding standard and readability of the contract. This is an important aspect. Because in most cases smart contracts are not isolated entities. It usually interacts with several other external smart contracts. Without proper standardized structures, there is a high probability that a given smart contract might misbehave or fail to reach its desired objective.

It's Free for limited Time

Apply for Tier-III Audit Now

About Whale Package :

This is the Tier-II package. We cover both Tier-III and Tier-II with this package. We have already discussed Tier-III above.

On top of that, we cover medium risk findings in this package. Medium risk findings are those vulnerabilities that could damage the contract desired objective under certain context or scenarios.

About Octopus Package :

This is the Tier-I package. This package also includes Tier-III and Tier-II package. We have already discussed the Tier-III and Tier-II package above.

On top of that, we cover high risk critical vulnerabilities in this package. Critical issues that could seriously damage the integrity of the contract.

Any bug that would allow attackers to steal tokens is a critical issue. For example, a loosely coupled access control mechanism could lead to critical or high-risk problems.

If you choose this package, the price will be the highest among all other packages and the audit timeline will also be more.

After successful completion of auditing,we award our client with Soul-bound NFT certificate which is non-transferrable. These helps clients to showcase to their investors or users that their smart contracts are vulnerabilities proof.

These NFT certificates are created according to the images of various tiers mentioned above.

It will contain important unique metadata like client_name , tier_type and batch_no.

The main reason we have divided our audit process into three levels is that each of these three levels of vulnerability requires a different mindset, timeline and skills.

And sometimes it's a compromise between levels. For example, it could be the case that the client would be more interested in saving or reducing transactions gas costs to attract more users, but then some security aspects could be lost in the form of extra checks and balances or vice versa.

Disclaimer