Just-In-Time Liquidity

Just-in-time (JIT) liquidity is the sharpest consequence of making liquidity provision granular and instantaneous.

A searcher observes a large pending swap in the mempool. In the same block, immediately before that swap, they mint an extremely concentrated position around the current price — often a single tick spacing wide. The swap executes, and because the JIT position now dominates active liquidity, it captures most of the fee. Immediately after, in the same block, the searcher burns the position and withdraws.

The searcher held inventory for zero blocks. They bore essentially none of the impermanent loss that passive providers accept as the price of earning fees, and they took most of the fee that swap generated.

Why the protocol permits it

Nothing in the pool distinguishes a position held for one block from one held for a year. Fees are credited by fee growth differencing, which measures growth across the interval a position existed — and an interval of zero blocks that happens to contain a large swap is a perfectly valid interval.

Adding a minimum duration would require the pool to track per-position timing, which is exactly the per-position state the accumulator design exists to avoid. Uniswap V3 chose the cheaper accounting and accepted the strategy.

Who actually loses

Not the swapper. The JIT position deepens liquidity at the moment of the trade, so the swapper's execution is typically better, not worse. This is why JIT is not straightforwardly an attack.

The passive liquidity providers lose. Their share of that swap's fees is diluted by a position that appeared for the profitable instant and left before any risk arrived. Over time this pushes passive providers out of the pools where JIT is most active, which is the second-order effect worth caring about: it is a redistribution from patient capital to fast capital, and it degrades the depth that exists between blocks.

See JIT liquidity attack for the framing where it is treated as adversarial, and for the cases where it does harm the swapper.

What it means for contracts you review

Any contract that reads pool liquidity, or derives a value from it, must assume that liquidity can be arbitrarily inflated for exactly the duration of one transaction and then vanish. Reward systems that pay proportional to liquidity provided, vaults that rebalance based on observed depth, and anything that uses pool.liquidity() as a proxy for a pool's health are all manipulable by an actor willing to mint and burn within a single call.