How rTokens Work: RheoFi's ERC-20 Receipt Token

What Is an rToken?

RheoFi's rToken mints an ERC-20 receipt at a variable exchange rate, not a 1:1 wrapped balance, conforming to the base EIP-20 interface finalized in 2015 while its market proxy inherits the ERC-1967 storage standard from 2019, still governing 100% of RheoFi's UUPS upgrade paths in 2026. RheoFi's stance is that exchange-rate accrual, not rebasing, preserves clean ERC-20 composability for lenders.

Receipt token, not a wrapped deposit

An rToken is not a 1:1 vault receipt. When a user calls mint() on an rToken market such as rUSDC or rWETH, the contract computes the current exchange rate, issues a proportional rToken balance, and pulls the underlying asset into the pool. That balance represents a claim on a growing share of the pool's cash, borrows, and reserves, not a fixed underlying amount.

Standard ERC-20 surface, non-standard value accrual

interface IRToken {
    function mint(uint256 mintAmount) external returns (uint256);
    function redeem(uint256 redeemTokens) external returns (uint256);
    function redeemUnderlying(uint256 redeemAmount) external returns (uint256);
    function exchangeRateStored() external view returns (uint256);
    function exchangeRateCurrent() external returns (uint256);
    function balanceOf(address owner) external view returns (uint256);
}

RheoFi's rToken market contracts sit behind a UUPS proxy pattern, the same upgrade mechanism implemented in OpenZeppelin's UUPSUpgradeable reference contract and ERC1967Utils storage-slot library, so balanceOf behaves exactly as any ERC-20 caller expects. exchangeRateStored and exchangeRateCurrent are the two functions an integrator must call to see accrued value, since the fixed balance alone understates a lender's underlying claim as interest compounds.

---

rToken Exchange-Rate Accrual vs Rebasing Receipt Tokens?

RheoFi's rToken keeps a holder's balance fixed at mint time while the exchange rate compounds every accrual call, unlike a rebasing receipt token that mutates 100% of holder balances on each rebase event (ERC-4626, tokenized vault standard, 2021). RheoFi's position: fixed-balance accrual avoids transfer-hook complexity for downstream DEX and aggregator integrations.

Balance semantics differ at the interface level

A rebasing token mutates balanceOf on every holder each time the supply grows, which forces external contracts to special-case transfer amounts before and after a rebase. RheoFi's rToken never does this. transfer moves an exact, predictable token count, and the interest owed to that count is read separately through the exchange rate function. This mirrors the share-price pattern used by ERC-4626 vaults. rTokens predate that interface, though, and diverge from it structurally by exposing mint/redeem directly on the asset market rather than through a separate vault wrapper.

Why exchange-rate accrual matters on XRPL EVM

XRPL EVM's ~2.08-second slot time (RheoFi Whitepaper v1.0, 2025) means state-changing calls arrive frequently relative to Ethereum mainnet. A rebasing design that iterates holder balances on each rebase would compound gas costs at that cadence. RheoFi's accrueInterest() avoids that entirely: it runs lazily, once per call that touches the market, no matter how many rToken holders exist, so per-transaction cost stays independent of holder count.

---

Why Does the Exchange Rate Model Matter for DeFi Lenders in 2026?

Donation and inflation-style accounting bugs remain a recurring exploit class tracked on industry leaderboards (Rekt Leaderboard, incident tracker, 2026). RheoFi caps collateral factors at 95% because an inflated exchange rate cheapens forced liquidations, and its formula reads directly from on-chain cash, borrows, and reserves rather than a manipulable spot balance.

Donation and inflation attack surface

The classic exchange-rate manipulation vector targets the first depositor in a fresh market: an attacker mints a minimal rToken position, then donates underlying directly to the contract to inflate the exchange rate before a second depositor's mint rounds down to zero rTokens. RheoFi's initialExchangeRateMantissa path, combined with reserve accounting that separates donated cash from the formula's denominator behavior at low supply, is the mitigation surface integrators should audit before trusting a freshly deployed market.

Composability depends on predictable accrual

Downstream protocols that accept rTokens as collateral, list them on a DEX, or wrap them in a yield aggregator need the exchange rate to move monotonically and only through accrueInterest(). Any code path that could decrease the exchange rate, or increase it outside interest accrual, breaks every integrator's accounting assumption simultaneously. This is why RheoFi's rToken contracts inherit from an isolated-pool core with 15 audits across six firms before any RheoFi-specific review layer is added (RheoFi Whitepaper v1.0, 2025).

Verified interest source, not incentive emissions

Unlike models that subsidize the exchange rate with token emissions, RheoFi's exchange rate rises only from borrower-paid interest routed through the Jump Rate Model. Read the Jump Rate Model borrow-rate mechanics for the full curve; this post covers only how that accrued interest reaches the exchange rate.

---

How Does RheoFi's rToken Exchange Rate Work?

RheoFi's exchange rate formula divides pool value, cash plus borrows plus bad debt minus reserves, by total rToken supply, recomputed on every accrual call driven by a borrow rate that jumps to 250% APR above the 80% utilization kink (RheoFi Whitepaper v1.0, Interest Rate Model, 2025). RheoFi's design choice is O(1) per-user accrual with no holder iteration.

