Rain v2 - Jupiter (formerly Rain Protocol)

1. Introduction

Rain Protocol engaged Halborn to conduct a security assessment of the bank and defi-lending programs from June 30th to July 25th, 2025. The security assessment was scoped to the smart contracts provided in the GitHub repository rain-v2, commit hashes and further details can be found in the Scope section of this report.

Rain Protocol is a modular lending platform composed of two programs Bank and Defi-Lending. The Bank program enables users to create either shared or personal banks, where liquidity providers (LPs) can deposit funds that are either borrowed by lending pools or delegated to MarginFi Protocol. The Defi-Lending program provides the core lending mechanism for facilitating loans, repayments, loan extensions, and liquidations through the use of pools. It also enables borrowers to repay their loans by selling collateral directly for the borrowed amount. A distinctive feature of the protocol is its time based liquidation model, where loans are liquidated strictly based on their expiration time, rather than the supplied collateral simplifying the liquidation logic.

2. Assessment Summary

Halborn was provided 4 weeks for the engagement and assigned 3 full-time security engineers to review the security of the Solana Programs in scope. The engineers are blockchain and smart contract security experts with advanced smart contract hacking skills, and deep knowledge of multiple blockchain protocols.

The purpose of the assessment is to:

• Identify potential security issues within the Solana Program.

• Ensure that smart contract functionality operates as intended.

In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were mostly addressed by the Rain Protocol team. The main ones were the following:

• Introduce a prior validation of the 'is_compounding_enabled' flag from the pool configuration before invoking 'pool.new_loan' in extend_loan.

• Iterate over the provided 'currency' vector during pool creation and explicitly validate each entry by calling the 'is_correct' method.

• Provide the corresponding bank's token program to the 'repay' CPI call.

• Reorder the logic in deposit function in the vault to perform the validation before modifying the 'deposited' field ensuring the unlimited deposit case is still allowed.

• Add a validation in 'check_swap_instruction' to ensure the provided destination token account to the swap matches the 'quote_vault'.

• Add a validation to forbid delegate operations in shared banks.

  
  
  

3. Test Approach and Methodology

Halborn performed a combination of a manual review of the source code and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of the program assessment. While manual testing is recommended to uncover flaws in business logic, processes, and implementation; automated testing techniques help enhance coverage of programs and can quickly identify items that do not follow security best practices.

The following phases and associated tools were used throughout the term of the assessment:

• Research into the architecture, purpose, and use of the platform.

• Manual program source code review to identify business logic issues.

• Mapping out possible attack vectors.

• Thorough assessment of safety and usage of critical Rust variables and functions in scope that could lead to arithmetic vulnerabilities.

• Scanning dependencies for known vulnerabilities (cargo audit).

• Local runtime testing (anchor test).