Rebasing

A rebasing token programmatically adjusts its total supply in response to price movements to target a specific value, typically a stablecoin peg. This is achieved by proportionally increasing or decreasing the balance in every holder's wallet.

• Positive Rebase: If the market price is above the target, the protocol mints and distributes new tokens to all holders, increasing supply and diluting the price back toward the peg.
• Negative Rebase: If the price is below the target, the protocol burns tokens from every holder's balance, reducing supply to create scarcity and increase the price.

Unlike algorithmic stablecoins that target a fiat value (e.g., $1), rebasing tokens often target a unit of account tied to another asset or index. The most common target is the value of one share of the protocol's treasury assets, creating a reflexive or backed asset.

For example, a token might rebase to maintain a 1:1 value with 1 gOHM (governance token) or a basket of assets in a treasury. The goal is price stability relative to the target, not absolute fiat stability.

A defining user experience of rebasing is that the number of tokens in a holder's wallet changes automatically. Your token balance fluctuates with each rebase event, while your share of the total supply remains constant.

• This is different from reflection tokens, which distribute fees but don't change total supply.
• Wallets and exchanges must integrate specific balance snapshot logic to display the correct, post-rebase amount. This can cause confusion if not properly supported.

Rebases occur at predefined intervals or when specific market conditions are met.

• Epoch-Based: Many protocols use a set period (e.g., every 8 hours) to trigger a rebase calculation and execution.
• Deviation Threshold: A rebase may only trigger if the market price deviates from the target by a certain percentage (e.g., > 1%).
• The process is typically on-chain and automated via smart contracts or oracles that feed price data, ensuring decentralization and predictability.

A critical design pattern is the separation of rebasing logic from the staked asset. Often, the protocol has two tokens:

1. A Staked, Rebasing Token (e.g., sTOKEN): This is the token held in the staking contract. Its balance rebases, representing a growing claim on the treasury.
2. A Non-Rebasing Governance Token (e.g., gTOKEN): This token's quantity is static, but its value is backed by the rebasing staked token. It's used for voting and is easier to integrate with DeFi protocols.

This design isolates the complexity of rebasing to the staking contract.

Advanced rebasing protocols use their treasury assets—the Protocol-Controlled Value (PCV)—to defend the price peg through market operations, not just supply changes.

• If the price is below target, the protocol can use PCV to buy back and burn tokens in the open market.
• If the price is above target, it can mint and sell new tokens.
• This creates a hybrid model combining elastic supply with treasury-backed liquidity management, moving beyond pure algorithmic rebasing.

Featured a dual-token, seigniorage-style rebasing system. The algorithmic stablecoin TerraUSD (UST) maintained its $1 peg by minting and burning the governance token Luna (now LUNC).

• Arbitrage Mechanism: Users could always burn $1 worth of Luna to mint 1 UST, and vice versa.
• Supply Adjustment: Luna's supply rebased based on UST demand.
• Collapse Catalyst: The mechanism failed under extreme market stress, leading to a death spiral where Luna supply hyperinflated.

Early algorithmic stablecoin experiments on Ethereum that used epoch-based rebasing and bonding mechanisms. They were community-run, governance-minimized protocols.

• Coupon System: Users could buy discounted "coupons" (debt) when the price was below peg, redeemable for tokens after a rebase above peg.
• DAO-Governed Expansion/Contraction: Supply changes were voted on by token holders in daily epochs.
• Challenges: Both struggled with maintaining peg stability and sustaining the coupon mechanism during extended periods below peg.

Rebasing protocols face unique challenges that inform their design and use cases.

• Peg Stability: Relies on continuous, robust arbitrage incentives and oracle reliability.
• Reflexivity: Price and supply feedback loops can create extreme volatility (hyperinflation or deflation).
• Integration Complexity: Rebasing tokens can break standard DeFi composability, requiring wrapper tokens or modified smart contracts.
• Use Case: Primarily for creating non-collateralized stable assets or governance tokens with elastic monetary policy, rather than general-purpose mediums of exchange.

