Liquidations

When a Direct-Loan borrower's HF crosses 1 and stays there past the proposed 24-hour grace window, anyone can repay up to 50% of the debt and seize collateral at a proposed 12% discount (8 pp to the liquidator, 4 pp to the protocol reserve). Three guardrails — grace period, per-block velocity cap, 50% close factor — turn a sharp price move into an orderly multi-block winding-down rather than a flash cascade. If no liquidator shows up, the reserve is the backstop bidder of last resort. All percentages on this page are proposed; final values fixed at official launch.

The mechanic in one formula

A liquidator who repays $\Delta D$ of a borrower's QOM debt receives ZAP collateral worth (in QOM-equivalent at the TWAP):

$$\text{seized}_{\text{ZAP-value}} \;=\; \Delta D \cdot (1 + b), \qquad b = b_{\text{liquidator}} + b_{\text{reserve}},$$

with $b_{\text{liquidator}} = 8\%$ paid to the liquidator and $b_{\text{reserve}} = 4\%$ retained by the protocol. The aggregate bonus $b = 12\%$ is sized within the modern partial-liquidation range — Aave v3 sits at 5–8.5% on bluechip, Morpho's LIF formula caps at 15% — and on the higher end because QOM has materially smaller liquidator depth than Ethereum.

Per-call repayment is bounded by the close factor:

$$\Delta D \;\le\; 0.50 \cdot D,$$

so fully winding down a position requires multiple separate transactions. This is the same close-factor mechanism Aave v3 uses, except v3 escalates to 100% when HF drops below 0.95 — we keep a flat 50% to slow cascades on a chain with thinner depth.

Why everything is denominated in QOM (not USD)

Every value below — collateral, debt, HF, liquidation price — is in QOM units, derived from the ZAP/QOM TWAP read directly from the on-chain QomX pool. There is no QOM/USD oracle anywhere in the system. This is intentional and matters: a QOM dump in USD terms (with the ZAP/QOM ratio unchanged) does not liquidate anyone, because both the borrower's collateral and their debt scale identically in USD. The position is risk-neutral to QOM/USD movements — the only price that determines solvency is the ZAP/QOM ratio in the actual market where the collateral trades.

This avoids the failure mode where a thinly-traded asset (ZAP) appears to "lose value" purely because its quote currency dropped in USD. If no one is selling ZAP for QOM and the pool ratio is stable, your position is stable.

Worked example — base calibration

Take the ZAP/QOM TWAP at $p = 0.5$ QOM per ZAP at origination.

Step	Value
Borrower deposits 1,000 ZAP, TWAP $p_0 = 0.5$ QOM/ZAP → collateral value $C \cdot p_0 = 500$ QOM	borrows $D = 200$ QOM at 40% LTV
ZAP/QOM ratio drops 25% → $p_1 = 0.375$ QOM/ZAP, collateral value $375$ QOM	$\mathrm{HF} = (375 \cdot 0.50)/200 = 0.94$ → liquidatable after grace
24h grace window elapses without top-up	position eligible
Liquidator calls liquidate(borrower, 100 QOM)	uses the 50% close factor
Liquidator pays 100 QOM into the pool	receives $100 \cdot 1.12 = 112$ QOM-equivalent in ZAP, i.e. $112/0.375 \approx 298.67$ ZAP
Of the bonus: liquidator keeps $100 \cdot 8\% = 8$ QOM-equivalent in ZAP	protocol reserve receives $100 \cdot 4\% = 4$ QOM-equivalent in ZAP
Borrower remaining debt: $100$ QOM	remaining collateral: $1000 - 298.67 \approx 701$ ZAP, i.e. $\approx 263$ QOM-equivalent

After the call, $\mathrm{HF}$ recomputes with the new $C$ and $D$. If still below 1, a second liquidate call can fire — but only after a fresh per-block velocity-cap window opens, which throttles cascade speed.

Three guardrails, formally

1. Grace period $\tau_g = 24$h. A position dipping below $\mathrm{HF} = 1$ does not become liquidatable until the position has been continuously underwater for $\tau_g$. Single-block oracle noise that recovers within the window does not trigger forced unwind. The trade-off is real: a deteriorating position that crosses 1 and stays there has 24 hours during which lenders are formally underwater. The 30-min TWAP softens this — a position that crosses 1 has already been underwater for some time on the spot price before the oracle catches up.

