Introduction
We express our gratitude to the RAIN team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Rain is a smart contract for the RAIN token, an ERC-20 upgradeable token with controlled inflation mechanics and governance features.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for RAIN |
| Audited By | Viktor Lavrenenko, Panagiotis Konstantinidis |
| Approved By | Ivan Bondar |
| Website | http://rain.one/→ |
| Changelog | 19/08/2025 - Preliminary Report |
| 22/08/2025 - Final Report | |
| Platform | Arbitrum |
| Language | Solidity |
| Tags | ERC20; Proxy; Upgradeable; UUPS; Oracle |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for RAIN
- Audited By
- Viktor Lavrenenko, Panagiotis Konstantinidis
- Approved By
- Ivan Bondar
- Website
- http://rain.one/→
- Changelog
- 19/08/2025 - Preliminary Report
- 22/08/2025 - Final Report
- Platform
- Arbitrum
- Language
- Solidity
- Tags
- ERC20; Proxy; Upgradeable; UUPS; Oracle
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/rain1-labs/rain-token→ |
| Commit | f439c92 |
| Remediation Commit | 7b397e8 |
Review Scope
- Commit
- f439c92
- Remediation Commit
- 7b397e8
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:
The project’s purpose is described.
Business logic is provided.
Use cases are described.
Project’s features are described.
Technical description is partially provided:
Key function descriptions are described for the files in the scope.
Architectural overview is missing.
Roles and authorization are provided.
No information on used technologies provided.
Code quality
Best practices are followed.
The development environment is configured.
Test coverage
Code coverage of the project is 33.33% (branch coverage).
Deployment and basic user interactions are partially covered with tests.
Negative cases coverage is partially missed.
Interactions by several users are not tested thoroughly.
System Overview
RAIN is an ERC20 token following contracts:
RainToken.sol - an upgradeable ERC-20 token that implements a controlled inflation system. The contract mints a fixed USD value of tokens ($50,000) daily to a designated treasury address, with the actual token amount calculated based on real-time price data from an oracle. It has the following attributes:
Name: RAIN.
Symbol: RAIN.
Decimals: 18.
Total supply: Not limited.
Privileged roles
The owner of the
RainTokencan:execute the daily minting via the
dailyMinting()function.set the address of the price oracle feed via the
setOraclePriceFeed()function.update the treasury address via the
updateTreasury()function.upgrade the proxy's implementation via the
upgradeToAndCall()function.transfer the ownership to another address via the
transferOwnership()function.
Potential Risks
The implemented dailyMinting() function highly depends on the external RAIN-USD price oracle not covered by the audit. This reliance introduces risks if these external contract is compromised or contains vulnerabilities, affecting the audited project's integrity.
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.
Allowing the admin to set oracle addresses without constraints or verification mechanisms introduces the risk of incorrect or malicious oracle selection, affecting the accuracy of data and potentially leading to financial losses.
The token ecosystem grants a single entity the authority to implement upgrades or changes. This centralization of power risks unilateral decisions that may not align with the community or stakeholders' interests, undermining trust and security.
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.
The contract suite allows for immediate upgrades without a mandatory review or waiting period, increasing the risk of rapid deployment of malicious or flawed code, potentially compromising the system's integrity and user assets.
The owner holds unilateral authority over minting, oracle configuration, treasury updates, and contract upgrades. Relying on a single key for these critical operations presents a significant centralization risk, which could be mitigated through the adoption of a multi-signature scheme.
The project depends on a single oracle price feed to determine mint amounts. This reliance introduces risks of inaccurate issuance or denial of service if the feed is manipulated, malfunctioning, or unavailable, directly affecting the system’s integrity.
The whitepaper indicates that minting is intended to occur daily after the 90-day lock period. However, there is a potential risk that minting may be executed at irregular intervals, deviating from the stated schedule.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1221 | PriceFeed Integration Lacks Safeguards Compromising Minting Policy | mitigated | Medium | |
| F-2025-1224 | Misaligned USD Cap Calculation Due to USDT Peg Assumption | fixed | Observation | |
| F-2025-1222 | Redundant State Initialization | fixed | Observation | |
| F-2025-1221 | Duplicated Token Name and Symbol Can Lead to Confusion | accepted | Observation | |
| F-2025-1221 | Missing Visibility on totalInflationMinted Prevents Tracking of Total Minted Inflation | fixed | Observation | |
| F-2025-1221 | Missing Two-Step Ownership Transfer Increases Risk of Permanent Owner Loss | fixed | Observation | |
| F-2025-1220 | Floating Pragma | 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/rain1-labs/rain-token→ |
| Commit | f439c92ddc28aaa54360ba18e212ca3147a79625 |
| Remediation Commit | 7b397e81af0828a1f2c63ea7a0e1f35352e60de3 |
| Whitepaper | https://whitepaper.rain.one/→ |
| Requirements | README.md |
| Technical Requirements | README.md, NatSpec |
Scope Details
- Commit
- f439c92ddc28aaa54360ba18e212ca3147a79625
- Remediation Commit
- 7b397e81af0828a1f2c63ea7a0e1f35352e60de3
- Whitepaper
- https://whitepaper.rain.one/→
- Requirements
- README.md
- Technical Requirements
- README.md, NatSpec
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:
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.