UNCLP

Smart Contract Audit Report

Audit Summary

UNCLP Audit Report UNCLP is a new contract which allows the project team to deposit LP tokens which unlock for redemption over time.

For this audit, we reviewed the UNCLP contract at commit cbc5066620dbec75689d8e40d3b7e877164442e0 on the team's private GitHub repository.

Audit Findings

An Informational finding remains and the team may want to review it. In addition, centralized aspects are present.
Date: December 19th, 2023.
Updated: December 26th, 2023 to reflect changes from code provided by the project team to commit cbc5066620dbec75689d8e40d3b7e877164442e0 on the team's private GitHub repository.

Finding #1 - UNCLP - High (Resolved)

Description: When withdrawing and redeeming LP tokens, the contract accepts any amount of WETH and FEG tokens to receive from the redemption. If the liquidity pool's reserves are manipulated before a withdrawal is executed, the project team may receive less WETH or FEG than intended.
Risk/Impact: A withdrawal can be frontrun with a FEG sell, decreasing the underlying WETH value of LP tokens. When the withdrawal is executed, the contract will then receive less WETH than intended from the LP token redemption.
Recommendation: The project team should add a "minimum WETH to receive" argument in the withdrawal function and ensure that the resulting WETH from LP token redemption is at least equal to the desired amount.
Resolution: A minimum amount to receive is now calculated when "enabling" a withdrawal. As this value determined by querying LP reserves, the project team should ensure that the minimum amount has not been manipulated before executing a withdrawal.

Finding #2 - UNCLP - Informational

Description: The following variables are not declared constant, but are never updated.
FEG, admin, goal, interval, rate, withdrawalAddress
Recommendation: These variables should be declared constant for additional gas savings on each call.
Update:The FEG, admin, and withdrawalAddress variables have been declared constant.

Contract Overview

  • This contract is used to allow the project team to redeem deposited LP tokens for their underlying FEG and WETH over time.
  • The Admin address can deposit LP tokens at any time; this will trigger the contract's start time and begin the first "round".
  • The start time and first round can also be triggered by an "agreement status" update by the contract's Admin or Withdrawal address.
  • Each round, an additional 10% of the total deposited LP tokens are unlocked for withdrawal by the project team.
  • The current round is incremented when certain contract functionality is triggered every 14 days, beginning from the contract's start time.
  • The withdrawal address can withdraw a percentage of unlocked tokens once per day, limited to a maximum 10% of the total deposited LP tokens at once.
  • In order to withdraw, the withdrawal address must first "enable" the withdrawal, which sets an accepted slippage used during withdrawal execution.
  • The project team must exercise caution and ensure that the minimum accepted amount determined by an enabling has not been manipulated before withdrawing.
  • Withdrawn LP is burned in exchange for their underlying FEG and WETH values.
  • Resulting FEG is transferred to the FEG Location address if it has been set. If the FEG location has not been set, it is transferred to the Admin address instead.
  • Resulting WETH is transferred to the withdrawal address.
  • Withdrawals can no longer occur if the contract's WETH goal has been reached.
  • If a withdrawal results in the goal being exceeded, excess WETH and any remaining LP tokens in the contract are sent to the Admin.
  • The Admin or Withdrawal address can withdraw all LP tokens, WETH, and FEG from the contract if both the Admin and Withdrawal addresses have both "agreed", or if 141 days have passed from the contract's start time.
  • The Admin and Withdrawal addresses can update their own agreement statuses at any time.
  • The Admin can update the FEG Location address at any time.
  • As the FEG address was not included within the scope of this audit, we are unable to provide an assessment with regards to its security or functionality.
  • This contract utilizes ReentrancyGuard to prevent against reentrancy attacks in applicable functions.
  • As the contracts are implemented with Solidity v0.8.0, they are safe from any possible overflows/underflows.

Audit Results