2. Per-block liquidation velocity cap. Total notional liquidated in any single block is capped at a fixed fraction of pool size:

$$\sum_{\text{calls in block } k} \Delta D_k \;\le\; v \cdot D_{\text{pool}}, \qquad v = 5\%.$$

This caps cascade speed independently of how many keepers are in the auction. A 50% drawdown that would liquidate $X$ in dollars instantly on Aave is spread over $\lceil X / (v \cdot D_{\text{pool}}) \rceil$ blocks here.

3. Close-factor cap $\theta = 50\%$. A single liquidator call clears at most 50% of one borrower's debt. The borrower retains a position with reduced exposure and another grace-window opportunity to restore solvency. Over-liquidation — the chronic complaint about Aave v3 before Aave v4's Target HF design — is bounded structurally by $\theta$.

Liquidator economics — when keepers fire

A keeper firing $\Delta D$ in QOM realizes a profit, in QOM-equivalent terms, of

$$\pi \;=\; b_{\text{liquidator}} \cdot \Delta D \;-\; \text{gas} \;-\; \text{slippage on selling the seized ZAP}.$$

The 8 pp share is set so that even with gas and slippage on dumping ZAP back into QomX (the same market the TWAP reads), the marginal keeper expects to profit. QOM L1 orders transactions FIFO — there is no priority-fee auction, no MEV mempool, no sandwich vector. Keepers race on raw broadcast latency to a validator, not on bidding wars; the keeper that broadcasts first lands first.

Three keeper profiles compete:

Profile	What they do
Block-watching bots	Run nodes, evaluate every borrower per block, fire within one block of $\mathrm{HF}<1$. The dominant share on mature chains.
Generalist arb bots	Already-running arbitrage infra that adds a liquidate() call path. Cheap to bolt on.
Manual / backstop liquidators	Whales or other parties who watch positions and step in when bots are absent.

What if no keeper shows up

Possible on a smaller ecosystem like QOM. Layered fallback:

Layer	What it does
Grace period	Buys time for any liquidator (or the borrower) to act before bad debt accrues.
Reserve-funded backstop	If a position remains underwater past the grace window, the protocol's reserve can retire the debt at the prevailing rate. The reserve absorbs the bonus instead of paying it out.
Reserve-funded bad-debt absorption	Any unrecoverable shortfall after backstop is covered by the reserve. Lenders are not exposed to bad debt.

This is a different shape than Liquity's stability-pool model (a separate pool of pre-deposited stables that automatically offsets undercollateralized debt) but achieves the same goal: bad debt is absorbed by a dedicated capital layer, not socialized to passive depositors. We chose the reserve-funded variant because it doesn't require building a separate pool primitive at launch.

Where this sits in the liquidation-design landscape

Design	Used by	What Forge does
Fixed-bonus partial liquidation	Aave v3, Morpho	Yes — base model
Target Health Factor (dynamic repay-to-HF)	Aave v4	Considered for Phase 3, not at launch
Pure absorption (protocol takes collateral at TWAP)	Compound v3	Reserve backstop fills similar role
Stability-pool offset	Liquity v1/v2	Reserve-funded analog
Dutch auction	Older Maker, Euler v1	Rejected — historically gas-war-prone in thin keeper markets
Bonded keeper challenges	Ajna	n/a — we have a price oracle

Borrower protections, quantified

Putting the three guardrails together: a 25% spot-price drawdown over a 6-hour window produces

1. TWAP catches up gradually over 30 minutes — borrower has continuous notice.
2. Once HF crosses 1, 24 hours of grace before any liquidator can fire.
3. When liquidations fire, at most 5% of pool notional clears per block.
4. At most 50% of any single borrower's debt clears per call.

In aggregate, a borrower at the maximum LTV who experiences a sudden 25% ZAP drawdown has approximately 24 hours + 30 minutes to top up before the first liquidation hits, and then up to two close-factor calls before the position is fully unwound — each separated by their own velocity-cap-bounded window. Compare this to a same-size borrower on a default Aave v3 deployment, where liquidations can fire in the same block the oracle moves and a $0.95 < \mathrm{HF}$ position is exposed to a 100% close-factor sweep.

Net effect

Liquidations on Forge are slow, predictable, and bounded — a deliberate tradeoff that accepts more time-in-bad-debt-window in exchange for far less probability of a cascade event taking out the lender side. The reserve is the absorber of last resort.