RheoFi Isolated-Pool Architecture on XRPL EVM

What Is an Isolated-Pool Money Market?

Isolated-pool money markets ring-fence each collateral asset inside a dedicated Comptroller with its own risk parameters, preventing one bad asset from draining the whole protocol. Lending TVL reached $37.4B by June 2026 (DeFiLlama, June 2026), and RheoFi deploys isolated pools natively on the XRPL EVM Sidechain to keep XRP, rUSDC, and rWETH markets fully independent.

The Isolated-Pool Primitive

An isolated pool is a self-contained lending market. Each pool contains one or more listed assets, a Comptroller that enforces collateral factors and close factors, a set of rToken contracts (one per listed asset) that hold cash and mint receipt tokens, a JumpRateModel that prices borrows algorithmically, a PriceOracle configuration, a RiskFund address that receives reserves, and a ShortfallAuction contract that handles bad debt if it arises. State that would normally be shared across an entire protocol lives inside a single pool boundary.

Why the Boundary Matters

The pool boundary is a security perimeter, not an organizational one. A price manipulation on one asset can only trigger liquidations for positions collateralized by that asset in that pool. A bad-debt event only depletes the risk fund attached to that pool. A parameter change made through governance targets one pool at a time. Depositors in other pools continue accruing interest without exposure to events they did not opt into.

RheoFi's Position on XRPL EVM

The RheoFi whitepaper records the design decision to build every market as an isolated pool from day one, rather than beginning with a shared-pool topology and migrating later. XRPL EVM's fast, low-cost transaction environment makes per-pool contract deployment operationally cheap, so the fixed cost of pool creation does not deter listing new assets.

---

Isolated Pools vs Shared-Pool Money Markets

Shared-pool designs mix collateral into one solvency bucket. When Immunefi tracked $680M in DeFi losses across 2025 (Immunefi, January 2026), a disproportionate share came from single-collateral failures cascading across shared markets. RheoFi isolates every asset in its own Comptroller so a mispriced feed or bad-debt event stays inside one pool.

Contagion Behavior Under Stress

The core distinction is what happens on the day a listed asset fails. In a shared-pool design, all borrowers of any asset in the pool are simultaneously exposed to that failure through the shared reserve and shared liquidation queue. In an isolated pool, exposure is bounded by the pool's own Comptroller state. RheoFi's blast-radius design puts a hard perimeter around each market.

Feature Comparison

Why Per-Pool Configuration Beats Uniform Policy

A single set of risk parameters cannot correctly price both a deep-liquidity stable asset and a smaller-cap volatile asset. Shared-pool protocols must compromise: too conservative and stable-asset borrowers subsidize risky-asset borrowers, too permissive and stable-asset depositors underwrite risky-asset volatility. RheoFi's per-pool parameterization removes that trade-off. Each pool holds parameters calibrated to its own asset profile.

---

Why Isolated Pools Matter for XRPL EVM in 2026

XRPL EVM Sidechain went live June 30, 2025, opening EVM smart-contract execution to XRP holders (xrplevm.org, 2025). DeFi lending across EVM chains reached $37.4B in TVL by June 2026 (DeFiLlama, June 2026), and RheoFi's isolated pools let new XRPL-native assets list without endangering depositors already funding existing markets.

Ecosystem-Growth Fit

An early-stage ecosystem sees episodic asset listings and uneven liquidity depth across those listings. A shared-pool protocol on such a chain must either delay listings until every candidate asset meets the strictest risk bar, or accept elevated contagion risk on each new addition. RheoFi's per-pool design removes that binary. New markets ship with their own parameter set and their own risk perimeter.

Chain Economics Favor Per-Pool Deployment

XRPL EVM offers fast, low-cost execution as documented in the RheoFi whitepaper. Deploying a new Comptroller, rToken, JumpRateModel, and PriceOracle set for a new pool remains operationally cheap. Governance can list a new asset without amortizing the deployment cost across every existing depositor.

First-Mover Positioning

RheoFi is the first algorithmic isolated-pool money market native to XRPL EVM. The design pattern matters more on a young chain than on a mature one: mistakes in a shared-pool topology are harder to unwind once TVL scales, while an isolated-pool topology is additive by construction. Every future asset listing adds surface area, not compounding risk.

---

