Smart Contract Audit

Download Report

Ferrum Network

September 18, 2022

Summary

Scope of Work

Workflow of the auditing process

Structure and organization of the findings

Manual Report

Test Results

Summary

Vidma is pleased to present this audit report outlining our assessment of code, smart contracts, and other important audit insights and suggestions for management, developers, and users.

The audited scope included an updated version of vesting and pre-transaction check smart contracts. A previous version was audited by Vidma team last November so this audit will include auditing the updates that are made.

There was an added updating of beneficiary addresses functionality that allows the contract owner to update receiver wallet address if the previous wallet was lost or the user just wants to move his allocation to a new address. Also, updated contract tracks unallocated tokens that allows to view transparent processing.

Vidma audit team confirms that all known issues are resolved and contracts are secure and operational. The changes are reflected in this version of the report accordingly.

During the audit process, the Vidma team found several issues, including those with critical severity. A detailed summary and the current state are displayed in the table below.

‍

Severity of the issue Issue severity

Critical

High

Medium

Low

Informational

Total

Severity of the issue Issue severity	Total found	Resolved
Critical	0 issues	0 issues
High	0 issues	0 issues
Medium	0 issues	0 issues
Low	3 issues	3 issues
Informational	3 issues	3 issues
Total	6 issues	6 issues

After evaluating the findings in this report and the final state after fixes, the Vidma auditors can state that the contracts are fully operational and secure. Under the given circumstances, we set the following risk level:

High Confidence

To set the codebase quality mark, our auditors are evaluating the initial commit given for the scope of the audit and the last commit with the fixes. This approach helps us adequately and sequentially evaluate the quality of the code. Code style, optimization of the contracts, the number of issues, and risk level of the issues are all taken into consideration. The Vidma team has developed a transparent evaluation codebase quality system presented below.

Severity of the issue

Issue severity

Total found

Resolved

Critical

High

0.8

Medium

0.5

Low

0.2

0.5

Informational

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:

99.40

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:

99.40

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

With the mission of breaking down barriers to mass adoption, Ferrum empowers the industry by reducing friction and bringing startups and established networks closer together.

Within the scope of this audit, two independent auditors thoroughly investigated the given codebase and analyzed the overall security and performance of the smart contracts.

The audit was conducted from August 24th, 2023 to September 18th. The outcome is disclosed in this document.

The scope of work for the given audit consists of the following contracts:

IronVestExtended;
IronVestPreCheck.

The source code was taken from the following source:

https://github.com/ferrumnet/linear-release-engine

Initial commit submitted for the audit:

bd2bf0a9a4c55467968cc289eb9bff7a61c43f63

Last commit reviewed by the auditing team:

9cb94e0946bd1ac527dbd1cb4c1f89ed428448a0

Final Release tag reviewed by Vidma auditors:

https://github.com/ferrumnet/linear-release-engine/releases/tag/v1.10.0

As a reference to the contracts logic, business concept, and the expected behavior of the codebase, the Ferrum Network team has provided the following documentation:

https://docs.ferrumnetwork.io/ferrum-network-ecosystem/v/iron-vest/

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

Usage data from the state variable to emit event

Low ML – 01 | Resolved

To decrease gas usage during claiming tokens by claim() you can use a local variable instead of a second call to the contract state (line 318).

Recommendation:

Consider changing info.remainingToBeClaimable to local remainingToBeClaimable.

Lack of zero address check

Low TL – 01 | Resolved

There is no requirement that the IronVest PreCheck contract address can't be zero address in the function setPreCheck (line 611). If the admin sets zero address with it, it will lock adding new vestings and updating beneficiary addresses.

Recommendation:

Make sure that functionality will be not locked or add requirement like that:

  function setPreCheck(IronVestPreCheck _vestingPreCheck) external onlyOwner {
        require(address(_vestingPreCheck) != address(0x00), "Invalid address");
        VestingCheck = _vestingPreCheck;
    }

Lack of delete operator

Low TL – 02 | Resolved

In function updateBeneficiaryAddress() assigns zero value to few struct fields. It is more efficient to use delete operator here to save gas usage on the function execution:

delete cliffInfo.allocation; (line 487)
delete nonCliffInfo.allocation; (line 490)
delete info.allocation; (line 511)

Recommendation:

Consider using delete operator to “clear” variables.

Wrong variable naming convention

Informational MI – 01 | Resolved

According to Solidity Style Guide, state and local variables should be in mixedCase style. In the IronVestExtended contract there is a state variable VestingCheck (line 92) that stores instance of the IronVestPreCheck contract.

Also, there is _usedHashes public mapping with underscore that usually indicates private/internal state variable but it is public. Make sure that visibility is correctly setted and remove underscore or change visibility for _usedHashes.

Recommendation:

Consider following the Solidity Style Guide 0.8.17 and naming conventions.

Typos

Informational MI – 02 | Resolved

There are some typos in the IronVestExtended contract code:

initilization -> initialization, line 89;
strore -> store, line 93;
agains -> against, line 116;
UpdateBeneficiaryWithdrawlAddress -> UpdateBeneficiaryWithdrawalAddress, line 177;
initilization -> initialization, line 204;
nonCliffReaminingTobeclaimable -> nonCliffRemainingTobeclaimable, line 371;
Functions -> Function, line 609;
geting -> getting, line 758;
sgnature -> signature, line 758;
tokenAddess -> tokenAddress, line 761;
un allocated -> unallocated, line 784.

Typos in the IronVestPreCheck contract code:

Souldn't -> Shouldn't, line 87;
concatened -> concatenated, line 134.

Recommendation:

Consider fixing typos.

Сontradiction of NatSpec docs

Informational MI – 03 | Resolved

In the IronVestPreCheck contract there are copied NatSpec docs from the IronVestExtended which do not correspond to their purpose. For example, general NatSpec for IronVestPreCheck contract, preAddVesting(), preAddCliffVesting(), preUpdateBeneficiaryAddress().

Recommendation:

Consider changing NatSpec documentation for IronVestPreCheck SC.

‍

Test Results

To verify the security of contracts and the performance, a number of integration tests were carried out using the Hardhat testing framework.

Vidma Coverage – 100%

‍
Industry Standard – 95%

‍

It is important to note that Vidma auditors do not modify, edit or add tests to the existing tests provided in the Ferrum Network repository. We write totally separate tests with code coverage of a minimum of 95% to meet the industry standards.

Tests written by Vidma auditors

Test Coverage

‍

File

contracts\

IronVestExtended.sol

IronVestPreCheck.sol

All Files

File	% Stmts	% Branch	% Funcs	% Lines
contracts\	100.00	100.00	100.00	100.00
IronVestExtended.sol	100.00	100.00	100.00	100.00
IronVestPreCheck.sol	100.00	100.00	100.00	100.00
All Files	100.00	100.00	100.00	100.00

Test Results

Contract: IronVestExtended

Deployment / Initialization

check name
check admin role
check vester role
check signer
check pre check address
should fail is contract is already initialized(40ms)

Functions

setPreCheck

should revert if caller is not admin
should reset pre check address correctly(73ms)
should fail reset to zero address

unAllocatedTokens

should return amount of unallocated tokens correctly(41ms)
should return zero amount if there is no unallocated tokens

addVesting

should fail if caller is not the vester
should fail if array lengths of users and amounts are not equal
should fail if vesting time will be less than current time
should fail if signature has incorrect message(91ms)
should add vesting correctly(258ms)

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(40ms)
should fail if invalid message was provided(68ms)
should fail if cliff percentage will be greater than 50%(44ms)
should fail if array lengths of users and amounts are not equal(41ms)
should add cliff vesting correctly(268ms)

claimable

should fail if user has no allocation in current pool
should get base claim amount by user
should calculate claim amount
should get full claim amount

cliffClaimable

should fail if user has no allocation in current pooll
should get base claim amount
should calculate claim amount & release rate by user
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(46ms)
should claim calculated amount correctly(234ms)
should get full claim amount & release rate by user(69ms)

claimCliff

should fail if current time is less than cliff period
should claim base amount correctly(58ms)
should claim calculated amount correctly(148ms)
should claim full amount correctly(80ms)

claimNonCliff

should fail if current time is less than cliff period
should claim base amount correctly(68ms)
should claim calculated amount correctly(176ms)
should claim full amount correctly(94ms)

signatureVerification

should fail if incorrect signature is provided
should return not that signer if not that address was extracted(82ms)
should fail if message was already used
should verify message correctly(96ms)

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
should withdraw funds correctly

Reentrancy

should fail add vesting(275ms)
should fail add cliff vesting(287ms)
should fail claim(165ms)
should fail claim cliff(189ms)
should fail claim nonCliff(194ms)
should fail beneficiary update(280ms)

Test Cases

Simple vesting full flow(523ms)
Cliff vesting full flow(409ms)
Flow when one user should get all vested tokens(341ms)
Case when cliff percentage is zero(335ms)
Mixed full flow with changing recipients(530ms)
Mixed full flow with changing recipients (cliff vesting)(694ms)

updateBeneficiaryAddress

should update beneficiary address correctly & claim full amount by other user(158ms)
should revert if user does not have allocation
update user for cliff & withdraw(302ms)
should revert if user does not have allocation(331ms)
should revert if there is no pool with selected pool id(194ms)
should revert if updated address is equal to the old address(194ms)
should revert if updated/old address is zero address(208ms)
update user for non cliff & withdraw(324ms)
should revert if caller is not admin(193ms)

80 passing(11s)

‍

We are delighted to have a chance to work with the Ferrum Network team and contribute to your company's success by reviewing and certifying the security of your smart contracts.

The statements made in this document should be interpreted neither as investment or legal advice, nor should its authors be held accountable for decisions made based on this document.

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.

Smart Contract Audit

Table of contents