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.
title | content |
---|---|
Platform | EVM |
Language | Solidity |
Tags | Governance, Vesting |
Timeline | 18/04/2024 - 26/04/2024 |
Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
---|---|
Repository | https://github.com/Jelly-Labs/jelly-verse-contracts/tree/main→ |
Commit | 3331a1e |
Review Scope
- Commit
- 3331a1e
Audit Summary
10/10
95,52%
9/10
10/10
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 | |
---|---|
Name | Smart Contract Code Review and Security Analysis Report for Jellyverse |
Audited By | Jakub Heba, Ataberk Yavuzer |
Approved By | Ataberk Yavuzer |
Website | https://jellyverse.org→ |
Changelog | 30/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
- Website
- https://jellyverse.org→
- 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-1497 | Any voting can be abused due to Chest ids duplicates passing possibility | fixed | Critical | |
F-2024-1492 | Multiple unstake at once possible due to _releasableAmount incorrect calculations | fixed | Critical | |
F-2024-1560 | claimWeeks does not burn tokens in StakingRewardDistribution | fixed | Medium | |
F-2024-1547 | Voting power restored with minimal cliff period extension | fixed | Medium | |
F-2024-1512 | Proposals are vulnerable to metamorphic attacks | accepted | Medium | |
F-2024-1511 | Overestimated voting power in first freezing week | fixed | Medium | |
F-2024-1563 | dailySnapshot can revert due to integer underflow | fixed | Low | |
F-2024-1559 | Lack of upper bound Beneficiaries may lead to deny of service | accepted | Low | |
F-2024-1510 | Missing fee validation in setFee function | accepted | Low | |
F-2024-1509 | Voting power restored without cost after cliff period | accepted | Low |
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:
Scope Details | |
---|---|
Repository | https://github.com/Jelly-Labs/jelly-verse-contracts/tree/main→ |
Commit | 3331a1e0ff6def4aec7a9aa736b6e96b18140409 |
Whitepaper | https://app.jellyverse.org/whitepaper-jellyverse-june-2024.pdf→ |
Requirements | https://github.com/Jelly-Labs/jelly-verse-contracts/docs/*→ |
Technical Requirements | https://github.com/Jelly-Labs/jelly-verse-contracts/blob/main/README.md→ |
Scope Details
- Commit
- 3331a1e0ff6def4aec7a9aa736b6e96b18140409
- Technical Requirements
- https://github.com/Jelly-Labs/jelly-verse-contracts/blob/main/README.md→
Contracts in Scope
contracts/Chest.sol
contracts/DailySnapshot.sol
contracts/Governor.sol
contracts/GovernorVotes.sol
contracts/InvestorDistribution.sol
contracts/JellyGovernor.sol
contracts/JellyTimelock.sol
contracts/JellyToken.sol
contracts/JellyTokenDeployer.sol
contracts/LiquidityRewardDistribution.sol
contracts/Minter.sol
contracts/OfficialPoolsRegister.sol
contracts/PoolParty.sol
contracts/RewardVesting.sol
contracts/StakingRewardDistribution.sol
contracts/TeamDistribution.sol
contracts/utils/Ownable.sol
contracts/utils/Vesting.sol