Audit name:
[SCA] GG3 / Tokenomia Pro / Dec2024
Date:
Jan 13, 2025
Table of Content
Introduction
We express our gratitude to the GG3 team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
GG3 is a groundbreaking solution, synthesizing staking and vesting into a novel, high-performance flywheel.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for GG3 |
| Audited By | Turgay Arda Usman |
| Approved By | Ataberk Yavuzer |
| Website | https://gg3.org/→ |
| Changelog | 18/12/2024 - Preliminary Report |
| 07/01/2025 - Second Report | |
| 13/01/2025 - Final Report | |
| Platform | Ethereum |
| Language | Solidity |
| Tags | Staking, Vesting, ERC20 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for GG3
- Audited By
- Turgay Arda Usman
- Approved By
- Ataberk Yavuzer
- Website
- https://gg3.org/→
- Changelog
- 18/12/2024 - Preliminary Report
- 07/01/2025 - Second Report
- 13/01/2025 - Final Report
- Platform
- Ethereum
- Language
- Solidity
- Tags
- Staking, Vesting, ERC20
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/tokenomia-pro/gg-contracts→ |
| Commit | b33bdccf2d63a62e36428bb5c9afba3ec0765b3c |
Review Scope
- Commit
- b33bdccf2d63a62e36428bb5c9afba3ec0765b3c
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are provided .
Technical description is not provided.
Code quality
The code mostly follows the best practices and style guides
See informational findings for more details
The development environment is configured.
Test coverage
Code coverage of the project is 73.24% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage is missed.
Interactions by several users are not tested thoroughly.
System Overview
GG3 is protocol contains staking and vesting features with the following contracts:
Token — simple ERC-20 token that utilizes burnable features.
TokenVesting — enables time-based token distribution with optional cliffs and linear unlocking to align with requirements for staggered releases after the TGE (Token Generation Event), ensuring beneficiaries can withdraw tokens proportionally over time.
StaticStaking — allows users to stake tokens, earn rewards over time-based on a fixed APR (Annual Percentage Rate), and manage their staked funds with mechanisms for unlocking and withdrawing after predefined lockup and unbonding periods.
SimpleStaking — allows users to stake tokens, lock them for a predefined period, and earn rewards based on their staked amount, while also implementing mechanisms for locking, unbonding, and emergency withdrawal with configurable parameters.
Privileged roles
The owner can he owner can set the
baseTokenandextrTokenaddresses.The owner can configure the number of tokens distributed per second as rewards.
The owner can set the contract's start time when rewards begin accruing.
The owner can set the contract's end time when rewards stop accruing.
The owner can withdraw any unallocated or excess reward tokens from the contract.
The owner can withdraw all tokens (
baseTokenandextrToken) from the contract in case of an emergency.The owner can set the token reward percentage (APR).
The owner can add beneficiaries to the vesting schedule
The owner can change the vesting token address.
The owner can lock a schedule
Potential Risks
The functioning of the system significantly relies on specific external contracts. Any flaws or vulnerabilities in these contracts adversely affect the audited project, potentially leading to security breaches or loss of funds.
The project concentrates minting tokens in a single address, raising the risk of fund mismanagement or theft, especially if key storage security is compromised.
The project iterates over large dynamic arrays, which leads to excessive gas costs, risking denial of service due to out-of-gas errors, directly impacting contract usability and reliability.
Making external calls within loops increases the risk of gas exhaustion, potentially leading to failed transactions and reduced contract reliability, especially when processing large datasets.
The broad authorization model increases the risk of protocol control loss if any authorized address is compromised, potentially leading to unauthorized actions and significant financial loss.
The lack of multi-signature requirements for key operations centralizes decision-making power, increasing vulnerability to single points of failure or malicious insider actions, potentially leading to unauthorized transactions or configuration changes.
The token’s total supply is determined at deployment and cannot be verified beforehand, potentially limiting the project’s adaptability and economic model flexibility.
The absence of restrictions on state variable modifications by the owner leads to arbitrary changes, affecting contract integrity and user trust, especially during critical operations like minting phases.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-7728 | Missing isLocked Update in unsafeUnbond Function | mitigated | Medium | |
| F-2024-7723 | Publicly Accessible Burn Functions in Token Contract | accepted | Medium | |
| F-2024-7656 | Mismanagement of Lock State When Adding to Existing Stake | mitigated | Medium | |
| F-2024-7655 | Improper Sequence of instantReseal Call in deposit Function | fixed | Medium | |
| F-2024-7739 | Denial of Service (DoS) in multisendEther and multisend Due to Gas Exhaustion | accepted | Low | |
| F-2024-7731 | Checks Effect Interactions Pattern Violation | accepted | Low | |
| F-2024-7730 | Owner Can Withdraw Funds Using withdrawEmergency | accepted | Low | |
| F-2024-7729 | Owner Can Frontrun | accepted | Low | |
| F-2024-7726 | Lack of Balance Validation in addBeneficiaries Function | mitigated | Low | |
| F-2024-7734 | Unchecked Return Value | accepted | Observation |
Identify vulnerabilities in your smart contracts.
Appendix 1. Definitions
Severities
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. |
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.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/tokenomia-pro/gg-contracts→ |
| Commit | b33bdccf2d63a62e36428bb5c9afba3ec0765b3c |
| Whitepaper | https://docs.gg3.xyz→ |
| Requirements | N/A |
| Technical Requirements | N/A |
Scope Details
- Commit
- b33bdccf2d63a62e36428bb5c9afba3ec0765b3c
- Whitepaper
- https://docs.gg3.xyz→
- Requirements
- N/A
- Technical Requirements
- N/A
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of GG3, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Echidna → a tool used for fuzz-testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.
Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific echidna fuzzing suite was prepared for this task, and throughout the assessment, selected number of invariants were tested over 1,000,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
| [TokenVesting Invariants] | ||
| Beneficiaries' token balances should never be negative. | Passed | 1M |
| Withdrawals should never exceed a beneficiary's initial allocation. | Passed | 1M |
| Tokens should not be released before the contract is locked. | Passed | 1M |
| [Token Invariants]. | ||
| Token balances should never exceed the maximum allowed by the uint256 type. | Passed | 1M |
| Delegate address should only be set to valid, non-zero addresses. | Passed | 1M |
| Token transfers should not allow overdrafts or negative balances. | Passed | 1M |
| Burning tokens should reduce the owner's balance by the specified burn amount. | Passed | 1M |
| Transferring tokens should correctly update the balances of sender and recipient. | Passed | 1M |
| Delegate functionality should correctly handle spending power updates after transfers. | Passed | 1M |
| Total supply of tokens should remain consistent within the defined initial limits. | Passed | 1M |
| Delegate spending power logic should correctly reflect token movement between accounts | Passed | 1M |
| Token transfer operations should accurately reflect in the recipient's balance. | Passed | 1M |
Invariant
- [TokenVesting Invariants]
Test Result
Run Count
Invariant
- Beneficiaries' token balances should never be negative.
Test Result
- Passed
Run Count
- 1M
Invariant
- Withdrawals should never exceed a beneficiary's initial allocation.
Test Result
- Passed
Run Count
- 1M
Invariant
- Tokens should not be released before the contract is locked.
Test Result
- Passed
Run Count
- 1M
Invariant
- [Token Invariants].
Test Result
Run Count
Invariant
- Token balances should never exceed the maximum allowed by the uint256 type.
Test Result
- Passed
Run Count
- 1M
Invariant
- Delegate address should only be set to valid, non-zero addresses.
Test Result
- Passed
Run Count
- 1M
Invariant
- Token transfers should not allow overdrafts or negative balances.
Test Result
- Passed
Run Count
- 1M
Invariant
- Burning tokens should reduce the owner's balance by the specified burn amount.
Test Result
- Passed
Run Count
- 1M
Invariant
- Transferring tokens should correctly update the balances of sender and recipient.
Test Result
- Passed
Run Count
- 1M
Invariant
- Delegate functionality should correctly handle spending power updates after transfers.
Test Result
- Passed
Run Count
- 1M
Invariant
- Total supply of tokens should remain consistent within the defined initial limits.
Test Result
- Passed
Run Count
- 1M
Invariant
- Delegate spending power logic should correctly reflect token movement between accounts
Test Result
- Passed
Run Count
- 1M
Invariant
- Token transfer operations should accurately reflect in the recipient's balance.
Test Result
- Passed
Run Count
- 1M
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.