Rebase Epoch

Many rebasing tokens offer a wrapped, balance-stable version (e.g., AMPL's ampl_geyser, Olympus's gOHM). These tokens do not change in quantity each epoch. Instead, the wrapper's value per token increases during positive rebases. This simplifies integration with DeFi protocols like DEXs and lending markets that are not built to handle balance changes.

• Key Insight: The rebase epoch's effect is transformed from quantity change to price-per-share appreciation.
• Example: Holding 1 gOHM is equivalent to a dynamically increasing amount of staked OHM (sOHM).

A rebase epoch is the predetermined period—often measured in blocks, hours, or days—after which a rebasing protocol's smart contract executes a supply adjustment. Its primary purpose is to create a predictable schedule for elastic supply changes, allowing the token's price to algorithmically track a target value (like $1). This periodicity prevents constant, gas-intensive recalculations and provides market stability between adjustments.

At the end of each epoch, a rebase function is triggered. This on-chain calculation:

• Compares the current market price to the target price.
• Calculates a rebase ratio (positive or negative).
• Applies this ratio to every holder's wallet balance, proportionally increasing or decreasing their token quantity.
• Updates the total supply on-chain. The function's logic is immutable and trustless, executed automatically by the protocol's smart contract.

Epoch length is a critical protocol parameter chosen for balance between responsiveness and stability.

• 8-hour epochs: Used by Ampleforth (AMPL) to allow significant market movement between rebases.
• 24-hour epochs: Common in many algorithmic stablecoins for daily recalibration.
• Variable/Block-based: Some protocols rebase every N blocks, tying the schedule directly to blockchain finality. The choice impacts volatility absorption and gas cost frequency for users.

During an epoch, a holder's token balance appears static in their wallet. The rebase is a state change applied globally at the contract level. After a rebase, the wallet UI updates to reflect the new balance. Importantly, the holder's percentage ownership of the total supply remains constant. Some wallets and DeFi interfaces require special integration to display these dynamic balances correctly, which can be a UX challenge.

Rebasing tokens present unique challenges for DeFi protocols and oracles:

• Constant Balance: Lending platforms must track a user's collateral value as the underlying token quantity changes.
• Oracle Design: Price feeds must account for the rebasing mechanism to avoid reporting misleading "price stability" while supply changes.
• Snapshot Timing: Protocols taking snapshots for governance or rewards must be epoch-aware. Failure to handle rebases can lead to accounting errors or exploits.

Rebase lag is a damping mechanism sometimes used alongside epochs to smooth supply adjustments. Instead of applying 100% of the calculated rebase ratio in one epoch, the protocol applies a fraction (e.g., 10%). The remaining adjustment is carried over to future epochs. This reduces supply shock and market volatility but extends the time required to reach the target price peg. It's a key stability parameter in protocol design.

A rebase epoch is the scheduled period (e.g., every 8 hours, daily) during which a protocol's smart contract executes a supply rebase. This is not a transaction but a state update that proportionally adjusts all token balances to maintain a price peg or target metric. The epoch length is a fundamental protocol parameter that balances responsiveness to market conditions with user predictability and gas cost efficiency.

The epoch boundary is a focal point for potential economic attacks. Attackers may attempt to manipulate the oracle price feed just before a rebase to trigger an incorrect supply adjustment (positive or negative). A secure design requires time-weighted average prices (TWAPs) over the epoch to mitigate short-term manipulation. Furthermore, the contract must be resilient to reentrancy and ensure atomic execution of the rebase logic to prevent inconsistent states.

For protocols like Olympus DAO (OHM), the rebase epoch is synonymous with the staking reward distribution cycle. Staked tokens (sOHM, gOHM) receive newly minted tokens as rebase rewards at each epoch. This creates a predictable cadence for yield accrual, but also concentrates sell pressure events if many users claim or unstake rewards simultaneously after a rebase.

A fixed epoch provides users with a clear schedule for balance updates and APY compounding. However, it introduces latency; a user buying tokens mid-epoch will not see a rebase adjustment until the next cycle. Protocols must communicate epoch timing clearly, as unexpected negative rebases (contractions) can cause confusion if a user's token balance decreases between checks.

The epoch structure creates periodic games. Rational actors may time their trades to enter just after a positive rebase (buying a larger share of the next epoch's rewards) or exit just before a negative rebase. This can lead to cyclical volume and price patterns. Long, infrequent epochs reduce gaming opportunities but make the peg less responsive.

In code, the epoch is tracked via a block number or timestamp stored in the contract state. A typical function like rebase() is permissioned (often callable by a keeper or decentralized oracle) and checks block.timestamp >= lastRebaseTime + epochLength. It then updates the _totalSupply and the rebaseIndex, a multiplier applied to all balances. Failed rebases due to network congestion are a key operational risk.

Elastic supply refers to a token design where the total circulating supply is not fixed but can change dynamically based on predefined rules, often in response to market price. This is the foundational mechanism behind rebasing tokens. Characteristics include:

• Non-Dilutive: Changes are applied proportionally across all holders.
• Algorithmic: Supply adjustments are triggered by code, not a central authority.
• Use Cases: Primarily for creating price-stable assets without collateral.

These terms describe the direction of the supply adjustment during a rebase epoch.

• Positive Rebase: Occurs when the market price is above the target peg. The protocol increases the token supply to apply sell pressure and lower the price.
• Negative Rebase: Occurs when the market price is below the target peg. The protocol decreases the token supply to create scarcity and raise the price.
• Neutral Rebase: No supply change occurs if the price is within a defined stability band.

The stability threshold or deviation threshold is the predefined price band around the target peg that determines if a rebase is triggered. It prevents excessive volatility from constant, minor rebases.

• Function: If the oracle price deviates from the peg by more than, for example, ±5%, a rebase is initiated.
• Purpose: Introduces hysteresis to the system, allowing for natural market fluctuations without protocol intervention.
• Parameter: A critical governance parameter that affects the frequency and magnitude of rebases.