BlockApex (Auditor) was contracted by BullionFX (Client) for the purpose of conducting a Smart Contract Audit/Code Review. This document presents the findings of our analysis which started on 20th Nov 2022.
Name: Rain Protocol
Auditor: BlockApex
Platform: EVM-based / Solidity
Type of review: Manual Code Review | Automated Took Analysis
Document log: Initial Audit Completed: Nov 27th, 2022 Final Audit Completed: Nov 29th, 2022
Scope
The git-repository shared was checked for common code violations along with vulnerability-specific probing to detectmajor issues/vulnerabilities. Some specific checks are as follows:
Code review
Functional review
Reentrancy
Unchecked external call
Business Logics Review
Ownership Takeover
FT token API violation
Functionality Checks
Timestamp Dependence
Unchecked math
Access Control & Authorization
Gas Limit and Loops
Unsafe type inference
Escrow manipulation
DoS with (Unexpected) Throw
Implicit visibility level
Token Supply manipulation
DoS with Block Gas Limit
Deployment Consistency
Asset’s integrity
Transaction-Ordering Dependence
Repository Consistency
User Balances manipulation
Style guide violation
Data Consistency
Kill-Switch Mechanism
Costly Loop
Inheritance Ordering
Operation Trails & Event Generation
Project Overview
Rain Protocol is a set of building blocks that enable your token economy including staking, vesting, emissions, escrow, order book, verification, sale, and membership. Rain VM uses EVM making it fully compatible with all the EVM chains. DEMI has integrated Rain protocol’s Staking contracts.
System Architecture
Staking Factory Contract:
The system uses a design pattern called the ‘factory method’ to deploy homogenous contracts from the same parent & keeps a record of the child contracts that have been deployed by the factory. In this particular case, the system deploys a staking contract.
Staking Contract:
Staking contract is a modified version of a vault contract tokenized. It inherits all of the properties of the ERC-4626 contract which standardizes the interface for easily managing deposited tokens & their shares within the system. The contract also introduces a custom logic for maintaining its own internal ledger for share calculation through the checkpointing mechanism.
Methodology & Scope
The codebase was audited using a filtered audit technique. A pair of two (2) auditors scanned the codebase in an iterative process spanning over a time of One (1) week.
Starting with the recon phase, a basic understanding was developed and the auditors worked on developing presumptions for the developed codebase and the relevant documentation/whitepaper. Furthermore, the audit moved on with the manual code reviews with the motive to find logical flaws in the codebase complemented with code optimizations, software, and security design patterns, code styles, best practices, and identifying false positives that were detected by automated analysis tools.
AUDIT REPORT
Executive Summary
Our team performed a technique called “Filtered Audit”, where the contract was separately audited by four individuals. After a thorough and rigorous process of manual testing, an automated review was carried out using slither for static analysis. All the flags raised were manually reviewed and re-tested to identify the false positives.
Our team found:
# of issues
Severity of the risk
0
Critical Risk issue(s)
0
High Risk issue(s)
0
Medium
1
Low Risk issue(s)
1
Informatory issue(s)
KEY FINDINGS
#
Findings
Risk
Status
1
Potential Loss of Precision
Low
Acknowledged
2
Inexplicable inclusion of unused library
Informational
Fixed
DETAILED OVERVIEW
Critical-risk issues
No critical issues were found.
High-risk issues
No High-risk issues were found.
Medium-risk issues
No Medium-risk issues were found.
Low-risk issues
Potential Loss of Precision
File: stake/Stake.sol#L15
Description:
In contracts/math/FixedPointMath.sol the function scaleN will lead to precision loss if a number is scaled down to 18. There may arise a scenario in future development where a deposited token having a higher decimal (i.e > 18) may need to scale down to 18 decimals for logic consistency. The conversion either from or to 18 will lead to a loss in precision which may result in the dust amount being locked in the contract.
However, this function is not used in the current implementation of the staking contract to either scale up or down.
Recommendation:
Introduce a mechanism to manage the difference that was lost during the conversion. One way could be by storing the difference & using it to convert back.
DEMI Staking Audit - Report
Dev’s Response:
As noted staking contract does not use scaleN. Worth also noting that ERC4626 that the staking contract is based on dedicates a lot of the spec to rounding/dust handling, so if scaleN would be hypothetically used in the future it would still need to be 4626 compliant (which means always leaving dust from the underlying asset in the vault in the case of rounding issues) that's largely what the mulDiv is handling in openzeppelin's implementation and we wrap in the other fixed point math functions
As scaleN is a library contract it has no storage of its own so there's nowhere for it to save information about the lost precision directly, the best it could do is return two values, one representing the scaled value and one representing the lost precision. Currently, scaleN is only used in expressions in the interpreter as a provided opcode, so I'm not sure if it's something on the average expression author's radar to be worrying about or ready to handle (juggling 2 values on the stack to avoid some dust).
it's probably worth documenting all this though as it's worth pointing out as something to consider for anyone who does care about it.
DEMI Staking Audit - Report
Auditor’s Response
The auditors agree with the devs.
Informatory issues and Optimizations
1. Inexplicable inclusion of unused library
File: stake/Stake.sol#L15
Description:
The staking contract imports a library called FixedPointMath.sol that is not used within the scope of the contract.
Recommendation: Remove the unused import along with its using statement.
// import "../math/FixedPointMath.sol"; // using FixedPointMath for uint256;
Alleviation: This issue is fixed.
DISCLAIMER
The smart contracts provided by the client for audit purposes have been thoroughly analyzed in compliance with the global best practices to date w.r.t cybersecurity vulnerabilities and issues in smart contract code, the details of which are enclosed in this report.
This report is not an endorsement or indictment of the project or team, and they do not in any way guarantee the security of the particular object in context. This report is not considered, and should not be interpreted as an influence, on the potential economics of the token, its sale or any other aspect of the project.
Crypto assets/tokens are the results of the emerging blockchain technology in the domain of decentralized finance and they carry with them high levels of technical risk and uncertainty. No report provides any warranty or representation to any third-Party in any respect, including regarding the bug-free nature of code, the business model or proprietors of any such business model, and the legal compliance of any such business. No third party should rely on the reports in any way, including for the purpose of making any decisions to buy or sell any token, product, service, or other assets. Specifically, for the avoidance of doubt, this report does not constitute investment advice, is not intended to be relied upon as investment advice, is not an endorsement of this project or team, and it is not a guarantee as to the absolute security of the project.
Smart contracts are deployed and executed on a blockchain. The platform, its programming language, and other software related to the smart contract can have its vulnerabilities that can lead to hacks. The scope of our review is limited to a review of the Solidity code and only the Solidity code we note as being within the scope of our review within this report. The Solidity language itself remains under development and is subject to unknown risks and flaws. The review does not extend to the compiler layer or any other areas beyond Solidity that could present security risks.
This audit cannot be considered as a sucient assessment regarding the utility and safety of the code, bug-free status, or any other statements of the contract. While we have done our best in conducting the analysis and producing this report, it is important to note that you should not rely on this report only - we recommend proceeding with several independent audits and a public bug bounty program to ensure the security of smart contracts.
Our team performed a technique called “Filtered Audit”, where the contract was separately audited by two individuals. After their thorough and rigorous process of manual testing, an automated review was carried out using Mythril, MythX, and Slither. All the flags raised were manually reviewed and re-tested.
Spin is a DeFi derivative infrastructure built on NEAR Protocol, a reliable and scalable L1 solution. The on-chain order book solution offered by Spin provides a CEX-competitive experience to DeFi users.
Rain Protocol lets you build web3 economies at any scale.Rain scripts are a combination of low level functions (opcodes) like addition and subtraction and very high level functions like fetching an ERC20 balance at a given snapshot ID (Open Zeppelin), or fetching a chainlink oracle price.