RUJI Trade FIN v1.1 - THORChain / Rujira

1. Introduction

THORChain engaged Halborn to conduct a security assessment of the Rujira FIN contracts, beginning on November 10th, 2025 and ending on November 18th, 2025. This security assessment was scoped exclusively to the updates introduced in version 1.1.0 of Rujira FIN, as the core system had already been reviewed in a previous audit. Commit hashes and further details can be found in the Sources section of this report.

Rujira FIN is a decentralized order book protocol built on top of Thorchain, enabling spot trading of native assets without wrapped tokens. It handles order creation, matching, and settlement fully on-chain.

2. Assessment Summary

The team at Halborn assigned a full-time security engineer to verify the security of the updated smart contracts. The security engineer is a blockchain and smart-contract security expert with advanced penetration testing, smart-contract hacking, and deep knowledge of multiple blockchain protocols.

The purpose of this assessment was to:

• Ensure that the updated smart contract functions operate as intended

• Identify potential security issues introduced or affected by the new logic in version 1.1.0

In summary, Halborn identified a few improvements to further harden the system and reduce the likelihood or impact of potential risks, which have been completely addressed by the Rujira development team. The most relevant ones were the following:

• Forbid denom changes during migration unless the contract is fully shut down or enforce a pre-migration check ensuring no active orders or pools exist.

• Deduplicate or reject repeated MarketMaker addresses during initialization before storing them.

• Replace inv().unwrap() with a checked inversion that errors on zero or tiny prices, and validate MM price inputs before use.

• Reject zero or negative tick values during configuration and validate ticks explicitly in Tick::new and Tick::validate.

• Explicitly reject Fixed <= 0 before tick validation, add guards to prevent underflow in truncation, and ensure validation returns a contract error instead of panicking.

• Replace the intermediate multiplication with amount.multiply_ratio(...) to avoid overflow and add tests with values near Uint128::MAX.

3. Test Approach and Methodology

Halborn performed a combination of manual and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of this assessment. While manual testing is essential to uncover flaws in logic, process, and implementation, automated techniques enhance coverage and quickly detect deviations from best practices.

The following phases and associated tools were used during the assessment:

• Research into architecture, version 1.1.0 updates, and overall protocol purpose.

• Manual code read and walkthrough of the updated Rust modules.

• Manual assessment of critical arithmetic operations, rate handling, and overflow/underflow protections.

• Logical review of order matching, bucket aggregation, and MarketMaker calculation flow.

• Validation of safe handling for zero and invalid price conditions.

• Review and verification of integration and unit tests covering the updated logic.