On this page
ROC integrations must account for two collateral buckets and a shared USDRIF token. Start from the current deployment and contract interfaces rather than a legacy single-collateral example. A bucket is a separate accounting compartment for one collateral asset.
Read the architecture
The protocol repository contains deployment modules, contracts and fork tests for the multicolateral upgrade. The whitepaper describes the economic model and the roles of the RIF bucket, DOC bucket and Multi Collateral Guard.
RIF and DOC are collateral assets (AC); USDRIF is the pegged token (TP). RIFPRO (RIFP in the dApp) is the collateral or residual token (TC) of the RIF bucket. Do not infer identical parameters or available operations across buckets.
The Multi Collateral Guard coordinates the collateral buckets and stabilization procedures. Each bucket accounts for its own collateral and USDRIF liabilities; the guard coordinates system-wide actions without creating a second USDRIF token. Coverage compares collateral value with stablecoin liabilities. Required coverage and recent-volume controls determine whether an operation is admissible.
Verify deployment details
Confirm the chain, deployment version, addresses, ABI and token decimals from the matching deployment artifacts and verified contracts. Avoid copying contract addresses from screenshots, tickers or unrelated networks. Governance can upgrade implementations and parameters.
Verify that the operations you integrate are available in the selected interface. This guide covers USDRIF minting and redemption with RIF or DOC, RIFP operations and combined operations with RIF.
Model the operation lifecycle
Separate token approval, operation submission, queuing and final execution in your application. Track operation identifiers and execution events; do not mark a request completed from its submission receipt alone.
For a combined mint, account for both token outputs and the total collateral input. For a combined redemption, account for both required token inputs and their allowances. Handle maximum collateral, minimum outputs, fees, rBTC execution costs and failures explicitly.
Use current constraints
Quote amounts against the selected bucket’s state. Coverage, attributed USDRIF liabilities and volume controls can limit operations. A global mintable or redeemable figure cannot replace per-operation validation.
Read the fork tests for DOC-bucket issuance/redemption and RIF combined minting, then test against the intended environment. The tests demonstrate contract behavior; they do not establish an address or parameter as current for your deployment.
Operation reference
| Flow | Inputs | Outputs |
|---|---|---|
| RIF bucket mint | RIF | USDRIF or RIFP |
| RIF bucket redeem | USDRIF or RIFP | RIF |
| DOC bucket mint | DOC | USDRIF |
| DOC bucket redeem | USDRIF | DOC |
| RIF combined mint / redeem | RIF / RIFP + USDRIF | USDRIF + RIFP / RIF |
USDRIF is a single fungible token. A redemption’s available amount depends on the selected bucket’s USDRIF liabilities and coverage, not the issuance origin of the user’s tokens. Residual value belongs to the bucket’s TC after accounting for TP liabilities.
An integration needs a wallet or signer on the intended chain, the correct input balances and rBTC for execution costs. Read current state, calculate the quote and its bounds, check allowances for every ERC-20 input, submit missing approvals, then submit the operation. Record its identifier, track the queue and execution receipt, handle a failed execution, and refresh balances only after the final outcome. Combined redemption requires two token balances and potentially two allowances.
For example, DOC → USDRIF consumes DOC collateral and produces USDRIF. Its reverse consumes USDRIF and returns DOC from that bucket. RIF combined mint consumes the full quoted RIF amount and produces USDRIF and RIFP together; its reverse consumes both tokens. These are protocol issuance/redemption flows, not a bridge or an external liquidity-pool swap.