# 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](/developers/stagenet-deployment-guide.md) * 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](https://ui.rujira.network/install) and[ Rujira.js](https://gitlab.com/thorchain/rujira-ui/-/tree/dev/packages/rujira.js?ref_type=heads) library. Here’s a list of useful topics both * Rujira.js: * [Account Provider](https://gitlab.com/thorchain/rujira-ui/-/blob/dev/packages/rujira.js/src/accounts.ts?ref_type=heads#L4): 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](https://gitlab.com/thorchain/rujira-ui/-/blob/dev/packages/main/src/main.tsx?ref_type=heads) * [Msg interface](https://gitlab.com/thorchain/rujira-ui/-/blob/dev/packages/rujira.js/src/msgs.ts?ref_type=heads#L14): 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](https://gitlab.com/thorchain/rujira-ui/-/tree/dev/packages/rujira.js/src/msgs?ref_type=heads) * Rujira.ui: Find official docs[ here](https://ui.rujira.network/usage). A list of interesting components from rujira.ui: * [Displaying / Handling Decimals](https://ui.rujira.network/numbers) * [Tabs](https://ui.rujira.network/tabs?tab=one) * [TxButton](https://ui.rujira.network/tx-button): 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](https://ui.rujira.network/denomicons): 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](/developers/setting-up-a-thorchain-multisig.md)) * Link to the **GitHub/Gitlab repo** including: * Well-structured **source code** (example: [RUJI Trade](https://gitlab.com/thorchain/rujira/-/tree/main/contracts/rujira-fin?ref_type=heads)) * [README.md](http://readme.md) in **plain language** describing the contract’s purpose (example:[ Rujira Merge Contracts](https://gitlab.com/thorchain/rujira/-/tree/d74d3dc4e2d384aef36af39bc200b59ed8206331/contracts/rujira-merge)) 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](https://gitlab.com/thorchain/rujira/-/blob/main/contracts/rujira-fin/src/events.rs?ref_type=heads) 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](https://gitlab.com/thorchain/thornode) with all the information listed below to obtain permissions for contracts to go live on THORChain mainnet. Example:[ RUJI Perps Permission MR](https://gitlab.com/thorchain/thornode/-/merge_requests/4062) * Contract **bytecode** * **Deployer address** (generate using [Setting Up a THORChain Multisig](/developers/setting-up-a-thorchain-multisig.md)) * Link to the **GitHub/GitLab repo** * Link to most recent **audit** of the code (example: [RUJI Perps audit](https://github.com/fyeo-io/public-audit-reports/blob/main/Code%20Audit%20Reports/2025/Levana/Levana%20-%20Security%20Code%20Review%20of%20Ruji%20Perps%20v1.0.pdf)) ### 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](https://gitlab.com/thorchain/rujira/-/blob/main/RELEASES.md?ref_type=heads) with commit id, checksum value and audit link, contracts are ready for mainnet deployment following [Mainnet Deployment Guide](/developers/mainnet-deployment-guide.md) 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 and
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.rujira.network/developers/review-and-audit-guide.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.