is Inverse Finance's flagship lending protocol that offers fixed-rate borrowing. Unlike variable-rate markets, where interest rates fluctuate based on market dynamics, FiRM ensures borrowers secure loans with fixed interest rates of any duration. This certainty attracts a broader range of users, including those who prefer traditional financial products with stable costs. FiRM supports various collateral types, each with specific parameters tailored to its risk profile.
Security is paramount in FiRM, featuring multiple layers of protection for users. These include:
Personal Collateral Escrows
Personal Collateral Escrows (PCEs) ensure that each user’s deposits are completely isolated by user and token type, replacing traditional shared collateral pools. This design eliminates the possibility of large-scale vulnerabilities, as there is no single, centralized pool for attackers to target. Additionally, PCEs allow users to stake their assets and hold sTOKENS (e.g., governance tokens that accrue rewards), granting them full participation rights—voting, reward claiming, and more—while those assets are simultaneously used as collateral. Since deposited collateral cannot be re-lent, potential oracle manipulation exploits that target artificially inflated collateral prices are further contained. PCEs thus combine granular segregation with utility for staked tokens, enhancing both security and user empowerment within FiRM.
Pessimistic Price Oracles
FiRM’s Pessimistic Price Oracles (PPOs) evaluate collateral based on the lower of two figures: the current Chainlink price and a 48-hour low price, adjusted by the collateral factor. For instance, if wETH’s current Chainlink price is $1,500 but its 48-hour low is $1,000, and the collateral factor is 80%, PPO deems wETH’s borrowable value to be $1,250 ($1,000 ÷ 0.80). By basing valuations on multi-day price data rather than momentary spikes, PPOs limit the effectiveness of flash loan–enabled manipulations or rapid pump-and-dump schemes. This conservative approach especially benefits long-term borrowers who seek stability, while still offering flexibility for less volatile assets like stablecoins.
Borrow Limits
Minimum Debt Amount: Each market enforces a minimum debt threshold per user, preventing users from taking out trivial borrow positions that could clutter liquidation mechanisms or otherwise disrupt the protocol. This requirement curtails malicious or “griefing” strategies, as every borrower must maintain a meaningful debt amount that can be more efficiently managed and liquidated if necessary.
Rolling 24-Hour Borrow Limit: Instead of resetting daily limits at a fixed time (e.g., midnight UTC), FiRM employs a continuously replenishing cap over a 24-hour period. This design prevents borrowers from exploiting back-to-back borrows across reset boundaries and ensures fairer access for users who engage with the protocol at different times. Borrow capacity recovers incrementally each second, reducing the potential for exploitative behavior and moderating the pace of new debt accumulation.
Contract Address Whitelist
To mitigate flash loan exploits, FiRM allows only whitelisted contracts to borrow DOLA at the Borrow Controller level, while any contract can still deposit collateral. This mechanism, upgraded to Pectra compliance, ensures full protection against delegated contract calls introduced by EIP-7702. By integrating additional checks—such as tx.origin == msg.sender and verifying msg.sender.code.length == 0—FiRM effectively blocks unauthorized reentrancy and atomic manipulation attempts. This framework preserves a secure borrowing environment by filtering out potentially malicious or unvetted contract interactions.
Staleness Theshold
FiRM safeguards against oracle disruptions and stale price data by enforcing a Staleness Threshold: whenever price feeds fail to update within a governance-defined timeframe, new borrows are temporarily blocked. This measure prevents scenarios where outdated collateral valuations might inadvertently grant borrowers an overly favorable position, thereby mitigating oracle-related exploits. The threshold can be tailored by governance to balance user convenience with the protocol’s overall security needs, ensuring borrowable asset prices remain timely and accurate.
