Cowrie Research

self-liquidation-monetization

16 min read

Self-Liquidation Monetization / Attacker-Controlled Liquidation Capture

  • Name: Self-liquidation monetization / attacker-controlled liquidation capture
  • Category: exploit pattern / liquidation-path abuse / lending bad-debt extraction / attacker-internalized liquidation incentive
  • Summary: Some lending exploits do not end when the attacker makes a position falsely solvent or falsely insolvent. They end when the protocol also lets that same attacker capture the liquidation right. The attacker engineers a position that becomes liquidatable on favorable terms, then uses a sister account, helper contract, or counterfeit liquidation surface to seize their own collateral at the protocol’s discount or bonus before outside liquidators can compete. The real lesson is not just the protocol let a bad state exist; it is the protocol paid the attacker to be the first consumer of that bad state.
  • What it is:
    • A lending protocol offers liquidators a bonus, discount, fee share, or other favorable exchange rate for restoring insolvent positions.
    • The attacker first manufactures, amplifies, or times a liquidatable state in their own position.
    • Instead of letting the protocol socialize the loss or letting third-party keepers race for the opportunity, the attacker controls the liquidator side too.
    • The liquidation engine then converts the attacker-created accounting fiction, oracle distortion, or collateral mismatch into seized collateral, borrowed assets, or redeemable receipt tokens that remain inside the attack bundle.
    • The attack often leaves bad debt behind, but by then the liquidation premium has already been internalized by the attacker rather than used to defend the protocol.
  • Typical preconditions:
    • The attacker can split control across at least two addresses or contracts, or can repurpose a liquidation helper as a controlled execution surface.
    • Some upstream bug lets the attacker create a profitable liquidation target: exchange-rate inflation, unchecked collateral deletion, precision distortion, read-only reentrancy, helper-path accounting drift, or fake market substitution.
    • Liquidation math offers a discount, close-factor window, collateral bonus, or fee path large enough to matter economically.
    • The seized collateral can be redeemed, withdrawn, borrowed against, or otherwise converted into stronger assets before the manipulated state fully normalizes.
    • The protocol does not meaningfully distinguish healthy third-party liquidation from attacker-manufactured self-liquidation.
  • Common vulnerable surfaces:
    • liquidation incentives that assume liquidatable states arise only from honest market stress
    • two-account looping structures where one wallet supplies manipulated collateral and another wallet becomes the designated liquidator
    • collateral types whose own exchange rate or oracle can be inflated and then immediately honored in liquidation
    • convenience helpers that compose repay, seize, mint, transfer, or swap logic without pinning canonical market identity
    • collateral-toggle or reserve-management paths that let an attacker delete supporting collateral before liquidating the remainder
    • thin or isolated markets where the attacker can dominate both the debt side and the collateral side of liquidation flow
  • Exploit sequence:
    1. The attacker builds a leveraged position and prepares a second controlled address or helper.
    2. They push the primary account into an attacker-chosen liquidatable state by corrupting collateral value, deleting equity, or exploiting a pricing / accounting edge.
    3. Before outside liquidators can meaningfully respond, the attacker-controlled liquidator repays the profitable slice of debt.
    4. The protocol seizes collateral at the built-in liquidation bonus, discount, or preferential exchange rate.
    5. The attacker redeems or reuses the seized collateral, often repays flash-loan capital, and leaves the protocol holding the residual loss.
    6. Any apparent liquidation defense has now become the attacker’s payout rail.
  • Variants:
    • Unchecked-insolvency self-liquidation — the attacker directly deletes or moves their own collateral through an unchecked helper path, then liquidates the manufactured shortfall from a second address. Euler is the clean exemplar.
    • Exchange-rate inflation self-liquidation — the attacker prints a higher collateral rate, lets one account become liquidatable at that distorted mark, and uses a sibling account to seize stronger collateral. Venus ZKsync wUSDM is the clearest version.
    • Callback-window collateral release plus self-liquidation — the attacker uses transient overvaluation to remove other collateral first, then later liquidates their own now-underwater account to reclaim the manipulated collateral on favorable terms. Sturdy is the useful exemplar.
    • Reentrancy-assisted two-contract liquidation loop — the initial callback creates the undercollateralized state and the attacker later recovers more value by liquidating the first attacking contract from a second one. C.R.E.A.M. AMP’s second wave preserves this progression clearly.
    • Counterfeit liquidation helper substitution — the attacker does not only control both economic sides; they also control the liquidation helper’s notion of what market, repay asset, or collateral object is being processed. Onyx’s NFTLiquidation exploit is the sharpest version.
    • Phantom-collateral order extraction — an asynchronous collateral adapter lets liquidation pull real backing assets out of a pending order or wrapper state without consuming the same pending-collateral value still used by solvency checks, so the attacker self-liquidates one order state and then re-borrows against its ghost. Abracadabra’s March 2025 GMX V2 gmCauldron exploit is the clean exemplar.
    • Shared-ledger closeout release — liquidation-side and auxiliary-borrowing-side mutations can make one borrower ledger read as repaid while a surviving trade or position record still has not passed one canonical closeout boundary, yet a helper releases collateral anyway. OpenLeverage preserves this useful cousin because payoffTrade() treated borrowBalanceStored == 0 as enough collateral-release truth after other modules had already changed the ledger beneath it.
    • Residual-collateral sweep after empty-market inflation — the main borrow drain comes from exchange-rate manipulation, then self-liquidation is used as the cleanup step to seize and redeem the last inflated collateral more efficiently. Midas Capital preserves this useful cousin.

