Liquidation Logic (Sell-Side)

Liquidation exists to convert speculative demand into realised capital, fund the launch's value flows, and distribute supply gradually into strength. The engine must never sell into weakness, become the dominant seller, or accelerate a drawdown — and each rule below exists to make one of those impossibilities structural.

Liquidation runs in three modes: a finite launch-phase program, the continuous steady-state mechanism, and the terminal shutdown action.

Mode 1 — Launch-Phase Liquidation (finite)

Immediately after launch, a short, fixed-duration sell program runs ($PURE: 10 minutes). Its purpose is to capture the concentrated speculative demand of the opening window and rapidly establish a realised avgSell baseline — the effect a transfer tax achieves, without embedding a permanent tax.

Each call to launchPhaseLiquidate() during the window sells one fixed chunk of 0.10% of total supply (hardcoded), and only if every gate passes:

• Strength. The spot price must be at least 3.0× the live floor (hardcoded). No strength, no launch sells at all.
• Supply cap. Cumulative launch-phase sales are hard-capped (maxLaunchSellSupplyBps — $PURE: 5% of supply). This is the primary anti-rug bound on the opening window.
• Pool impact. A chunk that would exceed the per-transaction pool cap (maxLaunchSellPoolEthBps — $PURE: 2% of pool reserves) is skipped entirely, not partially filled — the engine waits for the pool to deepen rather than degrading execution.
• Spacing. At least minSecondsBetweenLaunchSells between chunks ($PURE: 10s).

Proceeds from every launch-phase sale are split through the standard distribution path — identically to steady-state sales. When the window closes, Mode 1 is permanently done; it cannot re-arm under any circumstances.

Mode 2 — Steady-State Liquidation (pool-delta)

The steady-state mechanism answers one question on a fixed sampling cadence: has fresh base asset actually entered the pool since the last look? The engine sells only out of measured, recent buying pressure — never out of a stored budget, and never merely because the price is high.

Each liquidate() call (driven by the keeper every poolDeltaIntervalSec — $PURE: 120s) works through the following sequence:

1. Snapshot delta. Compare the pool's current base-asset reserve to the last snapshot. A non-positive delta — flat or falling reserves — re-anchors the snapshot at the current level and ends the call. Selling into weakness is structurally impossible: the engine cannot sell when no new money has arrived.
2. Strength gate. Compute strength = price / P_floor. At or below liqStartMult (3.0×), no sale — the timestamp refreshes but the snapshot deliberately does not, so pressure keeps accumulating (see below).
3. Fraction ramp. Above the gate, the engine sells a fraction q of the delta, ramping linearly from 0 at P_liqStart to qMax at P_liqMax ($PURE: up to 50% of fresh inflow at 6× the floor). The fraction starts at literally zero — just above the threshold the engine sells almost nothing, scaling up only as strength does.
4. Minimum size. If delta × q is below minSellSize, no sale; the pressure remains banked in the snapshot.
5. Caps. The sale is bounded by the per-transaction treasury cap, the per-transaction pool cap, and the per-period pool cap — the engine cannot dominate its own market however strong the signal.
6. Execute and split. Sell, update avgSell, split proceeds through the distribution path, and re-anchor the snapshot to the post-sale reserve.

Two subtleties make the mechanism robust:

The lazy first snapshot. The first liquidate() call after the launch phase ends only anchors the snapshot and returns — it never sells. Without this, the entire launch-phase pool growth would register as one giant "delta" and be harvested retroactively. Mode 2 therefore effectively begins one sampling interval after the first post-launch-phase call.

The accumulating snapshot. The snapshot only re-anchors on an actual sale or on non-positive delta. When a sale is gated off — insufficient strength, sub-minimum size, caps at zero — time refreshes but the snapshot holds, so slow, steady buying pressure accumulates across intervals until it is large enough to act on. Gentle inflow is not forgotten; it is aggregated.

The result is momentum-following, self-stopping, and self-limiting: selling scales with real inflow, stops the moment inflow stops, and can never exceed the caps regardless of timing games.

Mode 3 — Shutdown

The terminal mode, executed once by shutdown(): all market-making halts permanently, the entire LP position is removed in a single atomic action, all Treasury-held tokens are burned, and the resulting capital is repositioned for pull-based claims. The full mechanics — modes, splits, claims, and the claim window — are in Shutdown & Capital Resolution.

Where the proceeds go

Every liquidation — launch-phase and steady-state alike — splits its proceeds in the same transaction that realises them: the team share to TeamDistribution (where it vests), the supporter share to SupporterDistribution (where it becomes claimable), the ecosystem share (third-party launches only) to the $PURE EcosystemReceiver, and the market-making share retained by the Treasury as WETH. Percentages are immutable from deployment. The details live in Treasury & Value Flow.