Smardex fictive reserves change price impact as pool conditions evolve

Real token balances and fictive pricing balances

Each pool maintains separate fictive balances for its two tokens and pays swap output with actual tokens. The virtual amounts shape the pricing curve; they don't add tokens to the contract or create another withdrawable balance.

Reserve accounting also separates fees owed elsewhere. In the Ethereum v2 pair, getReserves returns token balances after subtracting pending fee-recipient amounts. A raw token balance can therefore differ from the reserve figure used for pricing. That difference comes from fee accounting, independently of the fictive-reserve adjustment.

The same marginal price with different depth

Two attributes of fictive reserves affect execution: their ratio gives the marginal exchange price before fees, while their size controls the curve's response to a finite trade. Marginal price describes the rate before the trade itself moves the curve.

The reserve ratio

Dividing fictive output reserves by fictive input reserves expresses output-token units per input-token unit, after decimal conversion. Larger swaps receive an average rate along the curve as they move the price. The actual reserve ratio can differ from this marginal price after trading shifts inventory.

Initial scaling and curve size

The first liquidity mint initializes each fictive reserve at half its corresponding token balance, with integer rounding. That shared scaling preserves the starting reserve ratio apart from rounding. It also makes a given input larger relative to the balances that the pricing calculation uses.

Within a single pricing segment, ignoring fees and integer rounding, output follows q * F_out / (F_in + q) . Here q is input quantity and F_in and F_out are the segment's fictive balances in matching token units. At the same starting ratio, smaller balances mean greater price movement for a given input. Later recalculations change those balances, so the initial half-reserve setting isn't a permanent pricing rule.

Trade direction and pool inventory

Recalculation responds to the relationship between real inventory and the price implied by fictive balances. The algorithm values the real tokens at that price, then changes effective depth according to the swap's direction. Its formulas can therefore give different curve depths to opposite directions in an imbalanced pool. Deeper effective liquidity lets the pool release more of the token that it seeks to sell for a given price movement. Shallower liquidity makes that movement steeper. This design aims to retain more of a rising token early in a price move and sell it later at higher prices.

The moving-average boundary

The Ethereum v1 and v2 pricing libraries cap elapsed time at 300 seconds when updating the price average. The update keeps the previous average when the current timestamp matches its last-update timestamp. At a later timestamp, the formula blends the previous average with the pre-swap fictive-reserve price, using the capped interval.

The average supplies a boundary for reserve recalculation. Keeping it fixed within a timestamp limits the advantage of resetting the pricing curve during an immediate reverse trade.

A swap that crosses the average

The swap calculation can apply different fictive balances to successive portions of one trade. Crossing the moving-average price determines whether the calculation needs that internal split. Trade direction matters because an input can move the price toward the boundary or away from it.

Before the boundary

A trade starting away from the average uses the existing curve while moving toward it without reaching it. A trade moving away also stays on that curve. When the starting price approximately equals the average, reserve recomputation can occur before the trade proceeds.

Beyond the boundary

A sufficiently large trade toward the average first reaches that boundary on the existing curve, subject to integer rounding. The calculation then recomputes fictive reserves from the resulting balances and prices the remaining amount with those revised reserves. The portions contribute to one overall input or output amount.

Smardex performs this split inside the swap calculation. It doesn't require two separately submitted user trades. Applying one constant-product curve to the whole amount can miss the boundary and return a different answer.

Fees and trade-size quotes

Swap fees reduce the input that enters the pricing formula. They also affect the updated reserves, because the liquidity provider (LP) fee contributes to pool value. Reproducing the swap's amounts requires an estimate that includes the charged fee components.

In the Ethereum v2 design, the factory owner can change pair fees within the contract's limits. That makes the fee setting a live input. A fee percentage copied from another pool or implementation can give the wrong output even when fictive balances match.

Token approval for a first swap gives a contract spending permission; it doesn't freeze these pricing inputs.

Liquidity additions and withdrawals

Liquidity operations scale fictive reserves with changes in LP-token supply. An additional deposit into an existing pool raises the virtual balances proportionally to the minted liquidity; a withdrawal reduces them proportionally to the burned liquidity. These operations change curve depth without requiring a price-changing swap. Deposit quantities follow the real reserve proportions. Since those proportions can differ from the fictive-reserve price, the deposited tokens needn't have equal market values. The swap-pricing ratio alone therefore doesn't determine the quantities required for a liquidity contribution.

After fee accounting, a successful LP-token burn distributes actual token balances proportionally to the burned share of supply.

View full-size image

Impermanent loss and the holding benchmark

Impermanent loss compares a liquidity position's value with the value of holding its originally deposited tokens. It can exist even when both values rise. Impermanent gain describes outperformance against that holding benchmark.

Fictive-reserve pricing changes the inventory path that produces that comparison. The sequence of swaps and relative prices therefore matters, alongside the fees that accrue. A reserve snapshot can't establish an LP position's return relative to holding. That requires matching the starting assets and valuation period, then valuing the final claim on the same basis.

Pair pricing and routed swaps

Fictive reserves describe the Smardex pool leg of a route. The Universal Router can combine Smardex swaps, other supported swap commands and token wrapping within one transaction. A whole-route quote therefore reflects additional mechanisms when it includes other legs. A difference between routed quotes doesn't isolate the effect of fictive reserves unless the compared pool path, input amount and fee treatment match.