How Does RheoFi's Isolated-Pool Architecture Work?

RheoFi assigns each listed asset a dedicated Comptroller contract governing collateral factors up to 95% and close factors between 5% and 90% per pool (RheoFi Whitepaper, April 2026). Every pool holds its own risk fund, rTokens, and Jump Rate Model. UUPS proxies allow upgrades without migrating deposits.

Contract Boundary of a Pool

The pool boundary is defined by the address of its Comptroller. All rToken contracts in the pool point to the same Comptroller, and the Comptroller holds the market list, per-asset collateral factors, per-asset close factors, the pool's oracle address, the pool's risk-fund address, and the shortfall-auction address. To determine which pool an rToken belongs to, an integrator reads its comptroller() accessor.

Parameter Bounds Enforced by the Codebase

Comptroller code enforces protocol-wide limits documented in the whitepaper. MIN_CLOSE_FACTOR is 5%, MAX_CLOSE_FACTOR is 90%, and MAX_COLLATERAL_FACTOR is 95%. DEFAULT_PROTOCOL_SEIZE_SHARE is 5% and DEFAULT_INCENTIVE_BPS is 10%. Governance may configure any per-pool value inside these bounds, but the bounds themselves are non-negotiable at the codebase level. Attempts to set values outside the range revert on-chain.

Upgrade and Governance Path

Every pool contract sits behind a UUPS proxy conforming to the EIP-1822 pattern (EIP-1822, 2019). Upgrades route through the AccessControlManager and a Timelock, meaning any parameter change or implementation swap carries a documented delay. That delay exists so depositors can exit before a change takes effect if they disagree with governance direction. The proxy pattern also decouples upgrade authority from depositor balances: implementation changes do not touch user state.

Rate Accrual and Interest Flow

When any state-changing rToken function runs, it calls accrueInterest() first. The rToken snapshots the pool's borrow rate from the pool's JumpRateModel, updates the pool's borrowIndex, and moves a governance-configured share of interest into the pool's reserves. Reserves eventually sweep to the pool's RiskFund contract. Every step of that flow reads and writes state scoped to a single pool address.

---

Components of RheoFi's Isolated-Pool Stack

Eight core contracts define each RheoFi isolated pool: Comptroller, rToken, JumpRateModel, PriceOracle, RiskFund, ShortfallAuction, RewardsDistributor, and AccessControlManager (GitHub, 2026). Comptroller bounds fix a maximum 95% collateral factor and a 5-90% close-factor window. The whitepaper documents 15 audits across 6 firms as the security baseline.

Contract-by-Contract Breakdown

1. Comptroller: Enforces market membership, collateral factors (bounded at 95% max), close factors (bounded 5%-90%), pause flags, and borrow caps. Answers getAccountLiquidity(address) for any position in the pool.
2. rToken: ERC-20 receipt token conforming to the token standard (EIP-20, 2015). Holds the pool's cash for a single underlying asset, tracks borrowIndex, and exposes mint, redeem, borrow, repayBorrow, and liquidateBorrow.
3. JumpRateModel: Stateless view contract holding the pool's four rate parameters (base rate, slope, jump multiplier, kink). Returns per-block borrow and supply rates. RheoFi's testnet defaults are 0%/10%/250%/80% (RheoFi Whitepaper, April 2026).
4. PriceOracle (Resilient Oracle): MAIN, PIVOT, and FALLBACK feed configuration, each backed by a Chainlink price feed (RheoFi Whitepaper, April 2026) with a BoundValidator guarding against out-of-band ticks.
5. RiskFund: Receives protocol reserves swept from each rToken. Serves as the first-loss buffer when bad debt appears in the pool.
6. ShortfallAuction: Handles residual bad debt after risk-fund coverage. Auctions off the shortfall to bidders posting collateral in accepted assets.
7. RewardsDistributor: Optional per-pool incentive contract that streams external reward tokens to depositors or borrowers on a governance-defined schedule.
8. AccessControlManager (ACM): Central authority mapping role holders to permitted actions across every contract in the pool. Combined with a Timelock, ACM enforces the governance delay on any upgrade or parameter change.

Inherited Security Baseline

---

Deploy Against a Fully Audited Isolated-Pool Money Market

