NAMI Protocol Rujira Index Product - THORChain / Rujira

1. Introduction

THORChain engaged Halborn to conduct a security assessment of the Nami Index contracts, beginning on May 13th, 2025 and ending on May 19th, 2025. This security assessment was scoped to the smart contracts in the Nami GitHub repository. Commit hashes and further details can be found in the Sources section of this report.

Nami Index is a protocol that enables the creation and management of tokenized index vaults on top of Thorchain. It allows users to deposit a single asset and receive diversified exposure across multiple assets according to predefined weights. The protocol handles rebalancing, swapping, and accounting through a set of CosmWasm smart contracts that interact with Thorchain’s liquidity network.

2. Caveats

All remediations described in this report were completed prior to the following commit, which serves as a consolidated snapshot of the final codebase. Although remediations may have been implemented across multiple earlier commits, this single commit includes all changes and can be used for verification purposes:

833f72787ee26d141008d2bb620cf324436a6d08

Below are the checksums for the deployed contracts:

3. Assessment Summary

The team at Halborn assigned a full-time security engineer to verify the security of the 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 is to:

• Ensure that smart contract functions operate as intended

• Identify potential security issues with the smart contracts

In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which have been partially addressed by the Nami team. The main ones were the following:

• Restrict affiliate fee injection by enforcing a whitelist and storing fee parameters on-chain.

• Prevent fee evasion by accumulating fractional fees in state or using ceiling rounding methods.

• Ensure deposit logic uses up-to-date amount_per_share by reordering rebalances.

• Limit Callback execution to known swap contracts by verifying the sender against the allocation map.

• Isolate and track the exact quote_denom amount received in the first swap before performing the second during reallocation.

• Enforce automatic rebalancing after relevant events or based on elapsed time in NAV index.

• Support batched allocation updates to verify that total weights sum to 1 within a single atomic call.

• Use separate min_return values for multi-step swaps or validate the final output instead of individual steps.

• Validate that the registered denom matches the swap contract’s base denom and is not the quote token.

• Reject duplicate allocation entries by checking for existing denom values before insertion.

4. 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 recommended to uncover flaws in logic, process, and implementation; automated testing techniques help enhance coverage of the code and can quickly identify items that do not follow the security best practices. The following phases and associated tools were used during the assessment:

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

• Manual code read and walk through.

• Manual Assessment of use and safety for the critical Rust variables and functions in scope to identify any arithmetic related vulnerability classes.

• Architecture related logical controls.

• Cross contract call controls.

• Scanning of Rust files for vulnerabilities(cargo audit)

• Review and verification of integration tests.