Introduction
We express our gratitude to the Re Protocol team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
The Re Protocol is a decentralized foundation built to invest in Reinsurance contracts in exchange for profits. The foundation itself will operate on multiple blockchain networks including but not limited to Arbitrum, Ethereum Mainnet, Avalanche, and Base.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Re |
| Audited By | Turgay Arda Usman, Niccolò Pozzolini |
| Approved By | Przemyslaw Swiatowiec |
| Website | https://re.xyz/→ |
| Changelog | 15/08/2024 - Preliminary Report, 04/09/2024 - Final Report |
| Platform | EVM, Avalanche, Arbiturm, Base |
| Language | Solidity |
| Tags | Insurance, ERC20 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Re
- Audited By
- Turgay Arda Usman, Niccolò Pozzolini
- Approved By
- Przemyslaw Swiatowiec
- Website
- https://re.xyz/→
- Changelog
- 15/08/2024 - Preliminary Report, 04/09/2024 - Final Report
- Platform
- EVM, Avalanche, Arbiturm, Base
- Language
- Solidity
- Tags
- Insurance, ERC20
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/re-protocol/re-defi→ |
| Commit | d099cbfe0043a33d38cf97a1f7f5e68330436282 |
Review Scope
- Repository
- https://github.com/re-protocol/re-defi→
- Commit
- d099cbfe0043a33d38cf97a1f7f5e68330436282
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are complete.
Technical description is provided.
Code quality
The development environment is configured.
Test coverage
Code coverage of the project is 42.11% (branch coverage).
Deployment and basic user interactions are covered with tests.
Interactions by several users are not tested thoroughly.
System Overview
The Re Protocol is a decentralized foundation built to invest in Reinsurance contracts in exchange for profits. The foundation itself will operate on multiple blockchain networks including but not limited to Arbitrum, Ethereum Mainnet, Avalanche, and Base. It has the following contracts:
PrivateInsuranceCapitalLayer — Manages and allocates capital within the private insurance layer of the protocol. PrivatePool — Represents a specialized risk pool within the private sector, managed independently from the public pools. ReToken — A governance and utility ERC20 token used for voting and participating in protocol governance and capital deployment decisions. USDRE — A stable token issued to depositors in exchange for USDC within the insurance layer, reflecting the current conversion price. USDRWA — A stablecoin designed for real-world asset transactions within the protocol. ConvertDecimals — A utility contract that manages the conversion of token amounts between different decimal formats. Executor — Manages the execution of specific protocol actions, including capital deployments and fund transfers. Math — Provides mathematical functions and utilities used across the protocol's smart contracts. Cell — A structure within the protocol allowing members to create and manage their own pools and capital deployments. DecentralizedFund — A fund governed by the protocol's members, used to invest in reinsurance contracts and other approved opportunities. InsuranceCapitalLayer — The main contract for managing the capital within the insurance layer, handling deposits, allocations, and redemptions. KYCRegistry — A contract that maintains the KYC status of members, ensuring compliance with verification requirements. MembershipFeeRegistry — Manages the collection and tracking of membership fees within the protocol. Pool — Represents an investment pool within the protocol, where members can allocate capital to participate in specific reinsurance opportunities. StableCoinManager — Handles the management and operations related to stablecoins within the protocol, including USDC transactions.
Privileged roles
The Cell Manager is responsible for creating and managing risk pools, negotiating terms, and raising capital within their assigned cell.
KYC’d members who participate in governance, propose new cells or pools, and redeem USDRE tokens for USDC.
The operator role is responsible for executing critical protocol functions, including managing settings, enabling/disabling features, and handling funds, often with centralized control.
The controller role typically oversees and manages the overall protocol's operations, ensuring that the protocol functions as intended and aligning with governance decisions, often involving strategic oversight rather than direct execution.
The owner role has the authority to add or remove stable coins from the whitelist, managing which stable coins are supported by the system.
The owner role can set the merkle tree root hash, update membership fee amounts, and claim collected membership fees.
The owner role can update the manager address of the cell and has overarching control over the cell's configuration.
The manager role is responsible for creating new pools, managing fees, and withdrawing fees from the pools deployed within the cell.
The controller role within a pool is responsible for the operational management of that specific pool, as defined when the pool is created.
Risks
Scope Definition and Security Guarantees: The audit does not cover all code in the repository, the governance part is missing. Contracts outside the audit scope may introduce vulnerabilities, potentially impacting the overall security due to the interconnected nature of smart contracts.
Centralized Minting to a Single Address: The USDRWA, ReToken contracts concentrate minting/burning tokens in a single address, raising the risk of fund mismanagement or theft, especially if key storage security is compromised. The function manualRebalance can be abused.
Single Points of Failure and Control: The project is fully or partially centralized, introducing single points of failure and control. This centralization can lead to vulnerabilities in decision-making and operational processes, making the system more susceptible to targeted attacks or manipulation.
Flexibility and Risk in Contract Upgrades: The project's contracts are upgradable, allowing the administrator to update the contract logic at any time. While this provides flexibility in addressing issues and evolving the project, it also introduces risks if upgrade processes are not properly managed or secured, potentially allowing for unauthorized changes that could compromise the project's integrity and security.
Dependency on Unaudited External Libraries: The project utilizes libraries or contracts without security audits, potentially introducing vulnerabilities. This compromises the security of the audited system, making it susceptible to attacks exploiting these external weaknesses.
Centralized Control of Minting Process: The token contract’s design allows for centralized control over the minting process, posing a risk of unauthorized token issuance, potentially diluting the token value and undermining trust in the project's economic governance.
Dynamic Array Iteration Gas Limit Risks: 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.
Centralized Oracles as Data Sources: The protocol utilizes centralized oracles for external data inputs. Dependence on a singular or limited set of data sources can introduce accuracy and manipulation risks, potentially affecting the DApp's operations and decision-making processes.
Centralized Governance Mechanisms: The smart contract system incorporates governance mechanisms that are not fully decentralized, potentially allowing a small number of participants to exert disproportionate influence over key decisions and changes, limiting community engagement and consensus.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-5369 | Denial of Service While Acquiring Oracle Data in rebalance Function | fixed | Medium | |
| F-2024-5223 | Potential Stale Data Usage in rebalance Function | fixed | Medium | |
| F-2024-5221 | Potential Denial of Service in rebalance Function | fixed | Medium | |
| F-2024-5015 | The Pool Deposit Amount Requirement Can Be Bypassed | fixed | Medium | |
| F-2024-5373 | Encoding in bytesToUint Function Leading to Supply Cap Bypass | fixed | Low | |
| F-2024-5329 | Lack of Validation for Over-Returning Capital in returnProfitAndCapital Function | fixed | Low | |
| F-2024-5316 | Inconsistent Metrics Due to Missing Decrement in cancelRedeemRequest Function | fixed | Low | |
| F-2024-5227 | Lack of Validation for Retrieved Balances in fulfillRequest Function | fixed | Low | |
| F-2024-5214 | Unclaimed Deposit Fees Are Often Unaccounted For When Moving Funds | fixed | Low | |
| F-2024-5016 | Unsafe ERC20 Transfers | fixed | 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/re-protocol/re-defi→ |
| Commit | d099cbfe0043a33d38cf97a1f7f5e68330436282 |
Scope Details
- Repository
- https://github.com/re-protocol/re-defi→
- Commit
- d099cbfe0043a33d38cf97a1f7f5e68330436282