Unipilot Staking Audit Report

Table Of Content



BlockApex (Auditor) was contracted by Voir Studio (Client) for the purpose of conducting a Smart Contract Audit/Code Review. This document presents the findings of our analysis which started on  22nd June 2022. 

Name: Unipilot Staking 
Auditors: Kaif Ahmed | Faizan Nehal 
Platform: EVM
Type of review: Manual Code Review | Automated Tools Analysis
Methods: Architecture Review, Functional Testing, Computer-Aided Verification, Manual Review
Git repository/ Commit Hash: https://github.com/unipilot
White paper/ Documentation: Docs | Medium 
Document log:
Initial Audit Completed: June 25th, 2022
Final Audit Completed: June 27th, 2022


The git repository shared was checked for common code violations along with vulnerability-specific probing to detect major issues/vulnerabilities. Some specific checks are as follows:

Code reviewFunctional review
Reentrancy Unchecked external callBusiness Logics Review
Ownership TakeoverERC20 API violationFunctionality Checks
Timestamp DependenceUnchecked mathAccess Control & Authorization
Gas Limit and LoopsUnsafe type inferenceEscrow manipulation
DoS with (Unexpected) ThrowImplicit visibility levelToken Supply manipulation
DoS with Block Gas LimitDeployment ConsistencyAsset’s integrity
Transaction-Ordering DependenceRepository ConsistencyUser Balances manipulation
Style guide violationData ConsistencyKill-Switch Mechanism
Costly LoopOperation Trails & Event Generation

Project Overview

Unipilot Staking is a Staking infrastructure built on Ethereum, a reliable and scalable L1 solution. The staking solution offered by Unipilot provides the stakers with a way to get incentives.

Founded in May 2021, Unipilot was the first of its kind liquidity optimizer product to offer users to further optimize their liquidity on Uniswap. The advantages of using a liquidity optimizer include better returns on the provided liquidity on Uniswap.

System Architecture

The Unipilot protocol earns 20% of all revenues generated on the platform. Under the old model, all of this revenue was sent to the Index Fund, which already has a value of $245,000 at the time of writing. With the introduction of staking, you will be able to stake your $PILOT tokens on the Unipilot dApp to earn a share of protocol revenues. Initially, 40% of Treasury revenues will be distributed to stakers, though this percentage could change in the future.

Rewards will be distributed with every block and paid in $ETH, as chosen by the community. Stakers will be able to collect their $ETH rewards at any time, and remain in full control of their $PILOT, with the ability to unstake at any time without penalty.

As staking rewards originate from revenue earned by the protocol and not from inflationary $PILOT token rewards, returns are therefore not fixed. As TVL rises, the protocol will earn more revenue, and staking rewards will increase.

Methodology & Scope

The codebase was audited using a filtered audit technique. A band of four (2) auditors scanned the codebase in an iterative process spanning over a time of two (1) weeks. 

Starting with the recon phase, a basic understanding was developed and the auditors worked on developing presumptions for the developed codebase and the relevant documentation/whitepaper. Furthermore, the audit moved on with the manual code reviews with the motive to find logical flaws in the codebase complemented with code optimizations, software, and security design patterns, code styles, best practices and identifying false positives that were detected by automated analysis tools.


Executive Summary

The analysis indicates that some of the functionalities in the contracts audited are working properly.

Our team performed a technique called “Filtered Audit”, where the contract was separately audited by four individuals. After a thorough and rigorous process of manual testing, an automated review was carried out using slither for static analysis and Hardhat and Foundry for edge case testing. All the flags raised were manually reviewed and re-tested to identify the false positives.

Our team found:

# of issues Severity of the risk
0Critical Risk issue(s)
3High-Risk issue(s)
2Medium Risk issue(s)
1Low-Risk issue(s)
1Informatory issue(s)

Key Findings

