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 how to n 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 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 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
Rujira.ui: Find official docs here. A list of interesting components from rujira.ui:
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 has been completed, then and only then ping Mark in the dedicated channel to doublecheck, 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 setup deployer address on a THORChain multisig if needed
4. Auditor (External) Review
Once you’ve gone through the interval 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 vulnerability 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 a 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/9R performs 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
Last updated