Vault liquidation

Liquidation moves part of an unhealthy vault's allocated debt, REP backing, and capacity ownership to a receiver vault. The receiver earns a REP award funded by the target; the operator only submits the operation and receives no automatic protocol payment.

Target, receiver, and operator

The target vault is the unhealthy vault whose position is reduced.
The receiver vault accepts moved security-bond debt and receives the capacity ownership and REP award.
The operator requests and stages the liquidation, paying that transaction's gas and any oracle cost.

If the liquidation remains staged, any account may execute it later and pay the execution transaction's gas. That permissionless executor does not replace the staged operator named by a delegated approval.

The receiver and target must differ. The operator may be either one, but identity alone is not a health or Sybil-resistance boundary. For the backward-compatible path, omitting a delegated receiver makes the operator the receiver and requires no signed approval.

The operator receives no liquidation ownership or REP merely for submitting the transaction. The first release assumes the operator and receiver coordinate compensation externally; the protocol neither creates a keeper marketplace nor takes a fee from the award.

Capacity and live health

A vault has a saved target backing factor, initialized by its first deposit and reused by later deposits. This target determines REP-denominated capacity ownership; it is distinct from live vault health. See the SecurityPool reference for target changes and capacity accounting. The pool totals capacity ownership in constant time. The live REP/ETH oracle price and the pool Statoblast security multiplier convert that total into current ETH minting capacity. A REP price change therefore changes capacity without rewriting vaults, and it never deletes already-open interest.

Vault health uses the vault's live REP backing, locally attributed dispute-staked REP, proportional live open interest, capacity ownership, the settled REP/ETH price, and the pool multiplier. The ordinary associated-REP branch counts pool-held and locally staked REP. The free-REP branch counts only pool-held REP because locked claims may lose. Required REP is rounded upward.

A delegated approval may demand that the receiver be healthier than the protocol minimum after the transfer. That requirement is checked against live post-liquidation state at execution; a queue-time preview is never a guarantee. The LiquidationApprovalRegistry reference defines the field.

Funded transfer and bad debt

The requested amount is ETH-denominated debt. Execution transfers no more than the target actually owes and no more than the target can fund the receiver's award for, then moves the matching backing and capacity ownership to the receiver. If a request covers the target's full position but some debt cannot be transferred safely, that remainder becomes target-local bad debt.

Delegated Liquidation Transfer

Capacity ownership and REP backing units leave the target. The authorized receiver incurs the reported debt increase and receives the ownership and backing units; target claims, fees, surplus, and unmatched ownership remain. Only a full-target request records residual target debt as bad debt.

Liquidation accountingThe operator submits the transaction, while the authorized receiver accepts the funded liability and receives the award.

The receiver must remain healthy after accepting the position, and any remaining target position must still meet the protocol's minimum sizes. These checks prevent liquidation from creating unusable dust positions. The award percentage, rounding directions, and caps are in the SecurityPool contract reference.

Bounded receiver approval

A receiver can approve an operator directly or by a bounded signature. The approval is specific to a pool, limits how much debt the receiver will accept, sets a validity window and minimum resulting health, and can be revoked for future liquidations. Existing staged work retains its reservation so cleanup remains deterministic. See the LiquidationApprovalRegistry reference for fields, nonce rules, and wallet-signature handling.

Reservation and queued execution

The price coordinator reserves the receiver's approval quota while it obtains a fresh REP/ETH price. Execution then rechecks the live target and receiver rather than trusting the earlier preview. Success consumes only the debt actually moved and releases unused quota; expiration or terminal failure releases the reservation so the receiver is not blocked permanently. The REP/ETH oracle operations reference covers staging, recovery, and failure handling.

Fork isolation

Approvals and reservations belong to one pool and its coordinator and are not copied into child pools or universes; see what Zoltar does not guarantee. A receiver approving liabilities in one universe has not approved them in a child. Pending parent operations remain permissionlessly cleanable after the parent becomes unable to execute, releasing their reservations.