Discover advanced techniques to safeguard your contracts
Read a document

Smart Contract Audit

Name

Table of contents

Summary
Scope of Work
Workflow of the auditing process
Structure and organization of the findings
Manual Report
Test Results

Summary

Vidma team has conducted a smart contract audit for the given codebase.

The contracts are in good condition. Based on the fixes provided by the Ammbr team and on the quality and security of the codebase provided, Vidma team can give a score of 95 to the audited smart contracts.

During the auditing process, the Vidma team has found a couple of informational issues, 7 issues with a low level of severity, 1 issue with a medium level of severity, and 3 issues with a critical level of severity.

Severity of the issue
Total found
Resolved
Unresolved
Critical
3 issues
3 issues
0 issues
High
3 issues
3 issues
0 issues
Medium
3 issues
3 issues
0 issues
Low
3 issues
3 issues
0 issues
Informational
3 issues
3 issues
0 issues
Low
3 issues
3 issues
0 issues

The contracts are in good condition. Based on the fixes provided by the Ammbr team and on the quality and security of the codebase provided, Vidma team can give a score of 95 to the audited smart contracts.

Based on the given findings, risk level, performance, and code style, Vidma team can grant the following overall score:

Please mind that this audit does not certify the definite reliability and security level of the contract. This document describes all vulnerabilities, typos, performance issues, and security issues found by Vidma auditing team. If the code is under development, we recommend run one more audit once the code is finalized.

Summary

Severity of the issue
Issue severity
Total found
Resolved
Critical
1
10
High
0.8
7
Medium
0.5
5
Low
0.2
0.5
Informational
0
0.1
Please note that the points are deducted out of 100 for each and every issue on the list of findings (according to the current status of the issue). Issues marked as “not valid” are not subject to point deduction.
Codebase quality:
70.00

Evaluating the initial commit and the last commit with the fixes, Vidma audit team set the following codebase quality mark.

Score
Based on the overall result of the audit and the state of the final reviewed commit, the Vidma audit team grants the following score:

90.00

In addition to manual check and static analysis, the auditing team has conducted a number of integrated autotests to ensure the given codebase has an adequate performance and security level. The test results and coverage can be found in the accompanying section of this audit report.

Please be aware that this audit does not certify the definitive reliability and security level of the contract. This document describes all vulnerabilities, typos, performance issues, and security issues found by the Vidma audit team.
If the code is still under development, we highly recommend running one more audit once the code is finalized.

Scope of work

Workflow of the auditing process

Vidma audit team uses the most sophisticated and contemporary methods and well-developed techniques to ensure contracts are free of vulnerabilities and security risks. The overall workflow consists of the following phases:

Phase 1: The research phase

Research

After the Audit kick-off, our security team conducts research on the contract’s logic and expected behavior of the audited contract.

Documentation reading

Vidma auditors do a deep dive into your tech documentation with the aim of discovering all the behavior patterns of your codebase and analyzing the potential audit and testing scenarios.

The outcome

At this point, the Vidma auditors are ready to kick off the process. We set the auditing strategies and methods and are prepared to conduct the first audit part.

Phase 2: Manual part of the audit

Manual check

During the manual phase of the audit, the Vidma team manually looks through the code in order to find any security issues, typos, or discrepancies with the logic of the contract. The initial commit as stated in the agreement is taken into consideration.

Static analysis check

Static analysis tools are used to find any other vulnerabilities in smart contracts that were missed after a manual check.

The outcome

An interim report with the list of issues.

Phase 3: Testing part of the audit

Integration tests

Within the testing part, Vidma auditors run integration tests using the Truffle or Hardhat testing framework. The test coverage and the test results are inserted in the accompanying section of this audit report.

The outcome

Second interim report with the list of new issues found during the testing part of the audit process.

Structure and organization of the findings

For simplicity in reviewing the findings in this report, Vidma auditors classify  the findings in accordance with the severity level of the issues. (from most critical to least critical).

All issues are marked as “Resolved” or “Unresolved”, depending on if they have been fixed by project team or not. The issues with “Not Relevant” status are left on the list of findings but are not eligible for the score points deduction.

The latest commit with the fixes reviewed by the auditors is indicated in the “Scope of Work” section of the report.

The Vidma team always provides a detailed description of the issues and recommendations on how to fix them.

Classification of found issues is graded according to 6 levels of severity described below:

