The Money on Chain - RIF on Chain bounty program covers two dual-token stablecoin protocols within one shared smart-contract ecosystem in the Rootstock blockchain.
Money on Chain uses RBTC collateral, while RIF on Chain uses RIF collateral. Each aims to provide a fully on-chain, censorship-resistant, USD-pegged and overcollateralized stablecoin, alongside low-maintenance, cost-efficient leveraged exposure for long-term holders of its respective collateral asset.
Both protocols are governed through the MOC token and share core governance, oracle, fee-flow, and supporting contracts.
Step-by-step PoC Required
KYC required
Rewards
Rewards by Threat Level
Mainnet assets:
Reward amount is 10% of the funds directly affected up to a maximum of:
$10,000Minimum reward to discourage security researchers from withholding a bug report:
$5,000Payouts are handled by Money on Chain directly and are denominated in USD. Payouts are done in DOC (Bitcoin-collateralized stablecoin on rootstock), RBTC (Bitcoin pegged 1:1 on Rootstock), or Bitcoin on mainnet.
Program Overview
The program focuses on protecting the integrity, solvency, and intended operation of both protocols. Key priorities include safeguarding collateral; ensuring that collateralization, accounting, and risk calculations remain correct; preserving users’ ability to mint and redeem stablecoins (senior claims) and collateral tokens (residual claims); and preventing unauthorized or malicious value extraction.
The program also covers the decentralized oracle infrastructure that supplies prices to the protocols. Oracle data must remain accurate, resilient, and economically incentivized to preserve the intended decentralization guarantees and prevent manipulation, stale pricing, replay, or other failures that could affect collateralization, redemptions, or protocol value.
Finally, governance is a core security boundary. MOC-token governance must enforce its intended voting thresholds, staking requirements, delays, and execution rules, preventing governance capture or proposal execution without the required authorization.
AI-assisted research is welcome and may be used to help identify vulnerabilities, prepare concise reports, and develop proofs of concept. However, we ask that AI-generated content remains accurate, evidence-based, and responsive to the specific protocol and questions raised during triage. Escalated reports receive human review, and we expect follow-up discussion to be conducted meaningfully with a human researcher. Reports that cannot be substantively supported or discussed may be flagged as spam on our end.
Known Issues
KYC required
The submission of KYC information is a requirement for payout processing.
Proof of Concept
Proof of concept is always required for all severities.
Prohibited Activities
-
- Disassembly or reverse engineering of binaries for which source code is not published, not including smart contract bytecode
- Any testing on mainnet or public testnet deployed code; all testing should be done on local-forks of either public testnet or mainnet
- Any testing with pricing oracles or third-party smart contracts
- Attempting phishing or other social engineering attacks against our employees and/or customers
- Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
- Any denial of service attacks that are executed against project assets
- Automated testing of services that generates significant amounts of traffic
- Public disclosure of an unpatched vulnerability in an embargoed bounty
- Any other actions prohibited by the Immunefi Rules
Feasibility Limitations
The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity.
Therefore, Immunefi has developed a set of feasibility limitation standards which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.