Rebasing Token Exploit

Rebasing tokens (e.g., Ampleforth) automatically adjust the token balance in every holder's wallet at set intervals to target a specific price. This is done by changing the total supply, not the price per token. Your wallet balance increases or decreases, but your percentage ownership of the total supply remains constant. This creates a discrepancy between a token's raw balanceOf() and its effective value.

The exploit requires a vulnerable third-party contract that interacts with the rebasing token but does not update its internal accounting after a rebase. Common targets include:

• Lending protocols using the token as collateral.
• Automated Market Makers (AMMs) with liquidity pools.
• Yield farming vaults or staking contracts. These contracts often store a stale balance or exchange rate, creating an arbitrage opportunity.

The attacker exploits the difference between the actual token balance and the recorded balance in the vulnerable contract. After a positive rebase increases balances, the vulnerable contract may still honor withdrawals based on the pre-rebase, lower balance recorded in its state. The attacker can then withdraw more tokens than the contract believes they have, or use overvalued collateral to borrow other assets.

A classic scenario:

1. User deposits 100 rebasing tokens as collateral into a lending protocol.
2. A positive rebase occurs, increasing the user's actual balance to 110 tokens.
3. The lending protocol's internal ledger still shows 100 tokens.
4. The protocol's getCollateralValue() function uses the stale 100-token balance.
5. The attacker borrows other assets against this undervalued collateral.
6. The attacker repays the loan and withdraws the 110 tokens, profiting from the 10 'invisible' tokens.

Secure integration requires moving away from direct balance tracking. Standard mitigations include:

• Share-based accounting: Instead of tracking token amounts, contracts issue shares representing a claim on the pool's total tokens. Balances are calculated as (userShares / totalShares) * poolTokenBalance.
• Rebase-aware oracles: Using price oracles that account for the rebasing mechanism to value collateral correctly.
• Explicit snapshots: Recording balances at the block level before and after interactions.

This is a related exploit targeting rebasing tokens in liquidity pools. An attacker donates a large amount of tokens to the pool, artificially inflating the balanceOf(pool) without a corresponding increase in the other reserve asset. This drastically skews the pool's price, allowing the attacker to exploit other users' transactions or drain value via manipulated swap rates. It highlights the danger of AMM math with supply-changing assets.

In December 2021, Visor Finance's Hypervisor liquidity management contracts were exploited for ~$8.8 million. The attack vector was a misalignment between token accounting and rebasing logic. The exploiter:

• Deposited Stake DAO's sdETH (a rebasing staked Ether derivative) into a Visor vault.
• The vault's internal accounting did not immediately reflect the sdETH rebasing rewards, creating a lag between the actual and recorded balance.
• The attacker repeatedly deposited and withdrew, claiming the "unaccounted for" rebasing rewards each cycle, effectively draining the underlying liquidity pool.

The fundamental flaw in most rebasing exploits is the discrepancy between an account's balanceOf and its proportional share of the totalSupply. In standard ERC-20 tokens, these are directly correlated. In rebasing tokens, a user's balance changes automatically, but many DeFi protocols cache or calculate value based on a static snapshot. Exploiters manipulate this by:

• Triggering a rebase after a protocol has recorded a balance but before it settles a transaction.
• Exploiting rounding errors or fee-on-transfer mechanics in pools not designed for elastic supply.
• Using donations to artificially inflate the total supply and skew share calculations.

In April 2022, Fei Protocol's Tribe (TRIBE) token, which employed a reward distribution mechanism similar to rebasing, was involved in an exploit on Rari Capital's Fuse pools. While not a classic rebase, it shared the critical flaw: balance changes external to transfers. An attacker manipulated a Fuse pool's internal accounting by:

• Borrowing assets against TRIBE collateral.
• Claiming TRIBE staking rewards, which increased the collateral balance outside the lending protocol's ledger.
• Using the unaccounted increase in collateral value to borrow more assets, ultimately draining the pool of ~$80M. This highlights the risk of any token with non-transfer balance updates.

Protocols integrating rebasing or similar tokens must implement specific safeguards:

• Use the balanceOfUnderlying pattern: Query the rebasing contract for the real-time, post-rebase balance at every critical state change (e.g., before a withdrawal or liquidation).
• Employ snapshotting mechanisms: Record a user's share of the totalSupply at deposit, rather than a static token amount.
• Isolate in separate adapters: Treat rebasing tokens as a distinct asset class with custom logic, preventing them from interacting with standard AMM math.
• Conduct rigorous integration audits: Specifically test for supply change scenarios, donation attacks, and rounding issues.

Understanding the taxonomy is key to identifying risk:

• Rebasing Tokens (e.g., Ampleforth, OHM): Adjust every holder's balance proportionally based on a target price or metric. The totalSupply changes.
• Elastic Supply Tokens (e.g., Empty Set Dollar): May use seigniorage or bonding curves to adjust supply, often burning or minting to/from a treasury rather than all wallets.
• Staking Derivative Tokens (e.g., stETH, sdETH): Accrue rewards via a growing balance, mimicking a rebase but often through a different mechanism (share-based system). All three can cause the same accounting mismatch if a protocol assumes a user's token balance only changes via direct transfers.

The fundamental flaw exploited is the balance accounting mismatch between the rebasing token contract and an external protocol. When a rebasing token's supply changes (e.g., AMPL, OHM), the balances in user wallets adjust automatically. However, many DeFi protocols cache or store a user's balance at deposit time. An attacker can:

• Deposit tokens before a positive rebase (inflation).
• Withdraw after the rebase, claiming the newly minted tokens from the protocol's reserves.
• Repeat to drain the contract's underlying assets, as the protocol's internal accounting does not reflect the updated, higher balances.

A common method is the donation attack. The attacker donates a large amount of rebasing tokens to the vulnerable contract, artificially inflating the total supply recorded by the protocol. This drastically reduces the share value for all other depositors. The attacker then withdraws, receiving a disproportionately large share of the underlying collateral because the protocol calculates withdrawals based on the manipulated share price. This was famously demonstrated in the 2021 Warren Buffet (WARREN) token exploit on the SushiSwap BentoBox.

Standard ERC-20 integration patterns fail with rebasing tokens. Key risks for developers include:

• Using balanceOf for accounting: Storing a user's balanceOf at deposit is unsafe, as it changes post-rebase.
• Incorrect share calculations: Protocols must track internal shares that are independent of the rebasing balance.
• Oracle manipulation: Price oracles that use the token's total supply can be gamed during a rebase event.
• Lack of balanceOf hooks: Unlike ERC-777, standard ERC-20 tokens do not notify contracts of balance changes, leaving them "out of sync."

Secure integration requires specific design patterns:

• Use internal shares: Record user deposits as a share of the contract's total holdings, not a token amount. Update shares only on user actions (deposit/withdraw).
• Checkpointed balances: Implement a system that snapshots balances at each user transaction, ignoring rebases between interactions.
• Whitelist known tokens: Protocols can explicitly support only well-understood rebasing tokens with audited adapters.
• Isolated collateral types: In lending markets, keep rebasing tokens in separate, isolated pools to prevent contamination of other assets.
• Adopt ERC-777 or similar: Use token standards with transaction hooks for balance change notifications.

In October 2021, an attacker exploited the BentoBox vault's integration with the rebasing WARREN token.

• The attacker donated a massive amount of WARREN to BentoBox, crashing the internal share price.
• They then withdrew their original deposit, but due to the manipulated math, received nearly all of the vault's WETH collateral.
• Result: The attacker netted ~$10M in WETH for a minimal cost, draining the vault. This incident became the canonical case study for rebasing token vulnerabilities in liquidity vaults.

Security reviews for protocols that may handle rebasing tokens must include:

• Balance invariance testing: Verify that a rebase event cannot change the protocol's total underlying asset value.
• Donation attack simulations: Stress-test the contract with extreme token donations and rebases.
• Integration code review: Scrutinize any use of balanceOf or totalSupply for accounting logic.
• Fork testing: Test integrations on a forked mainnet during actual historical rebase events of tokens like AMPL or OHM to observe real-world behavior.

A rebasing mechanism is a smart contract function that automatically adjusts the token balances of all holders to maintain a target price peg, typically to a stablecoin. This is done by proportionally increasing or decreasing the supply in each wallet, not the token's price.

• Key Feature: The total value of a user's holdings remains the same post-rebase, but the number of tokens and the total supply change.
• Example: If the target price is $1 and the market price is $2, a positive rebase mints new tokens to all holders, increasing supply to push the price back down.

Price elasticity refers to a token's design where its supply expands or contracts in response to market price deviations from a target. This is the core economic model behind rebasing tokens and algorithmic stablecoins.

• Elastic Supply: The token's circulating supply is variable and non-fixed.
• Attack Surface: Exploits often manipulate the rebase calculation by creating artificial price deviations on decentralized exchanges (DEXs) before or after the rebase function is called.

Oracle manipulation is a common attack vector where an exploiter artificially skews the price feed a rebasing contract uses to determine if a supply adjustment is needed. By manipulating the oracle price, the attacker can trigger an incorrect rebase.

• Method: Often involves flash loans to create massive, temporary price imbalances on a liquidity pool that the oracle queries.
• Result: The rebase mints or burns tokens based on false data, allowing the attacker to profit from the resulting arbitrage or imbalance.

An Automated Market Maker (AMM) is a decentralized exchange protocol that uses liquidity pools and a constant product formula (e.g., x * y = k) to price assets. Rebasing token exploits frequently target AMM pools.

• Liquidity Pool Imbalance: Attackers exploit the time delay between a rebase event and the pool's internal accounting update.
• Example: If a rebase increases token balances but the pool's reserves aren't instantly synced, an arbitrage opportunity is created that can be drained.

A flash loan attack involves borrowing a large amount of assets with no collateral, executing a series of complex transactions within a single block, and repaying the loan—all contingent on the profitability of the final arbitrage. This is a primary tool for rebasing exploits.

• Role in Rebasing Exploits: Provides the capital needed to manipulate oracle prices or create massive swaps in AMM pools to trigger advantageous rebases.
• Key Characteristic: The loan must be borrowed and repaid in the same blockchain transaction, or the entire operation reverts.

An algorithmic stablecoin is a type of cryptocurrency that uses algorithms and smart contracts (like rebasing) to control its supply and maintain a price peg, without being backed by off-chain reserves. Rebasing tokens are a subset of this category.

• Distinction from Collateralized Stablecoins: Relies on code and market incentives rather than held assets like USD or gold.
• Historical Context: Major rebasing token exploits (e.g., involving tokens like TITAN, EMPIRE) have often occurred in algorithmic stablecoin projects, highlighting the risks of purely algorithmic peg mechanisms.