Audit name:
[SCA] Renatus | Renatus Protocol Contracts | Jan2025
Date:
Feb 7, 2025
Table of Content
Introduction
We express our gratitude to the Renatus team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Renatus is a platform for launching AI agents backed by defi tokens, in which agent capabilities are unlocked as the token progresses on its bonding curve. The bonding curve phase bootstraps liquidity for a PancakeSwap v3 pool between the agent token and the Renatus token. This pool is automatically created when the bonding curve completes and the token graduates. Of this liquidity, 50% is locked forever and 50% is assigned to holders, vested over a period of months (+ cliff) set by the token creator.
The repository has been moved. The latest version of the previous repository can be found in the new repository at https://github.com/Renatus-AI-Official/renatus-protocol-contracts-public →, commit ID f921a1d.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Renatus |
| Audited By | David Camps Novi |
| Approved By | Grzegorz Trawiński |
| Website | https://renatus.ai/→ |
| Changelog | 23/01/2025 - Preliminary Report; 07/02/2025 - Final Report; |
| Platform | BSC |
| Language | Solidity |
| Tags | AMM, ERC-20, Fee-on-transfer, Vesting. |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Renatus
- Audited By
- David Camps Novi
- Approved By
- Grzegorz Trawiński
- Website
- https://renatus.ai/→
- Changelog
- 23/01/2025 - Preliminary Report; 07/02/2025 - Final Report;
- Platform
- BSC
- Language
- Solidity
- Tags
- AMM, ERC-20, Fee-on-transfer, Vesting.
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/SilexoDeFi/renatus-protocol-contracts→ |
| Commit | Initial Commit - fe56152; Final Comit - a58b4b2; |
Review Scope
- Commit
- Initial Commit - fe56152; Final Comit - a58b4b2;
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are included.
Technical description is provided.
Code quality
The development environment is configured.
NatSpec is included across the contracts.
The code is clear and straightforward.
Test coverage
Code coverage of the project is not configured.
Hardhat testing and coverage is not configured.
Testing is executed via scripts in ./scripts/unit_tests/ folder.
Extensive testing is provided in the aforementioned scripts.
System Overview
Renatus is a platform for launching AI agents backed by defi tokens, in which agent capabilities are unlocked as the token progresses on its bonding curve. The bonding curve phase bootstraps liquidity for a PancakeSwap v3 pool between the agent token and the Renatus token. This pool is automatically created when the bonding curve completes and the token graduates. Of this liquidity, 50% is locked forever and 50% is assigned to holders, vested over a period of months (+ cliff) set by the token creator.
The project consists of the following contracts:
RenatusToken: protocol token, used as the base coin to pay and create new Agent tokens, as well as the base coin for swaps.
AgentToken: implementation contract to be deployed for users that want to create a new agent.
RenatusPair: implementation contract to be deployed when a new Agent is created, in order to bootstrap liquidity, in exchange for Renatus token. Once the threshold liquidity is reached in this pair contract, the Agent token will become graduated.
GraduatedToken: once the threshold liquidity is reached for a pair Agent-Renatus, this token will be deployed. Users will be able to migrate their Agent token for the corresponding Graduated token.
Bonding: entry point for users to create new Agent tokens, as well as the related contracts and interactions (deploy Pair, start liquidity, etc.).
RenatusFactory: enables the deployment of new Renatus Pairs.
LiqLocker: locks liquidity from the Renatus Pair once the graduation is reached and manages migrations from Agent to Graduated tokens. Deploys and interacts with PancakeV3 pools as well as their NonFungiblePositionManager in order to create each Graduated token position, collect fees, etc.
Privileged roles
Owner & DEFAULTAMINROLE: defined in system contracts in order to setup administrative parameters to make the protocol run successfully.
Bonding: owns deployed Agent tokens.
GraduatedTokenOwner: introduced by users that launch tokens via Bonding contract. Get the ownership of the graduated token.
Potential Risks
The project utilizes Solidity version 0.8.20 or higher, which includes the introduction of the PUSH0 (0x5f) opcode. This opcode is currently supported on the Ethereum mainnet but may not be universally supported across other blockchain networks. Consequently, deploying the contract on chains other than the Ethereum mainnet, such as certain Layer 2 (L2) chains or alternative networks, might lead to compatibility issues or execution errors due to the lack of support for the PUSH0 opcode. In scenarios where deployment on various chains is anticipated, selecting an appropriate Ethereum Virtual Machine (EVM) version that is widely supported across these networks is crucial to avoid potential operational disruptions or deployment failures.
The functioning of the system significantly relies on PancakeV3 external contracts. Any flaws or vulnerabilities in these contracts adversely affect the audited project, potentially leading to security breaches or loss of funds.
Dependence on external DeFi protocols inherits their risks and vulnerabilities. This might lead to direct financial losses if these protocols (i.e. Pancake) are exploited, indirectly affecting the audited project.
The project concentrates minting tokens (RenatusToken) in a single address, raising the risk of fund mismanagement or theft, especially if key storage security is compromised.
Users can launch tokens without any limits to the parameters liqVestingPeriodSecs and liqVestingCliffSecs. This allows the possibility that tokens are effectively locked forever in the LiqLocker contract, although this will result in no vesting rewards for original holders.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-8411 | Incorrect Computation of Unclaimed Fees results in Loss of Funds | fixed | Medium | |
| F-2025-8351 | Mismatch Between Contract and its Interface Causes Calls to Revert | fixed | Medium | |
| F-2025-8408 | Unchecked Slippage Parameters May Lead to Loss of Funds | accepted | Observation | |
| F-2025-8404 | Redundant Function Call | fixed | Observation | |
| F-2025-8134 | Missing Zero Address Checks | accepted | Observation | |
| F-2025-8431 | Unbounded Fee Parameters | fixed | Observation | |
| F-2025-8406 | State Variable is Missing Visibility | fixed | Observation | |
| F-2025-8403 | Multiplication After Division may Result in Precision Loss | accepted | Observation | |
| F-2025-8133 | Floating Pragma | fixed | Observation | |
| F-2025-8407 | Testing Code Should be Removed from Final Contracts | accepted | 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/SilexoDeFi/renatus-protocol-contracts→ |
| Commit | fe56152 |
| Whitepaper | - |
| Requirements | ./README.md; ./docs/ |
| Technical Requirements | ./README.md |
Scope Details
- Commit
- fe56152
- Whitepaper
- -
- Requirements
- ./README.md; ./docs/
- Technical Requirements
- ./README.md
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of Renatus, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry →, 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, 12 invariants were tested over 3100 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
| Any address different than address(0) can launch tokens | Passed | 256 |
| Tokens can be launch with any supply from MIN to MAX defined | Passed | 256 |
| GraduatedTaxRate cannot exceed 10% in launch | Passed | 259 |
| Tokens can be launched with any vesting period and cliff | Passed | 259 |
| Launch initial buy cannot exceed max initial buy | Passed | 259 |
| Swap any amount of token1 via Renatus Pair | Passed | 260 |
| Swap any amount of token0 via Renatus Pair | Passed | 260 |
| Graduate tokens with any GraduatedTaxRate | Passed | 260 |
| Graduate tokens with any supply from MIN to MAX defined | Passed | 260 |
| Graduate tokens with any vesting period and cliff | Passed | 260 |
| Any user can perform a migration | Passed | 260 |
| Non-holders cannot perform a migration | Passed | 260 |
Invariant
- Any address different than address(0) can launch tokens
Test Result
- Passed
Run Count
- 256
Invariant
- Tokens can be launch with any supply from MIN to MAX defined
Test Result
- Passed
Run Count
- 256
Invariant
- GraduatedTaxRate cannot exceed 10% in launch
Test Result
- Passed
Run Count
- 259
Invariant
- Tokens can be launched with any vesting period and cliff
Test Result
- Passed
Run Count
- 259
Invariant
- Launch initial buy cannot exceed max initial buy
Test Result
- Passed
Run Count
- 259
Invariant
- Swap any amount of token1 via Renatus Pair
Test Result
- Passed
Run Count
- 260
Invariant
- Swap any amount of token0 via Renatus Pair
Test Result
- Passed
Run Count
- 260
Invariant
- Graduate tokens with any GraduatedTaxRate
Test Result
- Passed
Run Count
- 260
Invariant
- Graduate tokens with any supply from MIN to MAX defined
Test Result
- Passed
Run Count
- 260
Invariant
- Graduate tokens with any vesting period and cliff
Test Result
- Passed
Run Count
- 260
Invariant
- Any user can perform a migration
Test Result
- Passed
Run Count
- 260
Invariant
- Non-holders cannot perform a migration
Test Result
- Passed
Run Count
- 260
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.