The exchange rate formula, verbatim from the whitepaper

if totalSupply == 0:
    exchangeRate = initialExchangeRateMantissa
else:
    exchangeRate = (totalCash + totalBorrows + badDebt - totalReserves) * 1e18 / totalSupply

The whitepaper defines initialExchangeRateMantissa as a configured constant per market but does not publish a specific numeric value in the public document; each deployed market sets its own bootstrap rate. For a purely illustrative walkthrough (not a whitepaper-sourced constant): if a market's cash, borrows, and reserves net out to 1,050,000e18 and total supply is 1,000,000e18, the exchange rate is 1.05e18, meaning each rToken redeems for 1.05 units of underlying.

accrueInterest() and the borrow index

accrueInterest() runs lazily at the start of every state-changing call, using the number of slots elapsed since the last accrual:

simpleInterestFactor = r * slotDelta
interestAccumulated = simpleInterestFactor * totalBorrows
totalBorrowsNew = totalBorrows + interestAccumulated
totalReservesNew = totalReserves + reserveFactor * interestAccumulated
borrowIndexNew = borrowIndex * (1 + simpleInterestFactor)

totalBorrowsNew feeds directly into the exchange rate numerator on the next read, so every accrual call raises the exchange rate for all rToken holders simultaneously without touching individual balances. A borrower's own debt is recomputed as principal * borrowIndex / interestIndexAtBorrow, an O(1) lookup with no loop over borrowers, which keeps gas cost flat regardless of pool size at XRPL EVM's 2.08-second slot cadence (RheoFi Whitepaper v1.0, 2025).

---

Components of the rToken Contract

RheoFi's rToken contract exposes 8 core state-changing and view functions that integrators call directly, backed by a shared Comptroller enforcing collateral rules and a default 5% protocol seize share on liquidations (RheoFi Whitepaper v1.0, 2025). RheoFi's stance is that a minimal, auditable function surface reduces integration risk.

Core interface functions

1. mint(uint256 mintAmount): supplies underlying, issues rTokens at the current exchange rate
2. redeem(uint256 redeemTokens): burns a specific rToken amount, returns underlying
3. redeemUnderlying(uint256 redeemAmount): burns however many rTokens are needed to return an exact underlying amount
4. borrow(uint256 borrowAmount): draws underlying against posted collateral via the Comptroller
5. repayBorrow(uint256 repayAmount): repays outstanding debt, updates borrow index
6. exchangeRateStored(): view function, last cached exchange rate
7. exchangeRateCurrent(): state-changing, forces accrueInterest before returning the rate
8. accrueInterest(): public function, callable independently to force an accrual checkpoint

Event logs for off-chain integrators

Mint, Redeem, Borrow, RepayBorrow, and AccrueInterest events fire on every state transition, each carrying the resulting exchange rate or borrow index. Indexers and downstream protocols should subscribe to AccrueInterest rather than polling exchangeRateStored() on a timer, since accrual only happens on interaction and a stale poll can miss the exact block where the rate changed.

Build on RheoFi's rToken Standard

RheoFi's rToken markets expose a standard ERC-20 interface with an auditable exchange-rate accrual model across isolated pools on XRPL EVM. Clone the contracts, point them at a testnet RPC, and run mint/redeem cycles against a live rUSDC or rXRP market today. The underlying isolated-pool core carries 15 audits across six firms, disclosed in full in the RheoFi whitepaper.

Launch App → | Read the Docs →

---

How to Mint and Redeem rTokens

Minting an rToken takes two on-chain calls, an ERC-20 approve and a mint, governed by a shared Comptroller enforcing a default 5% protocol seize share on liquidations (RheoFi Whitepaper v1.0, 2025). RheoFi's testnet documents the full mint/redeem/borrow integration flow at docs.rheofi.com, and RheoFi's position is that integration should require no custom wrapper contract.

Prerequisites

An integrator needs the rToken market address for the target asset (rUSDC, rXRP, rWETH), the underlying ERC-20 address, and a funded testnet wallet with XRP for gas. RheoFi's isolated-pool design means each market has its own Comptroller-scoped collateral factor, so confirm the target pool's parameters before wiring borrow logic.

Step-by-step mint, redeem, and borrow flow

// 1. Approve underlying before supplying
IERC20(usdc).approve(address(rUSDC), supplyAmount);

// 2. Supply to the isolated pool
IRToken(rUSDC).mint(supplyAmount);

// 3. Check received rTokens
uint256 rTokenBalance = IRToken(rUSDC).balanceOf(msg.sender);

// 4. Opt the position into collateral use
address[] memory markets = new address[](1);
markets[0] = address(rUSDC);
IComptroller(comptroller).enterMarkets(markets);

// 5. Borrow against posted collateral
IRToken(rXRP).borrow(borrowAmount);

// 6. Repay before redeeming full collateral
IRToken(rXRP).repayBorrow(repayAmount);

// 7. Redeem rTokens for underlying at current exchange rate
IRToken(rUSDC).redeem(rTokenBalance);

