Review and Audit Guide

This page outlines the audit and review process required before deploying contracts and applications to THORChain mainnet.

Review Process

Before any deployment to mainnet, all contracts go through a structured review and audit process from stagenet to mainnet. This involves technical verification, governance-level review, and clear communication of the code’s purpose and security posture.

1. Deploy and Test on Stagenet

• Deploy the application and contracts to Stagenet, which is a permissionless test environment. See the Stagenet Deployment Guide

• Once deployed and functional, notify a reviewer (typically Mark and/or PM) with the URL to test the application and contracts making up the application.

Before requesting a review of your deployed contracts on Stagenet, make sure to also test that the UI follows one of the following guidelines:

• If you are building as an independent app, you will host your own UI. You are free to use Rujira UI components for convenience and to stay on theme.

• If you are building a new core app as part of the Rujira Alliance, you will need to integrate your app into the main Rujira UI, using the Rujira.ui and Rujira.js library. Here’s a list of useful topics for both:

  • Rujira.js:

    • Account Provider: A single provider that helps you manage the different accounts of a user and gives you the signer as well. See more about Implementation Main Rujira Page

    • Msg interface: A generic representation of a message type. This can either be encoded as a L1 with a memo, base layer with a MsgDeposit, or app layer with MsgExecuteContract

    • Individual Msg types

  • Rujira.ui: Find official docs here. A list of interesting components from rujira.ui:

    • Displaying / Handling Decimals

    • Tabs

    • TxButton: Fully functional button that takes a msg to be executed as an input, encodes it for the right network, signs it with the correct signer

    • IconDenom: Renders the icon for any token

2. Request Review

After successful testing on Stagenet, submit the following information in a dedicated channel on Discord to the core Rujira team including Hans and Mark:

• Contract bytecode

• Deployer address (generate using Setting Up a THORChain Multisig)

• Link to the GitHub/Gitlab repo including:

  • Well-structured source code (example: RUJI Trade)

  • README.md in plain language describing the contract’s purpose (example: Rujira Merge Contracts)

Before submitting a request to review, make sure to go through the following checklist:

• Source code matches deployed bytecode

• Repo contains README and plain-language description

• Code is readable, modular, and reviewed for common exploits

• Permissions and roles (e.g., admin, cap settings) are properly scoped

• Dependencies and external calls are reviewed

• Contract(s) emit events that are (1) Individual and (2) Well-namespaced for the contract name, see contracts/rujira-fin/src/events.rs as a guiding example

3. Technical (Internal) Review

Once all points in the general checklist above have been completed, then and only then ping Mark in the dedicated channel to double-check, before Hans starts an internal review of the contracts:

• Verifying that the submitted hashes match the deployed bytecode on stagenet.

• Ensuring that dependencies (e.g., imported CosmWasm libraries) and compiler versions are explicitly locked to prevent mismatches or compilation inconsistencies.

• Helping set up deployer address on a THORChain multisig if needed.

4. Auditor (External) Review

Once you’ve gone through the internal review process, your contracts are ready for an external review by an auditor. This includes:

• Get in touch with Mark giving a status after the technical review and the latest commits + repos that an auditor should review.

• Mark will find a suitable and reliable auditor for your contracts. Depending on the type of contracts, the Rujira team might help you fund part or all of the audit costs.

• Once an auditor is found, a dedicated group chat with the auditor is set up with the start and delivery date of the audit.

The role of the auditor is to

• Ensure the contract logic is aligned with the provided source code and documentation.

• Assessing security vulnerabilities such as: Reentrancy, Integer overflows/underflows, Denial of service (DoS), Front-running and MEV exposure, Insecure randomness sources

• Check for best practices in access control, rate-limiting, caps, and upgradability. Note that contracts involving sensitive logic (e.g., admin roles, asset caps) must include appropriate control mechanisms.

5. Request Permissions for Mainnet

Once both internal and external review has been completed, submit an MR to THORNode with all the information listed below to obtain permissions for contracts to go live on THORChain mainnet. Example: RUJI Perps Permission MR

• Contract bytecode

• Deployer address (generate using Setting Up a THORChain Multisig)

• Link to the GitHub/GitLab repo

• Link to most recent audit of the code (example: RUJI Perps audit)

6. Final Approval

• Members of ThorSec/TC core team perform the final review, assessing overall project readiness, risk exposure and any potential node operator / governance concerns.

• Upon approval, the application is listed in RELEASES.md with commit id, checksum value and audit link, contracts are ready for mainnet deployment following Mainnet Deployment Guide

THORChain upgrades in 3-week cycles, which means new contracts that have been approved will be slotted into the next upgrade. Upgrades to the network take effect when supermajority has been reached (⅔). You can find the version number, how old the current version is, and follow how many nodes upgraded on https://thorchain.net/network and https://thorchain.net/network/votes