Why Lending Protocols Must Re-evaluate Their Reliance on Rebasing Tokens

Rebasing tokens require constant price and supply updates, creating a critical dependency on centralized oracle feeds. This introduces a single point of failure for billions in TVL.

• Attack Vector: Manipulating the rebase delta can create risk-free arbitrage against the protocol.
• Complexity Cost: Oracles must track both price and supply, increasing latency and failure modes compared to standard ERC-20s.

Protocols must choose between the native rebasing token or its wrapped version, fracturing liquidity and user experience. This is a zero-sum design choice.

• Capital Inefficiency: Lending markets for stETH and wstETH operate in silos, reducing overall borrowing depth.
• UX Friction: Users must manually wrap/unwrap, adding steps and exposing them to base layer gas costs and complexity.

During market stress, the rebasing mechanism can accelerate liquidations and trigger death spirals. A falling ETH price compounds with a shrinking collateral balance.

• Compounding Risk: Collateral value declines from both price depreciation and automatic supply reduction.
• Procyclical Liquidations: Creates a vicious cycle where liquidations increase sell pressure, further depressing the underlying asset.

Rebasing tokens force protocols into a dangerous dependency on price oracles, creating a single point of failure. A manipulated oracle can trigger mass liquidations or allow infinite minting.

• Key Risk: Oracle latency or manipulation for a $30B+ asset like stETH is a systemic threat.
• Key Imperative: Design for oracle-minimized or oracle-free valuation using on-chain verifiable state.

Continuous token supply changes break standard ERC-20 assumptions, causing integration failures across DeFi. This imposes a composability tax on the entire ecosystem.

• Key Problem: Wrappers (wstETH) add complexity and fragment liquidity.
• Key Solution: Native integration of yield-bearing positions as non-rebasing ERC-4626 vaults, as seen in MakerDAO's sDAI.

When a user deposits a rebasing token as collateral and borrows against it, the increasing token balance does not automatically increase their borrowing power. This creates phantom equity that is locked and unusable.

• Key Flaw: Capital efficiency loss for borrowers holding long-tail rebasing assets.
• Key Fix: Protocol-native tracking of accrued yield within the position to dynamically adjust credit lines, similar to Compound's cTokens but for collateral.

Isolated markets for yield-bearing collateral, like Morpho Blue, demonstrate the path forward. They allow for custom risk parameters and oracle choices, containing failure domains.

• Key Benefit: A faulty stETH oracle only affects its isolated market, not the entire protocol's $1B+ TVL.
• Key Trend: Lending is moving from monolithic, shared-risk pools to permissionless, asset-specific risk modules.

Rebasing balances change unpredictably, forcing users to constantly claim or compound to avoid dilution. This generates wasted gas and creates MEV opportunities from stale balances.

• Key Cost: Users lose 1-3% APY to gas and slippage from manual management.
• Key Design: Automate yield accrual into the debt/collateral position itself, eliminating user-side actions. Euler's interest-bearing eTokens were an early model.

For a lending protocol, holding rebasing tokens on its balance sheet (e.g., from treasury or bad debt) creates accounting nightmares and unintended liability from perpetual supply inflation.

• Key Hazard: Protocol equity can be silently diluted.
• Key Mandate: Treat rebasing tokens as liabilities, not assets. Use non-rebasing wrappers for treasury management and design settlement mechanisms that avoid protocol-held rebasing exposure.