RheoFi's per-pool Comptroller, rToken, and rate model give integrators a bounded contract surface for every asset they touch.

Open a pool on testnet, read live rates, and stage borrow flows against the deployed contract set today.

Security lineage covers 15 engagements across 6 firms. Built natively on XRPL EVM.

Launch App → | Read the Docs →

---

How to Integrate With a RheoFi Isolated Pool?

Integrators call three view functions on the target pool's rToken and Comptroller to obtain balances, borrow amounts, and account liquidity (GitHub, 2026). RheoFi's ERC-20 rToken preserves standard token semantics for wallets and aggregators serving the $37.4B DeFi lending sector (DeFiLlama, June 2026), with pool state readable via a bounded interface.

Prerequisites

Before writing integration code, confirm the target pool's Comptroller address, the rToken address for each asset your contract will touch, the pool's oracle configuration, and the current governance-set collateral factor for each asset. All four values live in the RheoFi developer documentation and can be verified on-chain via the Comptroller's public accessors.

Minimal Solidity Interfaces

interface IRToken {
    function mint(uint256 mintAmount) external returns (uint256);
    function redeem(uint256 redeemTokens) external returns (uint256);
    function borrow(uint256 borrowAmount) external returns (uint256);
    function repayBorrow(uint256 repayAmount) external returns (uint256);
    function balanceOf(address owner) external view returns (uint256);
    function borrowBalanceStored(address account) external view returns (uint256);
    function exchangeRateStored() external view returns (uint256);
    function comptroller() external view returns (address);
}

interface IComptroller {
    function enterMarkets(address[] calldata rTokens) external returns (uint256[] memory);
    function exitMarket(address rToken) external returns (uint256);
    function getAccountLiquidity(address account)
        external view returns (uint256 error, uint256 liquidity, uint256 shortfall);
    function markets(address rToken)
        external view returns (bool isListed, uint256 collateralFactorMantissa);
}

Step-by-Step Integration

1. Enter the market. Call enterMarkets([rTokenAddress]) on the pool's Comptroller. This flags the rToken as active collateral for your account inside that pool.

2. Approve the underlying asset. Grant the rToken contract an ERC-20 allowance for the amount you plan to supply.

3. Supply liquidity.

IRToken rToken = IRToken(rTokenAddress);
uint256 err = rToken.mint(depositAmount);
require(err == 0, "mint failed");

You receive rTokens whose exchangeRateStored scales as pool interest accrues.

1. Query account liquidity. Before borrowing, verify headroom:

IComptroller comptroller = IComptroller(comptrollerAddress);
(uint256 error, uint256 liquidity, uint256 shortfall)
    = comptroller.getAccountLiquidity(address(this));
require(error == 0 && shortfall == 0, "unhealthy position");

1. Borrow within limits. Call borrow(uint256 amount) on the borrow-side rToken. The Comptroller enforces the pool's collateral factor and reverts if the position would fall short.

2. Monitor rate and utilization on each block of interest. Poll the JumpRateModel through the rToken:

address rateModel = rToken.interestRateModel();
uint256 util = IInterestRateModel(rateModel).utilizationRate(
    rToken.getCash(), rToken.totalBorrows(), rToken.totalReserves()
);

Or subscribe to the rToken's AccrueInterest event to receive updates without polling.

1. Repay and redeem. Call repayBorrow(uint256 amount) to close outstanding debt, then redeem(uint256 rTokenAmount) to withdraw underlying plus accrued interest.

Cross-Pool Considerations

An account's collateral in Pool A does not underwrite a borrow in Pool B. Each isolated pool maintains independent liquidity accounting. Multi-pool strategies must post collateral separately in every pool they borrow from. That constraint is a security guarantee, not a limitation: it is what keeps a failure in one market from touching another.

---

Risks and Security in Isolated-Pool Design

DeFi exploit losses across all protocols fell to $680M in 2025 from a $2.62B peak in 2022 (Immunefi, January 2026). Isolation contains blast radius but does not eliminate oracle, governance, or single-asset risks. RheoFi mitigates each with the Resilient Oracle, Timelock governance, and a per-pool risk fund funded from interest.

Oracle Risk Inside a Pool