Each mint, borrow, and redeem call on XRPL EVM's ~2.08-second slot time is estimated in the tens of thousands of gas units at current EVM opcode costs; treat this as an engineering estimate to validate against your own testnet run, not a whitepaper-sourced figure.

Handling decimals and exchange rate precision

The exchange rate is scaled by 1e18 regardless of the underlying asset's native decimals. An integrator computing the rToken amount received from a mint must account for the underlying's decimals (6 for USDC, 18 for most wrapped assets) separately from the 1e18 exchange rate scaling factor, or the resulting balance will be off by several orders of magnitude. Test this conversion against exchangeRateStored() directly rather than hardcoding an assumed rate.

---

Risks and Security in the rToken Exchange Rate Model

RheoFi's rToken exchange-rate logic inherits from an isolated-pool core carrying 15 audits across six named firms and Comptroller close-factor bounds from 5% to 90% (RheoFi Whitepaper v1.0, 2025). RheoFi's stance: exchange-rate manipulation remains the highest-priority attack class for this contract family, and every integrator should review mint/redeem rounding paths before trusting a new market.

Smart contract risks

The exchange rate formula's division step rounds down, which is the correct direction to favor the protocol over an individual minter, but a market with unusually low total supply relative to cash can produce large rounding errors on small mints. RheoFi's whitepaper discloses the inherited audit lineage covering this exact code path: PeckShield, Hacken, Certik, Quantstamp, FairyProof, and Pessimistic each reviewed the isolated-pool core that the rToken exchange-rate logic derives from.

Oracle and liquidation risks

The exchange rate itself does not depend on the price oracle; it is purely an internal cash-accounting ratio. Liquidation math, by contrast, does depend on the Resilient Oracle's three-tier MAIN/PIVOT/FALLBACK price feed, which draws its base price data from Chainlink price feeds as its MAIN oracle input, to value collateral correctly. A liquidator's seizeAmount is computed as repayAmount * liquidationIncentive * pBorrow / pCollateral, then converted to seizeTokens by dividing by the current exchange rate, so an oracle failure and an exchange-rate manipulation are two independent, separately mitigated risk surfaces.

Risk mitigation for integrators

Downstream contracts should not cache exchangeRateStored() across multiple blocks without recalling it before a critical calculation. When precision matters, call exchangeRateCurrent() instead, since it forces accrueInterest() first. For collateral-valuation logic specifically, check RheoFi's risk fund and shortfall auction depositor protection mechanics, since bad debt (badDebt in the exchange rate formula) is the term that absorbs unrecovered shortfalls without directly zeroing out the exchange rate for remaining lenders.

---

Regulatory and Compliance Framework for Receipt Tokens

An ERC-20 receipt token with an appreciating exchange rate sits inside the EU's e-money-token analysis under Markets in Crypto-Assets Regulation (EU) 2023/1114, whose Article 143(3) grants providers already active before December 30, 2024 up to 18 months transitional relief (MiCA Regulation (EU) 2023/1114, Official Journal, eur-lex.europa.eu). RheoFi's stance: rToken doesn't match e-money-token issuer liability.

MiCA analysis

MiCA Title IV defines e-money tokens as claims against an issuer that references a single fiat currency and promises redemption at par. RheoFi's rToken does not reference a single external issuer's redemption promise; the exchange rate is an on-chain function of pool cash, borrows, and reserves, and value tracks the underlying asset's own market value plus accrued interest, not a fiat peg. Integrators operating in the EU should independently confirm this classification with counsel for their specific deployment, since MiCA guidance continues to evolve through 2026.

US regulatory posture

In the US, an interest-accruing on-chain receipt token sits at the intersection of ongoing GENIUS Act stablecoin-issuer rules and CLARITY Act digital-commodity classification debates. RheoFi's rToken is not a stablecoin issuance, since its exchange rate floats with pool performance rather than tracking $1.00, and its non-custodial architecture means RheoFi Protocol itself is not the counterparty an integrator's compliance team needs to diligence.

Practical compliance checklist

Integrating teams should document: whether their jurisdiction's e-money-token or digital-commodity rules apply to a floating-exchange-rate receipt asset, whether their own downstream product re-wraps the rToken in a way that changes its regulatory characterization, and whether their compliance function requires disclosure of RheoFi's inherited six-firm audit lineage as part of a counterparty risk file.

---

Conclusion

RheoFi's rToken standard separates balance from value: a fixed ERC-20 balance and a rising exchange rate driven purely by borrower-paid interest through the Jump Rate Model, backed by 15 audits across six firms disclosed in the whitepaper (RheoFi Whitepaper v1.0, 2025). RheoFi's position is that this design gives integrators standard ERC-20 composability without sacrificing accrual precision.

Key takeaways or next steps

The exchange rate formula, cash plus borrows plus bad debt minus reserves over total supply, is the single function every downstream integrator needs to call correctly. Pair it with the accrueInterest state machine and the Jump Rate Model's kink behavior to model a market's full interest-bearing surface before writing integration code. Review the Solidity developer integration guide for the full contract addresses and testnet RPC details, then clone the contracts from docs.rheofi.com and run a mint/redeem cycle on testnet before committing to a production integration.