Q1 2025 Web3 Security ReportAccess control failures led to $1.63 billion in losses
Discover report insights
  • Hacken
  • Audits
  • jellyverse
  • [SCA] Jellyverse / Governor / Apr2024
Jellyverse logo

Jellyverse

Audit name:

[SCA] Jellyverse / Governor / Apr2024

Date:

Jun 24, 2024

Table of Content

Introduction
Audit Summary
Document Information
System Overview
Executive Summary
Risks
Findings
Appendix 1. Severity Definitions
Appendix 2. Scope
Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the Jellyverse team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

Jellyverse represents an expansive ecosystem within the decentralized finance (DeFi) landscape, managed by its community via a decentralized autonomous organization (DAO). It is dedicated to advancing the latest version of DeFi, often referred to as DeFi 3.0, with a vision to establish a sustainable, yield-focused framework that merges protocols with tangible real-world assets. The platform offers multiple utilities crafted to address diverse financial requirements, all regulated by its native cryptocurrency, JLY.

The governance model of Jellyverse, called Governor, is designed to enable users to steer protocols within its ecosystem effectively. Additionally, it allows new initiatives the opportunity to become part of Jellyverse. The system facilitates a fair allocation of protocol earnings to stakers, positioning it as an attractive option for projects seeking to prosper.