Three liquidation-authority promotions reviewers should not collapse

  1. A position has become economically liquidatable

    • Health factor, collateral membership, wrapper mark, pending-order value, reserve index, or debt ledger state now says the borrower can be liquidated.
    • This only answers is some bad state visible? It does not yet answer whether the protocol should treat that state as fully spendable keeper truth.

  2. The protocol accepts that liquidatable state as canonical seizure truth

    • Liquidation math, close-factor limits, bad-debt handlers, and seize calculations are now willing to honor the published state as the right basis for collateral confiscation and debt repayment.
    • This is already a much stronger claim than the account looks unhealthy, because the protocol is now publishing one canonical answer to what exact debt can be repaid and what exact collateral can be seized?

  3. An attacker-controlled liquidator is allowed to capture the keeper spread from that accepted state

    • A sibling account, helper contract, spoofed liquidation module, or correlated funding source can now consume the liquidation opportunity before independent keepers do.
    • This is the monetization boundary that turns a bad solvency state into an attacker-owned payout rail. The position is unhealthy, the protocol accepts that as liquidation truth, and the same economic actor may internalize the rescue incentive are three different promotions.
  • Detection heuristics:
    • Simulate attacker-controlled violator and liquidator accounts together; many lending designs look safe until both sides of liquidation are modeled inside one bundle.
    • Ask whether liquidation incentives are still defensible when insolvency is attacker-manufactured rather than market-driven.
    • Trace whether the same manipulated oracle, exchange rate, or helper-path fiction influences both borrow eligibility and liquidation seize math.
    • Inspect liquidation helpers for caller-supplied market addresses, underlying tokens, routers, callback targets, or settlement contracts.
    • Stress-test whether a position can become liquidatable and then immediately pay the attacker more through seizure than it cost to create the shortfall.
    • Check whether correlated assets can appear on both sides of the same protocol trade: borrowed on one account, supplied on another, then used to self-liquidate.
    • Model post-liquidation cash-out, not just can liquidation happen; many exploits only pay once seized collateral can be redeemed or reused before the mark collapses.
  • Defenses:
    • Fix the upstream state-creation bug first; liquidation should never be the first line of defense against attacker-manufactured insolvency.
    • Treat two-account self-liquidation as a standard adversarial model in testing, audits, and invariant design.
    • Apply caps, delays, quarantine windows, or correlated-asset restrictions before admitting donation-sensitive, callback-sensitive, or thin-liquidity collateral into ordinary liquidation flow.
    • Ensure liquidation helpers pin canonical markets, assets, and settlement routes rather than trusting interface-compatible caller input.
    • Re-check solvency and collateral truth on every path that can change liquidation eligibility, including collateral toggles, reserve donations, and helper-mediated migrations.
    • Bound the damage one manipulated mark can do: lower close factors, slower collateral admission, or kill switches can keep one manufactured shortfall from becoming a full-market drain.
    • When a design depends on liquidation bonuses for recovery, test whether those same bonuses turn attacker-created shortfalls into guaranteed profit instead.
    • Make liquidator independence an explicit security assumption: if the borrower and liquidator are economically the same actor through sister accounts, correlated funding, or helper substitution, the design should still fail safely.
  • High-signal incidents:

What sound design looks like

  • The protocol treats position looks unhealthy, protocol accepts one canonical seizeable state, and someone may spend against that state as liquidator as separate authority promotions rather than one blended liquidation event. Liquidation eligibility can exist without immediately becoming attacker-capturable payout authority.
  • Borrower–liquidator collusion is the default adversarial model, not an edge case. Liquidation discounts, seizure rights, and helper flows stay safe even when the same economic actor controls both sides through sibling contracts, shared funding, or bundled execution.
  • Solvency-changing state transitions and liquidation eligibility share one canonical post-state truth boundary. Reserve donations, collateral toggles, wrapper-rate updates, bad-debt rewrites, pending-order consumption, and liquidation settlement all have to agree on what collateral still exists and what debt is still real before liquidation authority is published.
  • Attacker-authored marks cannot instantly become both borrow power and liquidation value. Donation-sensitive exchange rates, thin-liquidity wrappers, pending fees, or transient callback-window valuations are delayed, haircutted, quarantined, or excluded before the same mark can support a borrow and then pay out through liquidation seize math.
  • Liquidation helpers commit to exact market identity, debt asset, collateral asset, and settlement path. The protocol never lets interface-compatible but attacker-chosen objects decide what is being repaid, seized, redeemed, or released.
  • Loss-containment paths stay defensive. Reserve absorption, bad-debt restructuring, liquidation settlement, and closeout tooling are designed to cap damage and preserve accounting truth, not to become borrower-timed rails that turn manufactured insolvency into guaranteed profit.

Failure-prevention checklist

  • Treat account is liquidatable, protocol accepts that state as seizeable truth, and a liquidator may now capture the spread as separate design gates. Do not publish all three at once just because one health-factor check fails.
  • Treat borrower–liquidator independence as a security assumption that must be encoded or compensated for, not as a social expectation. If the same beneficial owner can cheaply control both accounts, liquidation incentives are part of the attack surface.
  • Simulate two-account and same-bundle liquidation adversaries in tests, fuzzing, and invariant suites. A design that only looks safe when borrower and liquidator are modeled separately is not safe.
  • Re-check solvency and collateral truth at every path that can change liquidation eligibility, including reserve donations, collateral toggles, wrapper-rate updates, helper-mediated migrations, bad-debt rewrites, and asynchronous settlement callbacks.
  • Pin liquidation helpers to canonical market identities, debt assets, collateral assets, settlement modules, and callback origins. Do not let interface-compatible but attacker-chosen objects define what is being liquidated.
  • Restrict or heavily haircut collateral types whose value can be attacker-authored inside the same bundle through donation-sensitive exchange rates, thin liquidity, pending fees, stale order objects, or callback-sensitive accounting.
  • Put temporal separation or quarantine around newly inflated collateral marks before they become both borrow power and seizure value. If the same manipulated mark can immediately support borrowing and then liquidation seize math, the protocol is paying twice for one lie.
  • Treat bad-debt restructuring, reserve absorption, and liquidation settlement as loss-containment tools, not borrower-controlled convenience paths. Any path that socializes insolvency should be reviewed as a monetization rail.
  • Cap close factors, liquidation bonuses, and per-market seizure velocity so one manufactured shortfall cannot instantly internalize the full keeper incentive at protocol scale.
  • Alert on suspicious same-cluster behavior: repeated borrower-liquidator pairs, self-funded liquidators, correlated addresses sharing collateral and debt assets, or sudden liquidations immediately following a user-authored collateral mutation.
  • Keep protocol-level containment ready anyway: market pauses, collateral-factor zeroing, borrow caps, and per-market isolation should stop one attacker-authored insolvency from draining the rest of the book.