1.Pending rewards for the previous reward token are getting lostHighFixed
2.Incorrect behavior for pending reward tokensHighFixed
3.Incorrect behavior for staking when no one has staked their tokens HighFixed
4.Arithmetic overflow error on updating the reward tokenMediumFixed
5.Inconsistent behavior if the reward token is other than 18 decimalsMediumFixed
6.Less optimized checksLowAcknowledged
7.Redundant event emissionInformatoryFixed

Detailed Overview

Critical-risk issues

No issues were found.

High-risk issues

1. Pending Rewards For Previous Reward Tokens are Getting Lost 


If the reward token is changed by the governor then the pending reward for the previous reward tokens are lost, users will not receive their already accumulated rewards and the accumulated rewards will reset to 0. Contract does not hold any logic for giving out the pending rewards for previous token.

Developers Response:

Developers said that those pending rewards for the user will not be completely  lost and they would be paid out to users eventually through a merkle tree.


There must be a map that will check the previous pending reward that is not paid to the stakers.


Fixed as per BlockAPex recommendation. 

2. Incorrect Behavior For Pending Reward Tokens


When the reward token is changed and the previous reward token already had a reward for the user in it, then the calculated pending reward for the new reward token will add previous token reward as well as new token reward and return it to the user. 


The contract must check if the whole reward this is provided is given out to the stakers.


Fixed as per BlockAPex recommendation.

3. Incorrect Behavior For Staking When No One has Staked Their Tokens


If the staking in the contract has already started and no one has staked their tokens yet, then the reward for empty past blocks will not be assigned to any staker.

Developers Response:

Initial permanent PILOT stake will be done by the foundation to set the initial state of the contract, rewards earned by the foundation will be distributed back to staking participants.


This default behavior of the contract should be changed and is not as per the intended behavior.


Fixed as per BlockAPex recommendation.

Medium-risk issues

4. Arithmetic Overflow Error On Updating the Reward Token


If the governance recalls the updateRewardToken() function with the address of the same reward token, then the contract is throwing an arithmetic overflow error.


The arithmetic overflow error should be checked properly.


Fixed as per BlockAPex recommendation.

5. Inconsistent Behavior if the Reward Token is Other Than 18 Decimals


If the reward token decimal is 6, 8 and 12 then the contract won’t let the users to stake the PILOTs. There is a functionality in contract, when the user will come to stake their token, it will check whether the contract has the reward tokens in it or not, if the reward tokens will not be present then it will not let the user to stake their token. 

Now in case of different decimal places other than 18, the contract will get its own balance of reward token 


The property should be added for the 6,8 and 12 decimals , just like for the 18 decimals.


Fixed as per BlockAPex recommendation.

Low-risk issues

6. Less Optimized Checks


In the updateRewards() function, it is checking the condition if (_rewardDurationInBlocks == 0) instead in should check  if (_rewardDurationInBlocks == 0 || _reward == 0) because even if the rewardDurationInBlocks are provided but rewards are zero then there is no point in moving forward. 7 lines below this condition it is checking if (_reward == 0). So it would be more optimized if both of these conditions are checked in the same line.


These checks should be made into more optimized ones to save gas.

Developers Response:

Not valid as passing zero indicates the contract to distribute the existing debt rewards



Informatory issues and Optimizations

7. Redundant Event Emissions


There is no reason to emit the events at the end of the constructor, when the constructor is completed, two events GovernanceChanged() and RewardTokenChanged() are emitted. The code can be more optimized by removing these event emissions.


Redundant events fired in the constructor should be removed. 




The smart contracts provided by the client for audit purposes have been thoroughly analyzed in compliance with the global best practices till date w.r.t cybersecurity vulnerabilities and issues in smart contract code, the details of which are enclosed in this report. 

This report is not an endorsement or indictment of the project or team, and they do not in any way guarantee the security of the particular object in context. This report is not considered, and should not be interpreted as an influence, on the potential economics of the token, its sale or any other aspect of the project. 

