Audit name:
[SCA] Brainedge | Brainedge-Contracts | Nov2024
Date:
Dec 26, 2024
Table of Content
Introduction
We express our gratitude to the Brainedge team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Brainedge is a learn-to-earn platform, composed by a token, a vesting contract and a staking contract.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Brainedge |
| Audited By | Niccolò Pozzolini |
| Approved By | Przemyslaw Swiatowiec |
| Website | https://www.brainedge.ai→ |
| Changelog | 27/11/2024 - Preliminary Report; 26/12/2024 Remediation Report |
| Platform | Polygon |
| Language | Solidity |
| Tags | Staking, Vesting, ERC20 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Brainedge
- Audited By
- Niccolò Pozzolini
- Approved By
- Przemyslaw Swiatowiec
- Website
- https://www.brainedge.ai→
- Changelog
- 27/11/2024 - Preliminary Report; 26/12/2024 Remediation Report
- Platform
- Polygon
- Language
- Solidity
- Tags
- Staking, Vesting, ERC20
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/Brain-Edge/brainedge-contracts/→ |
| Commit | 6c0126f |
Review Scope
- Commit
- 6c0126f
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are not provided.
Technical description is provided.
Code quality
The development environment is configured.
Test coverage
Code coverage of the project is 30.47% (branch coverage).
Deployment and basic user interactions are covered with tests.
Interactions by several users are not tested thoroughly.
System Overview
Brainedge is a learn-to-earn platform that integrates a native token, a vesting contract, and a staking contract. The "Brainedge Learn Token" (LEARN) is used to reward users for educational activities. The vesting contract ensures tokens are distributed over time, promoting sustained engagement. The staking contract allows users to lock their tokens to earn additional rewards, encouraging token retention and stability.
Privileged roles
Vesting contract owner capabilities:
Set a Vesting Schedule: The admin can set a vesting schedule for a user using the setSchedule function.
Set Multiple Vesting Schedules: The admin can set multiple vesting schedules for multiple users with setSchedules.
Set Schedules by Template: The admin can apply a template schedule to multiple users with specific allocations using setSchedulesByTemplate.
Withdraw Tokens: The admin can withdraw tokens accidentally sent to the contract using saveTokens.
Update Token Custodian: The admin can update the address of the token custodian with seTtokenCustodian.
Staking contract owner capabilities:
Update Emission Rate: Change the rate at which reward tokens are distributed per second.
Pause/Unpause Contract: Toggle the paused state of the contract, which affects user interactions.
Update Token Custodian: Set a new address for the token custodian, which holds the reward tokens.
Update Signer: Change the address used for signature verification.
Save Tokens: Withdraw any tokens accidentally sent to the contract, except for the deposit token.
Potential Risks
Centralized Minting to a Single Address: 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 staking smart contract locks both the staked funds and the accrued rewards during the lock period. This approach is atypical in staking contracts, where users generally expect to receive their rewards continuously, even while their principal is locked. The current logic restricts users from accessing their rewards until the lock period concludes, which may not align with user expectations.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-7380 | Locked Rewards During Staking Period | mitigated | High | |
| F-2024-7378 | Inappropriate Bonus Application Post Lock Period | mitigated | High | |
| F-2024-7376 | Threshold Level Overwrite in Unlocked Stake Pool | fixed | High | |
| F-2024-7379 | Emergency Withdrawal Functionality Restriction | fixed | Medium | |
| F-2024-7375 | Incorrect Stake Limit Check Prevents Adding to Unlocked Stake | fixed | Low | |
| F-2024-7371 | Misaligned Incentives in Lock Periods for Staking Rewards | fixed | Low | |
| F-2024-7367 | Incomplete Validation in setSchedule Function | fixed | Low | |
| F-2024-7377 | Redundant Parameters in Deposit Signature Verification | fixed | Observation | |
| F-2024-7370 | Use of Magic Numbers and Lack of Readability in Long Number Literals | fixed | Observation | |
| F-2024-7369 | Inefficient Use of uint8 Index in For Loops | fixed | Observation |
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/Brain-Edge/brainedge-contracts/→ |
| Commit | 6c0126fdaceb3aff3b096ddaa67cc5a83a7b4102 |
| Technical Requirements | https://docs.google.com/document/d/1MNY3JY-bLZZ6nBHsjN45FB9fkqmXqNFzCzMZqVXY8nw/edit?usp=sharing→ |
Scope Details
- Commit
- 6c0126fdaceb3aff3b096ddaa67cc5a83a7b4102
Assets in Scope
Appendix 3. Additional Valuables
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:
Monitoring new schedule setting and token claiming in the vesting contract.
Monitoring deposit, claim and witdraw user actions in the staking contract.
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.