titlecontent
PlatformEVM
LanguageSolidity
TagsGovernance, Vesting
Timeline18/04/2024 - 26/04/2024
Methodologyhttps://hackenio.cc/sc_methodology

    Audit Summary

    Total9.6/10
    Security Score

    10/10

    Test Coverage

    95,52%

    Code Quality Score

    9/10

    Documentation Quality Score

    10/10

    11Total Findings
    6Resolved
    5Accepted
    0Mitigated

    The system users should acknowledge all the risks summed up in the risks section of the report.

    Document Information

    This report may contain confidential information about IT systems and the intellectual property of the Customer, as well as information about potential vulnerabilities and methods of their exploitation.

    The report can be disclosed publicly after prior consent by another Party. Any subsequent publication of this report shall be without mandatory consent.

    Document

    NameSmart Contract Code Review and Security Analysis Report for Jellyverse
    Audited ByJakub Heba, Ataberk Yavuzer
    Approved ByAtaberk Yavuzer
    Websitehttps://jellyverse.org
    Changelog30/04/2024 - Preliminary Report
    17/05/2024 - Remediation Check
    19/06/2024 - Second Remediation Check
    20/12/2024 - Whitepaper Update
    • Document

      Name
      Smart Contract Code Review and Security Analysis Report for Jellyverse
      Audited By
      Jakub Heba, Ataberk Yavuzer
      Approved By
      Ataberk Yavuzer
      Changelog
      30/04/2024 - Preliminary Report
      17/05/2024 - Remediation Check
      19/06/2024 - Second Remediation Check
      20/12/2024 - Whitepaper Update

    System Overview

    Jellyverse is a DeFi platform, managed by the governance, with multiple utilities, such as staking, vesting, native tokens to jelly tokens swapping, with its own JLY ERC20 token implementation, working as governance and utility token.

    Chest - staking contract representing user voting power by means of chest. Voting power decreases over time and upon unstaking. DailySnapshot - a contract to store and retrieve daily snapshots blocknumbers per epoch. Governor - it is a decentralised voting for proposals solution. It is assigned to signle Chest instance, to determine stakers voting power. It is modular, can be extended by JellyGovernor and other submodules: GovernorCountingSimple, GovernorSettings, GovernorTimelockControl. GovernorVotes - calculates user's votes based on chests staked. InvestorDistribution - a contract that stakes chests for predefined investors. JellyGovernor - extension of Governor, which specifies voting function and quorum. JellyTimelock - an instance of TimelockController. Connected with governance to execute proposals timely. JellyToken - an ERC20 token representing the main token of Jelly ecosystem. JellyTokenDeployer - a factory contract that allows to deploy JellyToken instace via Create2.  LiquidityRewardDistribution - a contract for distributing liquifity mining rewards. Minter - a contract that mints Jelly tokens timely for beneficiaries.  OfficialPoolsRegister - a registry contract to store and retrieve official DEX pools. PoolParty - a contract for swapping native tokens for jelly tokens. The received payment in USD stable coin is later used to provide liquidity for DEX pool. RewardVesting - a contract designed for claiming vested liquidity. It is used by the LiquidityRewardDistribution.  StakingRewardDistribution - a contract for distributing staking rewards. TeamDistribution - a contract that stakes chests for predefined team members.

    Privileged roles

    • MINTER_ROLE - in JellyToken contract, this actor could perform initial preminting of tokens to specified addresses, as well as is able to mint JLY tokens through the mint() function

    • Owner of Chest contract is able to set arbitrary fee value, which could have negative consequences for users using the platform. However, this address will be manager by governance, so risk of it is much lowered.

    • Owner of LiquidityRewardDistribution, as well as StakingRewardDistribution, could change vesting contract address which could be dangerous if replaced with malicious one.

    • Owner of PoolParty can set up _ustToJellyRatio arbitrary, which may lead to a situation where this ratio is set very high value, what could be problematic for users using the buyWithUsd() function

    Executive Summary

    Documentation quality

    The total Documentation Quality score is 10 out of 10.

    • Whitepaper is present.

    • Functional requirements are covered.

    • Technical description are provided for most critical parts..

    Code quality

    The total Code Quality score is 9 out of 10.

    • Several template code patterns were found.

    • Code lacks explanations for more advanced operations and math calculations

    Test coverage

    Code coverage of the project is 76.5% (branch coverage), with a mutation score of 95.52%.

    • Deployment and basic user interactions are covered with tests.

    • Edge case scenarios and negative cases coverage are missed somethimes

    Security score

    Upon auditing, the code was found to contain 2 critical, 0 high, 4 medium, and 4 low severity issues.

    All identified issues are detailed in the “Findings” section of this report.

    After performing the remediation check, it was found that all findings have been resolved or their risk has been accepted, what reflects into 0 pending issues. Therefore, the security score is 10 out of 10..

    Summary

    The comprehensive audit of the customer's smart contract yields an overall score of 9.6. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.

    Risks

    If much more time passes between block.timestamp and beginningOfTheNewDayTimestamp than expected - the calculations of the time of subsequent snapshots will not be accurate, because they will not refer to the current time, but to an old, distant value.

    In current implementation, GovernorCountingSimple in _quorumReached function is not calculating votes against, what is problematic, as far as for calculations of Quorum all votes should be taken into account.

    In PoolParty protocol assumes that the value of the JPY token will be less than one dollar, which if it exceeds it will make the calculations incorrect

    Findings

    Code
    Title
    Status
    Severity
    F-2024-1497Any voting can be abused due to Chest ids duplicates passing possibility
    fixed

    Critical
    F-2024-1492Multiple unstake at once possible due to _releasableAmount incorrect calculations
    fixed

    Critical
    F-2024-1560claimWeeks does not burn tokens in StakingRewardDistribution
    fixed

    Medium
    F-2024-1547Voting power restored with minimal cliff period extension
    fixed

    Medium
    F-2024-1512Proposals are vulnerable to metamorphic attacks
    accepted

    Medium
    F-2024-1511Overestimated voting power in first freezing week
    fixed

    Medium
    F-2024-1563dailySnapshot can revert due to integer underflow
    fixed

    Low
    F-2024-1559Lack of upper bound Beneficiaries may lead to deny of service
    accepted

    Low
    F-2024-1510Missing fee validation in setFee function
    accepted

    Low
    F-2024-1509Voting power restored without cost after cliff period
    accepted

    Low
    1-10 of 11 findings

    Identify vulnerabilities in your smart contracts.

    Appendix 1. Severity Definitions

    When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.

    Reference on how risk scoring is done is available through the repository in our Github organization:

    Severity

    Description

    Critical
    Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

    High
    High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

    Medium
    Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

    Low
    Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score.
    • Severity

      Critical

      Description

      Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

      Severity

      High

      Description

      High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

      Severity

      Medium

      Description

      Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

      Severity

      Low

      Description

      Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score.

    Appendix 2. Scope

    The scope of the project includes the following smart contracts from the provided repository:

    Contracts in Scope

    contracts
    Chest.sol - contracts/Chest.sol
    DailySnapshot.sol - contracts/DailySnapshot.sol
    Governor.sol - contracts/Governor.sol
    GovernorVotes.sol - contracts/GovernorVotes.sol
    InvestorDistribution.sol - contracts/InvestorDistribution.sol
    JellyGovernor.sol - contracts/JellyGovernor.sol
    JellyTimelock.sol - contracts/JellyTimelock.sol
    JellyToken.sol - contracts/JellyToken.sol
    JellyTokenDeployer.sol - contracts/JellyTokenDeployer.sol
    LiquidityRewardDistribution.sol - contracts/LiquidityRewardDistribution.sol
    Minter.sol - contracts/Minter.sol
    OfficialPoolsRegister.sol - contracts/OfficialPoolsRegister.sol
    PoolParty.sol - contracts/PoolParty.sol
    RewardVesting.sol - contracts/RewardVesting.sol
    StakingRewardDistribution.sol - contracts/StakingRewardDistribution.sol
    TeamDistribution.sol - contracts/TeamDistribution.sol
    utils
    Ownable.sol - contracts/utils/Ownable.sol
    Vesting.sol - contracts/utils/Vesting.sol
    vendor
    prb

    Disclaimer