Fraxfinance uses Fraxswap TWAMM orders to spread token sales over time at changing prices

Even Sales and Changing Pool Prices

Fraxswap combines a constant-product automated market maker (AMM) with long-term orders whose input sells at a scheduled rate. The AMM holds reserves of both tokens and uses their relationship to calculate swap output. Selling into those reserves changes the pool price. Spreading a sale across time gives other trading activity opportunities to alter the reserves between portions of that sale. Arbitrage trades can bring the pool price closer to prices elsewhere, provided profitable opportunities attract execution.

The order controls how much input enters that process over its effective lifetime. It does not control how much output each portion purchases. Changes in liquidity, opposing orders and wider market prices influence the eventual exchange rate. A longer schedule lowers the input sold per unit of time for the same deposit. That can soften immediate price impact, while extending exposure to market movements. More time alone cannot establish which schedule produces the most output.

When Does a Price Floor Rule Out Core TWAMM Orders?

A price floor rules out an unprotected core TWAMM order when every sale must satisfy a minimum exchange rate. Its long-term swap functions take an input amount and interval count, without an order-wide minimum-output parameter. A starting estimate therefore describes an expectation, not an enforceable future fill. Cancelling an active order can stop further selling, but cannot reverse completed sales. A displayed tolerance establishes a price floor only if the relevant execution logic enforces it across the schedule.

Open full-size image

Order Duration and Hourly Expiry

The recorded expiry determines the effective sale period, which can differ from a simple count of requested hours. The constant-product Fraxswap pair uses a 3,600-second order-expiry interval. Its calculation adds one more interval than requested to the boundary at or before order creation. The remaining portion of the current interval therefore contributes to the duration. The selling rate uses the funded input and the actual time remaining until expiry, with fixed-point rounding.

The stored creation and expiry timestamps identify the schedule precisely. An interface label may summarize that schedule more loosely.

Virtual orders represent accumulated trading calculations, without a separate wallet transaction for every tiny sale. During normal operation, the pair updates those calculations before relevant AMM interactions. An inactive pool can consequently have stored accounting behind the elapsed clock. The next qualifying interaction brings execution forward through intervening expiries. A live order’s displayed progress needs to distinguish that stored state from an estimate accounting for elapsed virtual trading.

How Do Cancellation and Withdrawal Change an Order?

Cancellation ends an active sale and returns unsold input together with uncollected proceeds in the buying token; withdrawal collects proceeds without necessarily ending execution. The cancellation calculation requires an order still active in the pair’s virtual-order accounting. Once normal execution reaches expiry, proceeds withdrawal handles the completed order. Amounts collected earlier remain separate from what either operation transfers later.

The order owner can withdraw accrued proceeds without changing an active order’s remaining sale schedule.

The constant-product pair also has a factory-controlled TWAMM pause path. Once activated on a pair, that irreversible pause rejects new long-term orders and skips virtual execution. Both operations require the recorded owner. Proceeds withdrawal reverts if no uncollected proceeds remain; cancellation requires unsold input or uncollected proceeds. An expected end time consequently cannot establish settlement during a pause. The pair’s accounting state determines the available amounts, and an unchanged clock-based estimate can misrepresent them.

The pair marks an order complete after cancellation or an expired-order proceeds withdrawal. That closure flag can describe either a partly executed, cancelled sale or a finished schedule. It does not certify a particular exchange rate or output target. The received token balance establishes how many tokens the owner collected.

Proceeds calculations need virtual-order accounting aligned with the relevant timestamp. A raw stored-state read can show stale proceeds after inactivity. The getTwammOrderProceeds function updates execution before calculating proceeds during normal operation. Its read-only counterpart, getTwammOrderProceedsView, relies on existing accounting. A displayed claimable amount describes a claim against the pair. It becomes a received balance only through the token transfer.

Pool Fees and Transaction Costs

The pool’s trading fee affects swap proceeds, while contract transactions carry separate network costs. Authorized fee settings can change, so a fee quoted when creating an order need not describe its entire lifetime. Virtual execution avoids a transaction for every conceptual sub-order. Creating an order, collecting proceeds or cancelling still involves contract execution and can incur gas costs. Duration alone cannot establish the cheapest conversion, because the market price path and settlement actions also affect the overall cost.

TWAMM Execution, Spot Swaps and TWAP Measurements

A spot swap executes against the pool during a transaction, while a TWAMM order distributes its input across time. Fraxswap’s regular spot router supports minimum output for an exact-input swap. That bound lets the transaction reject output below the specified amount. The core long-term order has a different purpose: committing input to a schedule with variable proceeds. Neither mechanism removes pool price impact. Their execution boundaries differ, which matters when a required exchange rate outweighs the benefit of spreading input.

A time-weighted average price (TWAP) measures prices across an interval. TWAMM names the market-making mechanism used to execute scheduled orders. Similar terminology does not make an order’s realized exchange rate equal to an external TWAP. Pool depth, fees and arbitrage conditions affect that relationship. A stablecoin target also does not fix every pool execution at its peg. The spot router’s amountOutMin bounds transaction output; a TWAMM expiry timestamp bounds its sale schedule.