A rebasing token algorithmically adjusts the balance in every holder's wallet to maintain a target price, typically $1. Instead of the token price changing, the supply expands or contracts. For example, if the market price is $1.10, the protocol mints new tokens to all holders, increasing supply to push the price back to $1. The rebase function is a smart contract call, often occurring at regular epochs (e.g., every 8 hours).

Rebasing tokens introduce unique smart contract risks and break standard DeFi assumptions.

• Integration Risk: Many DeFi protocols (DEXs, lending markets) are not built to handle balance changes between transactions, leading to potential loss of funds or failed transactions.
• Approval Exploits: Malicious contracts can exploit token approvals made before a rebase occurs.
• Oracle Manipulation: The rebase calculation often relies on an external price oracle, creating a central point of failure vulnerable to manipulation.

The economic model of rebasing creates complex user experiences and potential tax liabilities.

• Balance Volatility: A user's token count changes constantly, making portfolio tracking and value calculation non-intuitive.
• Taxable Events: In many jurisdictions (e.g., the U.S.), each rebase that increases a holder's balance may be considered a taxable event, creating an accounting burden as new tokens are 'received'.
• Slippage & Pricing: Trading around rebase epochs can be problematic due to sudden liquidity shifts.

Rebasing is often confused with staking rewards, but they are fundamentally different mechanisms.

• Rebasing: Adjusts the base supply in your wallet. Your share of the total supply remains constant relative to other holders.
• Staking Rewards: Mints new tokens as rewards, which are distributed to stakers, diluting non-stakers. Your share of the total supply increases. Protocols like OlympusDAO popularized the "(3,3)" game theory model, where staking and rebasing were combined to incentivize long-term holding.

Other models achieve price stability without directly rebasing wallet balances.

• Wrapper Tokens (e.g., sOHM): A non-rebasing, yield-bearing vault token that represents a claim on the rebasing base asset. Simplifies DeFi integration.
• Algorithmic Stablecoins (e.g., Fei Protocol): Use Protocol Controlled Value (PCV) and direct incentives (rewards/penalties) to maintain the peg, without altering user balances.
• Seigniorage Shares: A two-token model where one token is stable and a second, volatile token absorbs supply changes.

A rebasing token algorithmically adjusts the token balance in every holder's wallet to maintain a price target, usually $1.00. Instead of the token's price changing, the supply expands or contracts. For example, if the market price is $1.10, the protocol mints and distributes new tokens to all holders, increasing supply to push the price back down. Conversely, if the price is $0.90, tokens are burned from all wallets, reducing supply. This process is often called an elastic supply or seigniorage model.

Rebasing tokens create significant friction for DeFi protocols and user interfaces. Key challenges include:

• Balance Volatility: A user's token count changes constantly, breaking standard wallet displays and confusing users.
• Smart Contract Accounting: Protocols must track rebase-adjusted balances rather than raw token amounts, requiring custom integration logic.
• Oracle Pricing: Price oracles must be configured to understand the rebasing mechanism to report the correct, pegged price instead of a volatile market price. Failure to handle this can lead to incorrect liquidation or borrowing logic.

Providing liquidity with rebasing tokens in an Automated Market Maker (AMM) like Uniswap is complex. The pool's token reserves are constantly altered by rebases, which can distort the constant product formula (x * y = k). This often requires:

• Rebase-aware AMMs: Custom pools that suspend trading during a rebase event to rebalance reserves.
• Liquidity Provider (LP) Token Adjustments: LP token balances or underlying shares must be adjusted to reflect the changing composition of the pool, ensuring fair distribution of the rebase. Without this, LPs can suffer impermanent loss-like effects from the mechanism itself.

