Rebasing Collateral

The total supply of a rebasing token is not fixed. It automatically expands or contracts based on a rebase function, which is triggered by an oracle price feed. This elasticity is the core mechanism for maintaining a peg to a target value, such as $1 USD. For example, if the market price is $0.98, a positive rebase mints new tokens to holders, increasing supply to push the price back toward the peg.

A user's wallet balance of a rebasing token changes automatically with each rebase event, without requiring any transaction from the user. This is a state change at the contract level, not a transfer. The user's proportional share of the total supply remains constant, but the nominal token amount updates. This is distinct from rebasing stables like Ampleforth, where the adjustment is applied directly to all holder balances.

Rebasing is a non-dilutive price stability mechanism. Unlike algorithmic stablecoins that use seigniorage shares or secondary tokens, rebasing adjusts the unit count for all holders simultaneously. The target is maintained through supply elasticity rather than collateral backing or direct arbitrage. This makes it a purely algorithmic approach to achieving a soft peg, where the price oscillates around the target based on the rebase parameters and market forces.

Integrating rebasing tokens into lending protocols and automated market makers (AMMs) requires special handling. Key challenges include:

• Accounting Complexity: Protocols must track the rebase-adjusted balance rather than the raw token amount.
• Oracle Reliance: Accurate, manipulation-resistant price feeds are critical for triggering rebases.
• Slippage in AMMs: Constant supply changes can lead to unexpected slippage if pools are not designed for elastic tokens. Specialized rebasing-aware vaults are often used as wrappers.

A negative rebase (or contraction) occurs when the market price is above the target peg, causing the protocol to burn tokens from all holders' wallets. This reduces the nominal balance of every holder, representing a deflationary shock. For users, this means the number of tokens decreases, though the goal is for the USD value of their holdings to remain stable. This is a fundamental design risk distinct from impermanent loss or smart contract bugs.

A primary application is creating a yield-bearing stable asset. A protocol accepts stablecoin deposits (e.g., USDC), stakes them in a yield-generating strategy (e.g, lending on Aave), and issues a rebasing token representing the deposit. The token's target price remains $1, but its supply increases via rebases to distribute the accrued yield to all holders. This creates a native yield asset without requiring users to manually claim rewards, exemplified by tokens like Ethena's USDe.

Using rebasing tokens as collateral requires specific risk management frameworks:

• Specialized Oracles: Protocols need oracles that report the rebase-adjusted exchange rate, not just the spot price, to accurately value collateral.
• Dynamic LTV Ratios: Loan-to-value ratios may be set conservatively to account for the complexity and potential volatility of the rebasing mechanism.
• Liquidation Logic: Liquidations must account for the fact that collateral balances are not static, requiring precise calculations of user health factors post-rebase.

Protocols typically choose one of two integration paths for rebasing collateral:

• Wrapped Version (e.g., wsOHM): The rebasing token is wrapped into a static-balance version. This simplifies accounting but adds an extra layer of complexity for users and may involve a wrapping fee.
• Native Integration (e.g., AMPL): The protocol's smart contracts are modified to natively track and apply rebases to user balances. This is more transparent for users but requires more complex protocol engineering and auditing. The choice impacts user experience, security, and composability with other DeFi applications.

The use of rebasing and yield-bearing tokens as collateral is driving innovation in DeFi standards. Emerging solutions include:

• ERC-4626 Tokenized Vault Standard: Provides a unified interface for yield-bearing vaults, making integration across protocols simpler and safer.
• Rebase-Agnostic Accounting: New lending primitive designs that separate the unit of account from the rebasing token, focusing solely on the underlying value.
• Cross-Chain Collateral: Rebasing tokens from one chain (e.g., staked SOL) being used as collateral on another, requiring secure cross-chain messaging for rebase updates.

The primary risk is inaccurate valuation of the collateral's rebasing-adjusted supply. Attackers can exploit the time delay between a rebase event and the oracle's price update to manipulate the collateralization ratio. For example, a negative rebase that reduces a user's token balance may not be reflected instantly in the protocol's view, allowing the user to temporarily appear over-collateralized and withdraw excess funds before the system corrects the value.

Standard liquidation triggers based on static collateral amounts fail with rebasing tokens. The system must continuously monitor the adjusted debt-to-collateral ratio post-rebase. Key failure modes include:

• False liquidations: A positive rebase increases a healthy position's collateral, but a lagging engine might misread the initial dip in per-token price.
• Failed liquidations: A negative rebase can instantly push a position underwater, but if the liquidation mechanism cannot keep pace with the rapid devaluation, bad debt accrues.
• Liquidation bots must be specifically designed to account for the token's elastic supply.

Rebasing tokens often break assumptions made by standard ERC-20 interfaces, leading to integration fragility in the broader DeFi stack. Risks include:

• Balance snapshot attacks: Protocols that cache token balances (e.g., in merkle distributors or vesting contracts) can have their state invalidated by a rebase.
• Cross-protocol arbitrage: A position may be safe in the lending protocol but become undercollateralized in a secondary money market or derivative protocol that uses a different oracle or update mechanism, creating systemic risk.
• Front-running rebases: MEV bots can exploit predictable rebase timing to extract value at the expense of other users or the protocol's treasury.

The rebasing mechanism itself can be a vector for attack, especially if governance controls key parameters.

• Rebase parameter manipulation: A malicious or compromised governance could alter the rebase formula, frequency, or magnitude to deliberately create mass undercollateralization or unfair liquidations.
• Reflexive depegging: In a crisis, a wave of liquidations of rebasing collateral can force large sell-offs of the underlying token, causing its market price to drop. This triggers further negative rebases and more liquidations—a death spiral that can drain protocol reserves.
• Stale rate exploitation: Attackers may target protocols using outdated rebasing logic or oracles that do not track the latest contract implementation.

Secure implementation of rebasing collateral requires deliberate design choices:

• Use dedicated price oracles that natively track the rebasing-adjusted total supply and per-share value (e.g., using getSharesByPooledEth for stETH).
• Implement continuous, rebase-aware health checks instead of periodic price updates.
• Employ circuit breakers that pause new borrows or liquidations during extreme market volatility or known rebase windows.
• Design isolation modes where rebasing collateral is in a separate, risk-parameterized market to limit contagion.
• Rigorous, time-weighted testing of all protocol functions against historical rebase data.