How Rebase Tokens Behave Inside Liquidity Pools

Detailed Instructions

A rebase event is triggered by the token's smart contract, typically on a scheduled basis or when a specific condition is met. This is an on-chain transaction that calls the rebase() function. For a liquidity pool, the critical detail is that this transaction originates from the token contract itself, not from a user interacting with the pool.

• Sub-step 1: Monitor the token contract. Watch for the Transfer(address(0), address(this), amount) event emitted to the pool's address, signaling a mint of new tokens.
• Sub-step 2: Verify the caller. Confirm the transaction's msg.sender is the rebase token contract (e.g., 0x...).
• Sub-step 3: Check the timestamp. Rebase events often occur at precise intervals (e.g., every 8 hours).

solidityCopy
// Example event log from Ampleforth-style rebase
emit Transfer(address(0), poolAddress, positiveRebaseAmount);

Tip: The pool contract's balance of the rebase token will increase without a corresponding change in the other reserve, breaking the constant product k.

Detailed Instructions

A standard AMM pool like Uniswap V2 maintains the invariant reserveA * reserveB = k. A positive rebase mints new tokens directly to the pool's contract, increasing one reserve (reserveRebaseToken) without any change to the paired reserve (reserveStable). This causes the product k to increase, as newReserveRebase * reserveStable > oldK.

• Sub-step 1: Calculate pre-rebase k. Record reserveRebase and reserveStable from the pool's getReserves() function before the event.
• Sub-step 2: Observe the post-rebase balance. Call balanceOf(poolAddress) on the rebase token contract to see the new, higher balance.
• Sub-step 3: Compute the new invariant. Multiply the new rebase token balance by the stable token reserve. The result is a larger k'.

solidityCopy
// The pool's internal accounting is now imbalanced
uint256 newRebaseBalance = IERC20(rebaseToken).balanceOf(address(this));
uint256 newK = newRebaseBalance * reserveStable; // This is now > old K

Tip: This imbalance creates an arbitrage opportunity, as the pool's quoted price for the rebase token is now artificially low.

Detailed Instructions

Arbitrage bots monitor for rebase events and execute trades to profit from the price discrepancy, which simultaneously restores the pool's k invariant to its original value. They will swap stable tokens for the now-undervalued rebase tokens until the price reflects the external market rate.

• Sub-step 1: Identify the opportunity. Bots detect the increased pool balance and calculate the implied price deviation, often using a formula like (reserveStable / newRebaseBalance).
• Sub-step 2: Execute the swap. The arbitrageur calls swap(amountStableIn, 0, arbitrageurAddress) on the pool, receiving rebase tokens.
• Sub-step 3: Capture profit. The arbitrageur sells the acquired rebase tokens on a centralized exchange or another pool at the higher market price.

solidityCopy
// Simplified arbitrage logic
(uint112 reserveRebase, uint112 reserveStable, ) = pool.getReserves();
uint256 priceInPool = (reserveStable * 1e18) / reserveRebase;
if (priceInPool < externalMarketPrice) {
    // Execute swap: stable in, rebase out
    pool.swap(0, amountRebaseOut, arbitrageur, "");
}

Tip: This process transfers the rebase's supply adjustment from the pool to the wallets of arbitrageurs and swappers.

Detailed Instructions

Liquidity providers do not directly receive the rebased tokens. Their share of the pool is represented by LP tokens, which entitle them to a proportional claim on both reserves. After the arbitrage rebalancing, the composition of those reserves changes, affecting the value of each LP share.

• Sub-step 1: Understand constant share. The total supply of LP tokens remains unchanged. An LP's percentage ownership of the pool is constant.
• Sub-step 2: Analyze reserve transformation. Post-arbitrage, the pool holds more stable tokens and fewer rebase tokens than before the rebase, but the product k is restored.
• Sub-step 3: Calculate new LP value. Value = (shareOfPool * reserveStableAfter) + (shareOfPool * reserveRebaseAfter * marketPrice).

solidityCopy
// Calculating an LP's claim
function getLPValue(address lp, address pool) public view returns (uint256) {
    uint256 lpBalance = IERC20(pool).balanceOf(lp);
    uint256 totalSupply = IERC20(pool).totalSupply();
    (uint112 reserveRebase, uint112 reserveStable, ) = IPool(pool).getReserves();
    uint256 share = (lpBalance * 1e18) / totalSupply;
    uint256 claimRebase = (reserveRebase * share) / 1e18;
    uint256 claimStable = (reserveStable * share) / 1e18;
    // ... value using external price oracle
}

Tip: The LP's position becomes more heavily weighted toward the stable asset, which can be seen as a form of automatic, market-driven fee collection.

Detailed Instructions

Providing liquidity for a rebase token against a stablecoin creates a distinct impermanent loss (IL) scenario. IL is the difference between holding tokens in the pool versus holding them in a wallet. The rebase mechanism adds a layer: wallet holders see their token count change, while LP holders see their pool share's composition change.

• Sub-step 1: Define the baseline. Compare two strategies: HOLDING rebase tokens + stablecoins vs. providing LIQUIDITY with the same initial amounts.
• Sub-step 2: Simulate a positive rebase. After a rebase, the HODLer's rebase token balance increases. The LP's pool reserves are rebalanced via arbitrage, increasing the stablecoin portion.
• Sub-step 3: Calculate relative performance. Impermanent Loss = (Value of LP Position - Value of Hold Position) / Value of Hold Position. For rebase tokens, this calculation must account for the changing supply in the hold position.