Ampleforth is the canonical example of a rebasing token, targeting the 2019 USD value. Its supply adjusts globally once per day (at 2:00 UTC) based on the prior day's price deviation from $1. This daily rebase is applied proportionally to every wallet and contract holding AMPL. The protocol demonstrated that a non-dilutive rebase (where all holders' percentage of the network remains constant) is possible, but it highlighted the severe integration hurdles for exchanges and DeFi, leading to the creation of wrapped, non-rebasing versions like SPOT or ampl.eth.

To simplify integration, many rebasing protocols create a wrapped, non-rebasing version of their token (e.g., Olympus's wsOHM). This wrapper token:

• Stops Rebasing: Holds the underlying rebasing token but maintains a constant quantity, with value accrual reflected in its price.
• Enables Compatibility: Can be seamlessly used in standard DeFi protocols, DEXs, and lending markets.
• Introduces a Layer: Adds complexity and potential centralization risk if the wrapper is controlled by a multisig. Users must decide between the native (rebasing) token for direct protocol benefits and the wrapped version for liquidity and ease of use.

Accurate off-chain and on-chain data for rebasing tokens requires specialized oracle solutions. Standard price feeds will capture the market price, which for a functioning rebasing token should hover near its peg. However, protocols need more:

• Rebase Event Data: Oracles must detect and broadcast when a rebase occurs, its magnitude (positive or negative), and the new total supply.
• Index or Scaling Factor: Many integrations use a rebase index (e.g., the ratio of current supply to original supply). Oracles provide this index so contracts can calculate a user's underlying balance as wrappedBalance * index.
• Failure Modes: If the rebase mechanism breaks and the token depegs, oracles must reflect this true market price to prevent systemic risk in integrated protocols.

The foundational property of a rebasing token. Its total supply expands or contracts algorithmically, typically in response to price deviations from a target peg. This elasticity is distinct from fixed-supply assets like Bitcoin.

• Mechanism: Supply changes are applied proportionally to all holders' wallets.
• Goal: To make each token unit more stable in value, often targeting a specific price (e.g., $1).
• Contrast: Differs from seigniorage models where new supply is minted for specific entities.

The target value a rebasing token aims to maintain, serving as its unit of account. Common pegs include fiat currencies (e.g., $1 for Ampleforth) or a basket of assets.

• Function: The protocol's rebase function triggers when the market price deviates from this peg.
• Example: If a token pegged to $1 trades at $1.20, a positive rebase increases supply to push the price back down.
• Stability: The peg is a target, not a guarantee; it relies on market arbitrage and protocol incentives.

A system used to track a user's proportional ownership of the elastic supply pool without their wallet balance constantly changing. This is a common implementation pattern to improve UX.

• How it works: Users hold static shares or a balance tracked by an index. Their effective token balance = shares * current index.
• Example: OlympusDAO's sOHM (staked OHM) uses a staking index that increases with each rebase, while the wallet balance of sOHM stays constant.
• Benefit: Simplifies integration with DeFi protocols that expect static token balances.

An alternative algorithmic stablecoin model often contrasted with rebasing. New supply is minted as revenue (seigniorage) for the protocol or its holders, rather than being distributed proportionally.

• Key Difference: In seigniorage models (e.g., early Basis Cash), new tokens are sold or distributed to bondholders when price is high, not to all holders.
• Treasury Focus: Often involves a protocol-owned treasury and bonding mechanisms to manage expansion/contraction cycles.
• Risk Profile: Can lead to different incentive structures and potential death spirals compared to proportional rebasing.

Critical parameters governing a rebasing system's operation and security.

• Oracle: The external price feed (e.g., Chainlink) that determines the market price versus the peg. It is a central point of failure and manipulation risk.
• Rebase Lag: A damping coefficient (e.g., 0.9) that applies only a fraction of the calculated necessary supply change. This reduces volatility and front-running incentives by making adjustments gradual.
• Design Impact: These parameters directly affect the system's responsiveness, stability, and attack surface.