Crypto assets/tokens are results of the emerging blockchain technology in the domain of decentralized finance and they carry with them high levels of technical risk and uncertainty. No report provides any warranty or representation to any third-Party in any respect, including regarding the bug-free nature of code, the business model or proprietors of any such business model, and the legal compliance of any such business. No third-party should rely on the reports in any way, including for the purpose of making any decisions to buy or sell any token, product, service or other asset. Specifically, for the avoidance of doubt, this report does not constitute investment advice, is not intended to be relied upon as investment advice, is not an endorsement of this project or team, and it is not a guarantee as to the absolute security of the project.

Smart contracts are deployed and executed on a blockchain. The platform, its programming language, and other software related to the smart contract can have its vulnerabilities that can lead to hacks. The scope of our review is limited to a review of the Solidity code and only the Solidity code we note as being within the scope of our review within this report. The Solidity language itself remains under development and is subject to unknown risks and flaws. The review does not extend to the compiler layer, or any other areas beyond Solidity that could present security risks.

This audit cannot be considered as a sufficient assessment regarding the utility and safety of the code, bug-free status or any other statements of the contract. While we have done our best in conducting the analysis and producing this report, it is important to note that you should not rely on this report only - we recommend proceeding with several independent audits and a public bug bounty program to ensure security of smart contracts.

More Audits

Metaverse: Virtual Wonderland Or Capitalist Dystopia?

Security and privacy are among the top issues expected to arise in the metaverse. Some have even gone so far as to say that the metaverse is capitalizing on users' desire to escape from reality.

Dforce Network - February 13, 2023

The attack on dForce network had significant consequences for the platform and its users. By exploiting a reentrancy vulnerability in the wstETH/ETH pool on Curve and the dForce wstETH/ETH Vault, the attacker was able to manipulate the virtual price of the pool, which in turn affected the oracle used by the dForce wstETH/ETH Vault

Infiltrating The EVM IV - Echoes of the Past, Visions for Tomorrow

The article "Infiltrating The EVM IV - Echoes of the Past, Visions for Tomorrow" takes readers on a captivating journey through real-life incidents in the realm of blockchain security. Three gripping narratives stand out: the MISO rescue mission, the Dark Forest of Ethereum, and the Siren Market exploit.

Sonar Bridge Initial Audit

BlockApex (Auditor) was contracted by Sonar(Client) for the purpose of conducting a Smart Contract Audit/Code Review of Sonar bridge modeule.  This document presents the findings of our analysis which took place on 8th September 2021. 

Yearn Finance - April 13, 2023

The Yearn Finance hack that occurred on April 13, 2023, resulted in the loss of approximately $11.4 million. The exploit was carried out through a misconfiguration in the yUSDT vault, revealing a flaw in the system's architecture.

Yamato Protocol - Audit Report

Yamato Protocol is a crypto-secured stablecoin generator DApp pegged to JPY. Yamato Protocol is a lending decentralized financial application (DeFi) that can generate Japanese Yen stablecoin "CJPY". It is being developed by DeFiGeek Community Japan, a decentralized autonomous organization.

Kokomo Finance - Hack Analysis (March 27, 2023)

Kokomo Finance has taken off with approximately $4 million worth of user funds, leaving users unable to withdraw their funds. Wrapped Bitcoin deposits were rugged, with almost $2M of tokens still remaining in the project’s pools on Optimism.

Chainpals Token Audit Report

The main contract is called Chainpals Token. The minting and transfer of the complete supply is done during deployment. This means new tokens can only be minted if the old ones are burnt.

Revisiting Ethereum Classic in Light of the London Hard Fork

The successful upgrade of the London Hard Fork is a big difference from the fork leading to Ethereum Classic that took place back in 2016. However, despite their divergence, both are milestones in the Ethereum world- guaranteed to have lasting impacts on the blockchain as we know it. Read more to find out the circumstances surrounding each hard fork and the role they may play in shaping Ethereum's future.

1 2 3 11
Designed & Developed by: 
All rights reserved. Copyright 2023