# An exit that refuses to run at the wrong price

> A close that only executes if the price is inside a window you signed. Outside it, the transaction reverts rather than selling your position into a spike.

- Source: https://defiloops.com/blog/an-exit-that-refuses-to-run-at-the-wrong-price
- Published: 2026-09-16
- Category: Security
- Tags: uniswap, liquidity, ticks, execution
- Author: DeFiLoops

---
A plan written now might run in ten minutes or next week. Between the writing and the running,
the price moves — and a close that executes regardless is a close that will occasionally
execute at the worst moment available.

One operation refuses to.

## The window

You give it two numbers: a tick at the centre of an acceptable window, and a half-width in
ticks. The position closes only if the current tick sits inside that band. Outside it, the
transaction reverts.

<Spec rows={[
  ['The centre', 'A tick, which is a price. Zero is a range around the current price at the time of signing'],
  ['The half-width', 'How far either way is acceptable, in ticks. Sixty ticks is a different width in every fee tier, because spacing differs'],
  ['Outside the band', 'The whole transaction reverts. Nothing is closed, nothing is sold, and nothing is half-done'],
]} />

Both numbers are signed as part of the plan. They are not a preference held on our side and
consulted at run time — they are in what you approved, and the chain enforces them.

## What it does and does not defend against

Be precise about this, because it is easy to oversell.

The window is read from the pool's **spot tick** — where the price is at the instant the
transaction executes. So it defends against the thing that happens most: the market
having moved between the moment you signed and the moment the transaction lands.

It is **not** a defence against someone manipulating the pool. A party who can push the price
out of your window can equally push it into one, and spot-tick checks of this shape have a
known history of being gamed — there are public audit findings against exactly this pattern
elsewhere in the ecosystem. Treat it as a freshness check on a signature, not as a guard
against an adversary.

## Why a revert is the right failure

A close that fails is an inconvenience. A close that succeeds at a price you would never have
chosen is a loss you cannot undo.

Reverting costs you the network fee and leaves your position exactly as it was, which is a
position you already own and already understand. It is the cheap failure, and it is the one
worth choosing when the alternative is irreversible.

<Callout type="note" title="This is a different guard from slippage">
  A slippage limit bounds the price of a *trade* — what you get for what you sold. This bounds
  whether the operation happens at all, by asking where the market is before doing anything.
  Both can apply to the same plan and they are not substitutes for each other.
</Callout>

## Where it earns its keep

- **Scheduled exits.** A plan that fires on a clock has no idea what the market is doing when
  it wakes up. The window is how you say "not if it looks like this".
- **Price-triggered plans.** A trigger fires on a price; by the time the transaction is mined
  the price can be somewhere else. The window closes the gap between the trigger and the fill.
- **Anything unattended.** The whole point of automation is that nobody is watching, which is
  exactly when an unconditional close is most dangerous.

<Callout type="warn" title="A window too narrow never fires">
  The failure mode here is a band so tight that ordinary volatility keeps the close out of it,
  and a position you meant to exit stays open while every attempt reverts. Wide enough
  to execute, narrow enough to matter — and it is a tick count, so its meaning changes with the
  pool's spacing.
</Callout>