javascriptCopy
// Simplified IL comparison for a +10% rebase
let initialRebase = 1000;
let initialStable = 1000;
let price = 1.0;

// HOLD Strategy after 10% rebase
let holdValue = (initialRebase * 1.10 * price) + initialStable; // 2100

// LP Strategy: Assume perfect arbitrage restoring price
// Reserves rebalance. Simplified result:
let lpValue = 2 * Math.sqrt( (initialRebase * price) * initialStable ); // ~2000
let impermanentLoss = (lpValue - holdValue) / holdValue; // ~ -4.76%

Tip: Frequent rebases can lead to more frequent arbitrage and compounding IL effects, making historical data analysis crucial for LPs.

Detailed Instructions

Liquidity pools for standard tokens use the constant product formula, x * y = k, where x and y are the reserves of two assets. For a rebase token like OHM paired with a stablecoin, this formula still governs the pool's external price discovery. The key is that the pool contract's internal token balances are what matter for the formula, not the user's wallet balance. The invariant k is recalculated on every swap, but for calculating your share, you treat the current reserves as fixed.

• Sub-step 1: Identify the two reserve amounts in the pool contract (e.g., reserveOHM, reserveDAI).
• Sub-step 2: Confirm the pool uses a constant product AMM (e.g., Uniswap V2 style).
• Sub-step 3: Note that k = reserveOHM * reserveDAI.

solidityCopy
// Reading reserves from a UniswapV2Pair contract
(uint112 reserve0, uint112 reserve1, ) = pair.getReserves();
// Determine which reserve corresponds to your rebase token

Tip: The pool's token balances are unaffected by rebases occurring externally; only swaps and liquidity events change them.

Detailed Instructions

Your pool share is the fraction of the total liquidity provider (LP) tokens you own. First, query the total supply of LP tokens minted by the pool contract. Then, divide your LP token balance by this total supply. This percentage represents your claim on the pool's entire reserve of both assets. For example, if the pool has a totalSupply of 100,000 LP tokens and you hold 250, you own 0.25% of the pool. This share is critical because the underlying token quantities in the pool can change due to trading, but your proportional ownership remains constant until you add or remove liquidity.

• Sub-step 1: Call the totalSupply() function on the LP token contract.
• Sub-step 2: Call balanceOf(your_address) on the same LP token contract.
• Sub-step 3: Calculate: your_share = your_lp_balance / total_lp_supply.

Tip: This share is a static number until your LP position changes; it is not automatically compounded by rebases.

Detailed Instructions

Multiply your pool share percentage by the total reserves of each token in the pool. This gives the quantity of each token your LP position represents. For a pool with reserveA and reserveB, your claim is your_A = your_share * reserveA and your_B = your_share * reserveB. In a rebase token pair, note that reserveA (the rebase token) is the balance held inside the pool contract, which does not rebase. This is a crucial distinction: your wallet's OHM may increase due to a rebase, but the OHM locked in the pool does not, preserving the k invariant. Your claim is on this static pool balance.

• Sub-step 1: Fetch the latest pool reserves (e.g., via getReserves).
• Sub-step 2: Apply your share: yourRebaseToken = reserveRebaseToken * (yourLP / totalLP).
• Sub-step 3: Calculate your paired asset amount similarly.

javascriptCopy
// Example calculation in JS
const yourShare = lpBalance / totalSupply;
const yourRebaseTokens = reserveRebase * yourShare;
const yourStablecoins = reserveStable * yourShare;

Tip: These calculated amounts are what you would receive if you burned your LP tokens to withdraw liquidity at this exact moment.

Detailed Instructions

To find the total USD value of your LP position, price both underlying token amounts. For the stablecoin pair (e.g., DAI), the value is 1:1. For the rebase token, use the current market price from the pool or an oracle. The pool's internal price is reserveStable / reserveRebase. Multiply your rebase token amount by this price and add the value of your stablecoin claim. The formula is: totalValue = (yourRebaseToken * price) + yourStablecoin. This reveals your position's impermanent loss relative to holding the tokens separately, as the pool price diverges from the external market. For rebase tokens, this calculation is independent of the token's rebasing mechanics on-chain.

• Sub-step 1: Determine price: poolPrice = reserveStable / reserveRebase.
• Sub-step 2: Calculate rebase token value: valueRebase = yourRebaseToken * poolPrice.
• Sub-step 3: Sum values: totalValueUSD = valueRebase + yourStablecoin.

Tip: Monitor this value over time to assess performance, remembering that fee income from trades is accrued separately as increased pool share.

Detailed Instructions

Your LP position earns a pro-rata share of trading fees, which are added to the pool's reserves, increasing the value of k. This gradually increases your underlying token amounts without you receiving more LP tokens. To estimate accrued fees, track the growth of k or your share value over time. Separately, understand that a rebase on the external token (e.g., OHM supply adjustment) does not affect the pool's internal reserves. However, it affects the token's market price, which impacts the pool's external exchange rate and can lead to arbitrage. This arbitrage changes the pool's reserves (x and y), which subsequently changes the value of your share. Your LP token balance is a claim on the pool's state post-arbitrage.

• Sub-step 1: Periodically snapshot your calculated position value to measure fee accrual.
• Sub-step 2: Recognize that a positive rebase typically causes selling pressure as arbitrageurs restore the pool price.
• Sub-step 3: Your impermanent loss is measured against the hypothetical holding of the external, rebasing tokens.

Tip: Fee accrual slightly offsets impermanent loss. The rebasing mechanism adds a layer of price volatility that accelerates reserve changes through arbitrage.