Critical
The issue affects the contract in such a way that funds may be lost or allocated incorrectly, or the issue could result in a significant loss.
Example: Underflow/overflow, precisions, locked funds.
High
The issue significantly affects the ability of the contract to compile or operate. These are potential security or operational issues.
Example: Compilation errors, pausing/unpausing of some functionality, a random value, recursion, the logic that can use all gas from block (too many iterations in the loop), no limitations for locking period, cooldown, arithmetic errors which can cause underflow, etc.
Medium
The issue slightly impacts the contract’s ability to operate by slightly hindering its intended behavior.
Example: Absence of emergency withdrawal of funds, using assert for parameter sanitization.
Low
The issue doesn’t contain operational or security risks, but are more related to optimization of the codebase.
Example: Unused variables, inappropriate function visibility (public instead of external), useless importing of SCs, misuse or disuse of constant and immutable, absent indexing of parameters in events, absent events to track important state changes, absence of getters for important variables, usage of string as a key instead of a hash, etc.
Informational
Are classified as every point that increases onboarding time and code reading, as well as the issues which have no impact on the contract’s ability to operate.
Example: Code style, NatSpec, typos, license, refactoring, naming convention (or unclear naming), layout order, functions order, lack of any type of documentation.

Manual Report

Test Results

Contract: IronVest

  • Deployment / Initialization
    • check name(788ms)
    • check admin role
    • check vester roleƒun
    • check signer
    • should fail is contract is already initialized(43ms)
  • Functions
    • addVesting
      • should fail if caller is not the vester(58ms)
      • should fail if array lengths of users and amounts are not equal(39ms)
      • should fail if vesting time will be less than current time(38ms)
      • should fail if signature has incorrect message(83ms)
      • should add vesting correctly(206ms)
    • addCliffVesting
      • should fail if caller is not the vester
      • should fail if vesting time will be less than current time
      • should fail if vesting time will be less than cliff period
      • should fail if vesting time will be less than cliff period
      • should fail if vesting time will be less than cliff vesting time
      • should fail if cliff period time will be less than current time
      • should fail if cliff vesting time will be less than cliff period
      • should fail if invalid message was provided(51ms)
      • should fail if cliff percentage will be greater than 50%(41ms)
      • should fail if array lengths of users and amounts are not equal
      • should add cliff vesting correctly(229ms)
    • claimable
      • should fail if user has no allocation in current pool
      • should get base claim amount by user
      • should calculate claim amount(44ms)
      • should get full claim amount
    • cliffClaimable
      • should fail if user has no allocation in current pool
      • should get base claim amount
      • should calculate claim amount & release rate by user(38ms)
      • should get full claim amount & release rate by user
    • nonCliffClaimable
      • should fail if user has no allocation in current pool
      • should get base claim amount
      • should calculate claim amount
      • should get full claim amount
    • claim
      • should claim base amount(55ms)
      • should claim calculated amount correctly(229ms)
      • should get full claim amount & release rate by user(64ms)
    • claimCliff
      • should fail if current time is less than cliff period
      • should claim base amount correctly(63ms)
      • should claim calculated amount correctly(137ms)
      • should claim full amount correctly(86ms)
    • claimNonCliff
      • should fail if current time is less than cliff period
      • should claim base amount correctly(56ms)
      • should claim calculated amount correctly(140ms)
      • should claim full amount correctly(92ms)
    • signatureVerification
      • should fail if incorrect signature is provided
      • should return not that signer if not that address was extracted(50ms)
      • should fail if message was already used
      • should verify message correctly(46ms)
    • setSigner
      • should fail if caller is not admin
      • should fail if signer has zero address
      • should set signer correctly
    • emergencyWithdraw
      • should fail if caller is not the owner
      • hould withdraw funds correctly(49ms)
  • Reentrancy
    • should fail add vesting(222ms)
    • should fail add cliff vesting(276ms)
    • should fail claim(183ms)
    • should fail claim cliff(170ms)
    • should fail claim nonCliff(170ms)
  • Test Cases
    • Simple vesting full flow(274ms)
    • Cliff vesting full flow(276ms)
    • Flow when one user should get all vested tokens(244ms)
    • Case when cliff percentage is zero(193ms)
    • 62 passing(5s)
Vidma is a security audit company helping crypto companies ensure their code and products operate safely and as intended, enabling founders to sleep soundly at night. We specialize in auditing DeFi protocols, layer one protocols, and marketplace solutions. Our team consists of experienced and internationally trained specialists. Our company is based in Ukraine, known for its strong engineering, cryptography, and cybersecurity culture.
4