Audit prompts

  • Where exactly does this design promote position looks unhealthy into canonical seizeable truth, and where does it separately allow a liquidator to spend against that truth?
  • If the borrower and the liquidator are controlled by the same beneficial owner, what exact invariant still protects the protocol from paying the attacker the liquidation bonus on an attacker-created shortfall?
  • Which code paths can manufacture a profitable liquidation target without going through the same solvency checks as deposit, withdraw, mint, burn, and transfer paths?
  • Does the same manipulated variable influence both borrow eligibility and liquidation seize math: exchange rate, wrapper conversion, pending-fee valuation, reserve index, collateral membership, or order-value accounting?
  • Can the attacker choose or spoof any part of the liquidation execution envelope: market object, helper contract, callback target, router, settlement adapter, or token identity?
  • Are there borrower-visible paths like reinvest, restructureBadDebt, migration helpers, reserve donations, or collateral toggles that finalize insolvency while externalizing the loss to lenders?
  • How quickly can an attacker create insolvency and then capture liquidation in the same bundle? If the answer is one transaction, what exactly stops protocol-scale extraction?
  • Which collateral types become especially dangerous when the borrower can also be the liquidator: same-asset loops, donation-sensitive wrappers, thin LP positions, pending-order objects, or concentrated-liquidity NFTs?
  • Does the protocol distinguish direct self-liquidation only by address equality or subaccount linkage, while ignoring broader beneficial-control equivalence that sibling contracts can trivially bypass?
  • What monitoring would flag attacker-owned liquidation capture early: repeat liquidations by the same address cluster, repeated liquidator profits against one borrower, or sudden liquidation after a reserve / collateral mutation that should almost never precede honest market stress?
  • If liquidation were disabled for one block after certain collateral mutations, would the protocol merely slow honest keepers or would it cut off the exploit entirely? That answer often reveals whether liquidation is being used as an attacker payout rail.

Lessons that should already be standard

  • Liquidation is not automatically defensive. Once an attacker can manufacture the insolvency condition, the liquidation bonus becomes an extraction subsidy unless the design assumes hostile borrower–liquidator collusion by default.
  • No direct self-liquidation checks are thin protection. Sibling contracts, funded helpers, and controlled relayers are enough to recreate the same economics if the protocol only blocks exact-address reuse.
  • The dangerous question is often not can an attacker borrow too much? but can they get paid again when the position inevitably breaks? The second leg is what turns many accounting bugs into protocol-scale drains.
  • Bad-debt handling deserves the same adversarial review as borrowing and liquidation math. If debt restructuring or reserve absorption can be borrower-timed, it may be part of the exploit rather than the cleanup.
  • Correlated-asset loops matter. When the borrowed asset, the liquidated collateral, and the manipulated mark all sit in the same economic cluster, liquidation can become a capital-recycling primitive rather than a safety valve.
  • Many protocols implicitly model liquidators as independent keepers restoring order. That is a convenience model, not a security model, unless code, timing, and market structure make independence economically real.
  • The strongest defense is usually upstream: stop attacker-authored insolvency before the position becomes liquidatable. Once the protocol honors the bad state, liquidation math often only decides how generously the attacker gets paid.
  • If an exploit review stops at position became insolvent, it is unfinished. The real question is who captures the liquidation spread, on what objects, and how quickly that capture turns false accounting into irrecoverable loss.

Internal linkages

Control surface

Graph View

Backlinks