The Time-Weighted Average Market Maker

The five-minute read

One action, walked through

1. A trader deposits the asset they want to sell and names an interval.
2. The order joins the virtual flow of that direction.
3. As time passes, the flow is treated as trading continuously against the pool and against the opposite flow.
4. The next person who touches the pool updates the lazy state to the current time.
5. At the end, the trader withdraws what the flow bought. They can cancel early, on the note's terms, and take what has executed.

The argument, unpacked

What has to be true

• The embedded pool is constant-product, or the closed form does not apply. A concentrated-liquidity pool needs a different derivation.
• Someone interacts often enough if the application cannot tolerate stale reserves. The math is defined either way. The readers of storage may not be.
• The order's interval and size are what the user signed. A hook can change the meaning of those fields.
• Cancellation rules are the ones in the contract. The note's early-withdraw behaviour is part of the design, not a default of every fork.

What happened after the paper

TWAMM ideas showed up in research prototypes and as candidate Uniswap v4 hooks. A hook that advertises the name may execute a simpler schedule. The 2021 note is the citation for lazy continuous execution against a constant-product pool. It is not Uniswap's time-weighted oracle, which is a different object in the v2 paper.

What to check before you use the idea

• Is this a schedule to trade, or a report of past prices?
• What pool curve is the closed form written for?
• When are reserves updated, and who updates them?
• What does the trader receive if they cancel halfway?

Terms

Virtual order

An order the contract treats as trading continuously, without a transaction at each moment.

Lazy settlement

Bringing that virtual trading up to date only when someone next touches the pool.

The problem the paper names

A single swap against a constant-product pool moves the price by the whole size at once. Splitting it by hand costs gas and leaks the schedule. The TWAMM wants the split without the transactions.

What the design proposes

• Users submit long-term orders: sell this much of A for B between two times.
• The pool virtually executes those orders continuously against its reserves.
• Anyone who touches the pool brings the lazy accounting up to date.

How the mechanism is specified

• Between interactions, the closed form of the constant-product curve plus a constant flow can be computed without iterating every block.
• Gas stays on the order of a normal swap, not on the order of the number of slices.
• Price impact falls only if opposite flow, or time, actually absorbs the order. The paper does not cancel impact.

What this page does not treat as proven

• A TWAMM is not Uniswap's time-weighted average price oracle. One is an order. One is a measurement.
• Lazy settlement means the on-chain reserves can be stale until someone transacts. Integrators who read reserves mid-interval have to understand that.
• The note is a design. A hook that claims to be a TWAMM can be a different formula.

Why a venture studio still reads it

If a product says TWAP, ask whether it is reporting a past price or selling an asset over time. Those are opposite directions of data flow.