Smart Contract Audit

Audit of smart contracts.
Basic principles

The security of smart contracts today is a very important part both at the development stage and the entire business process as a whole. When deploying a smart contract on the blockchain, all the security flaws, misbehavior and inefficiency of the contract are very costly to the creator. Smart contracts must be separate agreements, not subject to interpretation by third parties or jurisdictions.

image smart contract audit

The code itself is intended to be the ultimate arbiter of the "deal" it represents. Therefore, the importance of auditing smart contracts is simply impossible to overestimate. Wherever you order an audit of your project, there are basic points that you should know in order to avoid unauthorized expenses or elementary fraud. Below is a summary of the contract audit process - from preparatory work to the submission of a full audit report.

Preparatory work

    Conducting an audit

      For example:

      • Passing unit tests, checking the test configuration (compliance with the main network configuration);
      • Compiler warnings;
      • Race conditions. Re-entry. Cross-functional race conditions. Traps in solutions for race conditions;
      • Potential delays in data delivery;
      • Dependence of the transaction on the order (front launch);
      • Dependence on time stamp;
      • Integer overflow and underflow;
      • DoS with (unexpected) rollback;
      • DoS with blocking gas limitation;
      • Permissions to execute methods;
      • The influence of the exchange rate on logic;
      • Calling oracles;
      • Economic model. It is important to predict scenarios when the user receives additional economic motivation or is faced with restrictions. If the logic of the application is based on the wrong model of the economy, the application will not function correctly and the participants will suffer financial losses. This type of problem is most common in bonus reward systems.
      • Leaks of personal data of users.

      This report will be sent to you for full correction of all errors without exception, according to the recommendations provided by the executor. As a rule, we do not leave our clients alone with such a difficult task, and we comprehensively accompany and control the correction process.

      The smart contract audit report is your property, and you have every right to use it in any marketing activity, despite the fact that our logo is there.

      Specifically, we conduct audits in the following order:

      • Major coding errors: static analysis of a smart contract using our own static code analyzer for known coding errors, followed by manual verification of all problems detected by our tool.
      • Checking semantic consistency: manually checking the logic of the implemented smart contracts and comparing with the description in the Specification.
      • Advanced Analysis: Additional study of business logic, system operation and a thorough investigation of possible pitfalls and errors.
      • Additional Guidance: Provide additional coding and smart contract development suggestions in terms of proven coding practices.
      • Help in eliminating errors: if necessary, our specialists are involved in the process of eliminating the errors indicated in our report and perform the necessary work
      • Final code release: global testing of all code after fixing bugs and applying all our recommendations, followed by confirmation of the release of the verified project.

      To better describe each issue we identify, we classify the results using Common Weakness Enumeration (CWE-699), which is a community-developed list of types of software weaknesses.

      An example of such a list:

      Category Summary
      Configuration Weaknesses in this category are typically introduced during the configuration of the software.
      Data Processing Issues Weaknesses in this category are typically found in functionality that processes data.
      Numeric Errors Weaknesses in this category are related to improper calculation or conversion of numbers.
      Security Features Weaknesses in this category are concerned with topics like authentication, access control, confidentiality, cryptography, and privilege management. (Software security is not security software.)
      Time and State Weaknesses in this category are related to the improper management of time and state in an environment that supports simultaneous or near-simultaneous computation by multiple systems, processes, or threads.
      Error Conditions, Return Values, Status Codes Weaknesses in this category include weaknesses that occur if a function does not generate the correct return/status code, or if the application does not handle all possible return/status codes that could be generated by a function.
      Resource Management Weaknesses in this category are related to improper management of system resources.
      Behavioral Issues Weaknesses in this category are related to unexpected behaviors from code that an application uses.
      Business Logics Weaknesses in this category identify some of the underlying problems that commonly allow attackers to manipulate the business logic of an application. Errors in business logic can be devastating to an entire application.
      Initialization and Cleanup Weaknesses in this category occur in behaviors that are used for initialization and breakdown.
      Arguments and Parameters Weaknesses in this category are related to improper use of arguments or parameters within function calls.
      Expression Issues Weaknesses in this category are related to incorrectly written expressions within code.
      Coding Practices Weaknesses in this category are related to coding practices that are deemed unsafe and increase the chances that an exploitable vulnerability will be present in the application. They may not directly introduce a vulnerability, but indicate the product has not been carefully developed or maintained.

      This allows additional control of the auditor by the customer.

      Duration of audit

      The duration of the audit depends on the code you want to audit: its size, complexity, protocol, purpose, and the Specification provided. If the code is a simple bulk sale, well documented and planned in advance, it will take 10-15 business days.

      More complex contracts will take significantly longer. But at the time of the start of the audit, you will already know the exact estimate, since we determine it at the stage of preparatory work.

      Just to understand:

      • The simplest contracts for audit are ERC20, ERC721 tokens, as they must comply with the standard that limits its design. The complete chain and lack of ether transmission reduces the risk of attacks and the scope of vulnerabilities.
      • Fully chain-to-air contracts are slightly more difficult to verify as they are substandard. There are several implementations of open contracts that contract developers can follow, making the job easier by making the auditor familiar with the code. The complete chain still makes these contracts easy to audit.
      • Contracts with off-chain interactions are the most difficult to verify because they involve some important off-chain components. These can be oracles, channels, or anything else that is an important part of the flow of said contractual interaction.

      A complete audit of these contracts may be difficult or even impossible, as there may be some unreachable (off-chain) component that needs to be trusted in advance. However, even so, we can audit these contracts on the assumption that the specified parts can be trusted if this condition satisfies you.

      Conducting an audit

      Basic Coding Bugs

      Semantic Consistency Checks

      Advanced DeFi Scrutiny

      Additional Recommendations

      In the report itself, these checks are detailed.

      • Limitation of Liability. We have to be honest - an assessment based on a single audit is not a comprehensive one. Therefore, we always recommend running multiple independent audits and a public bug bounty program (BugBounty). This will allow you to ensure that your smart contract is as secure as possible.
      • Conclusions. You should receive a detailed description of exactly what problems were found in the contract, with a classification of the problem according to the severity level (problems of high, medium or low severity were found).
      • Improvements. Each executor should have both a classic and his own toolkit, which allows him to identify sections of code that can and should be improved.
      • Conclusion. It is logical that there should be a brief description of the most important points in the entire document, which the contractor must note.

      This report will be sent to you for full correction of all errors without exception, according to the recommendations provided by the executor. As a rule, we do not leave our clients alone with such a difficult task, and we comprehensively accompany and control the correction process.

      The smart contract audit report is your property, and you have every right to use it in any marketing activity, despite the fact that our logo is there.

      Conclusion

      The duration of the audit depends on the code you want to audit: its size, complexity, protocol, purpose, and the Specification provided. If the code is a simple bulk sale, well documented and planned in advance, it will take 10-15 business days.

      More complex contracts will take significantly longer. But at the time of the start of the audit, you will already know the exact estimate, since we determine it at the stage of preparatory work.