Every isolated pool wires to a Resilient Oracle configuration with MAIN, PIVOT, and FALLBACK price feeds, each backed by a Chainlink data feed (RheoFi Whitepaper, April 2026). A BoundValidator contract rejects prices that deviate more than a governance-set percentage from the pivot. Isolation limits an oracle-manipulation blast radius to a single pool, but the pool itself remains exposed to whatever depth its own feed offers.

Governance Risk and the Timelock Delay

Every parameter change routes through the AccessControlManager and a Timelock. That delay is a mitigation against key compromise: an attacker who takes over a governance role cannot instantly reset collateral factors or swap the rate model. The delay is also a coordination window for depositors who disagree with a change; they can exit the pool before the change activates.

Single-Asset Concentration Inside a Pool

Isolation reduces cross-pool risk but concentrates within-pool risk. A borrower in a single-asset pool has no diversification benefit. RheoFi's per-pool risk fund and shortfall-auction contract are the on-chain response: reserves accrue continuously from interest, the RiskFund absorbs first-loss bad debt, and the ShortfallAuction handles anything larger by auctioning the shortfall to solvent bidders.

Codebase Provenance

The isolated-pool contracts inherit review coverage from 15 prior audit engagements across PeckShield, Hacken, Certik, Quantstamp, FairyProof, and Pessimistic. Every contract listed in the Components section above sits within that inherited scope, and the contract sources are published under an open-source license (GitHub, 2026) for independent review before any deposit.

---

Regulatory and Compliance Framework

MiCA (EU 2023/1114) became enforceable December 30, 2024, applying to a DeFi sector that reached $37.4B in lending TVL (EUR-Lex, December 2024). Isolated pools ease the compliance argument because each market's risk parameters, oracle, and collateral list are individually inspectable on-chain. RheoFi's per-pool disclosures give institutional integrators an audit trail shared-pool designs cannot match.

MiCA and Per-Pool Transparency

MiCA (Markets in Crypto-Assets Regulation, EU 2023/1114, applicable December 30, 2024) covers asset-referenced tokens and e-money tokens, and its whitepaper and disclosure regime for crypto-asset issuers is directionally relevant to programmable rate systems that publish parameters on-chain. In a shared-pool design, an integrator has to reason about entangled parameters across dozens of assets. In RheoFi's isolated pools, each market publishes its own parameter set on-chain, and each market can be assessed in isolation for compliance review.

DORA and Per-Pool Vendor Assessment

DORA (Digital Operational Resilience Act, EU 2022/2554, applicable January 17, 2025) requires financial entities to document resilience assessments of third-party ICT dependencies. Each RheoFi isolated pool exposes a bounded contract dependency surface: one Comptroller, one rToken per underlying, one JumpRateModel, one PriceOracle. Institutional operators can produce DORA-aligned assessments per pool rather than for the whole protocol at once.

Compliance Corner

• Each RheoFi pool is a discrete, on-chain-enforced compliance boundary. Collateral factor, close factor, oracle configuration, rate parameters, and risk-fund balance are readable on any block by any actor.
• Codebase provenance is public: contracts sit in a documented repository (GitHub, 2026) under prior audit coverage from PeckShield, Hacken, Certik, Quantstamp, FairyProof, and Pessimistic.
• XRPL EVM Sidechain positioning is documented by the XRPL Foundation (xrplevm.org, 2025); institutional integrators should review chain-level positioning alongside protocol-level compliance work.

---

Conclusion

RheoFi's isolated-pool architecture ships with a 95% maximum collateral factor, per-pool risk funds, and UUPS proxies conforming to the standard's proxy-storage separation rules (EIP-1822, 2019). Every pool remains upgradeable through Timelock governance without touching depositor balances. Builders gain a per-market design surface, not a single shared risk envelope.

What Builders Should Take Away

Every RheoFi market is one Comptroller, one rToken per asset, one JumpRateModel, one Resilient Oracle configuration, and one risk fund. That layout is the contract surface an integrator reasons about. Fifteen inherited audits across six firms cover the codebase, and the parameter bounds (95% max collateral factor, 5-90% close-factor window, 5% seize share, 10% liquidation incentive) are enforced at the source level.

Read the full parameter documentation at docs.rheofi.com, open a pool on testnet at app.rheofi.com, and see how the Jump Rate Model interacts with each pool's rate curve in the companion post on RheoFi's Jump Rate Model.