Vulnerability Category Notes Result
Arbitrary Jump/Storage Write N/A PASS
Centralization of Control
  • The Admin or Withdrawal address can withdraw all FEG, WETH, and LP tokens from the contract.
  • WARNING
    Compiler Issues N/A PASS
    Delegate Call to Untrusted Contract N/A PASS
    Dependence on Predictable Variables N/A PASS
    Ether/Token Theft N/A PASS
    Flash Loans N/A PASS
    Front Running
  • The project team must exercise caution and ensure that the minimum accepted amount determined by an enabling has not been manipulated before withdrawing.
  • PASS
    Improper Events N/A PASS
    Improper Authorization Scheme N/A PASS
    Integer Over/Underflow N/A PASS
    Logical Issues N/A PASS
    Oracle Issues N/A PASS
    Outdated Compiler Version N/A PASS
    Race Conditions N/A PASS
    Reentrancy N/A PASS
    Signature Issues N/A PASS
    Sybil Attack N/A PASS
    Unbounded Loops N/A PASS
    Unused Code N/A PASS
    Overall Contract Safety   PASS

    Inheritance Chart

    Smart Contract Audit - Inheritance

    Function Graph

    Smart Contract Audit - Graph

    Functions Overview

    
     ($) = payable function
     # = non-constant function
     
     Int = Internal
     Ext = External
     Pub = Public
    
    
     + [Int] IERC20 
     - [Ext] totalSupply
     - [Ext] balanceOf
     - [Ext] transfer #
     - [Ext] allowance
     - [Ext] approve #
     - [Ext] transferFrom #
    
    + [Int] IUniswapV2Router02 
     - [Ext] swapExactTokensForTokensSupportingFeeOnTransferTokens #
    
    + [Int] IPair 
     - [Ext] burn #
    
    + [Lib] Address 
     - [Int] isContract
     - [Int] functionCall #
     - [Int] functionCallWithValue #
     - [Int] verifyCallResultFromTarget
     - [Prv] _revert
    
    + [Lib] SafeTransfer 
     - [Int] _pullUnderlying #
     - [Int] safeTransfer #
     - [Int] safeTransferFrom #
     - [Int] _pushUnderlying #
     - [Int] safeTransferETH #
     - [Prv] _callOptionalReturn #
    
    +  ReentrancyGuard 
     - [Pub]  #
     - [Prv] _nonReentrantBefore #
     - [Prv] _nonReentrantAfter #
    
    +  UNCLP (ReentrancyGuard)
     - [Ext] addLP #
    	- modifiers: nonReentrant,update
     - [Pub] balanceOpen
     - [Ext] LPValue
     - [Ext] setAgreed #
    	- modifiers: nonReentrant,update
     - [Ext] withdraw #
    	- modifiers: nonReentrant,update
     - [Ext] saveTokens #
    	- modifiers: nonReentrant
    
    
    

    About SourceHat

    SourceHat has quickly grown to have one of the most experienced and well-equipped smart contract auditing teams in the industry. Our team has conducted 1800+ solidity smart contract audits covering all major project types and protocols, securing a total of over $50 billion U.S. dollars in on-chain value!
    Our firm is well-reputed in the community and is trusted as a top smart contract auditing company for the review of solidity code, no matter how complex. Our team of experienced solidity smart contract auditors performs audits for tokens, NFTs, crowdsales, marketplaces, gambling games, financial protocols, and more!

    Contact us today to get a free quote for a smart contract audit of your project!

    What is a SourceHat Audit?

    Typically, a smart contract audit is a comprehensive review process designed to discover logical errors, security vulnerabilities, and optimization opportunities within code. A SourceHat Audit takes this a step further by verifying economic logic to ensure the stability of smart contracts and highlighting privileged functionality to create a report that is easy to understand for developers and community members alike.

    How Do I Interpret the Findings?

    Each of our Findings will be labeled with a Severity level. We always recommend the team resolve High, Medium, and Low severity findings prior to deploying the code to the mainnet. Here is a breakdown on what each Severity level means for the project:

    • High severity indicates that the issue puts a large number of users' funds at risk and has a high probability of exploitation, or the smart contract contains serious logical issues which can prevent the code from operating as intended.
    • Medium severity issues are those which place at least some users' funds at risk and has a medium to high probability of exploitation.
    • Low severity issues have a relatively minor risk association; these issues have a low probability of occurring or may have a minimal impact.
    • Informational issues pose no immediate risk, but inform the project team of opportunities for gas optimizations and following smart contract security best practices.