Cowrie Research

liquidator-independence-assumptions

13 min read

Liquidator Independence Assumptions / Borrower-Separation Discipline

  • Name: liquidator independence assumptions / borrower-separation discipline
  • Category: liquidation-design reference / lending-solvency monetization checklist / positive-design companion to self-liquidation capture
  • Summary: Many lending systems implicitly assume the liquidator is economically independent from the borrower whose position is being closed. In healthy markets that assumption often holds well enough. In exploits it frequently fails. The same actor can control the violator and the liquidator through sister EOAs, helper contracts, recycled collateral, counterfeit liquidation adapters, or same-transaction loops. Once that happens, liquidation bonuses and discounted collateral seizure stop being a recovery mechanism and become an attacker payout rail. This note exists to keep that design boundary explicit instead of leaving readers to infer it only by inverting Euler, Venus ZKsync wUSDM, Onyx NFTLiquidation, Abracadabra GMX V2, or Midas Capital.
  • Why this note exists:
    • Several incidents are not explained fully by collateral was inflated or solvency check was skipped. They pay because the same adversary also owns the liquidation side.
    • Many protocols defend only against the narrowest form of self-liquidation, such as borrower != liquidator or not the same subaccount, while leaving beneficial-control equivalence, correlated funding, and helper-level substitution untreated.
    • The useful design question is often not can liquidation happen? but what assumptions make liquidation a recovery path instead of an attacker-owned monetization path?

What this note means by liquidator independence

  • Liquidator independence means the account restoring solvency is not economically the same actor as the borrower whose position is being liquidated.
  • Borrower-separation discipline means the protocol does not rely on thin address-level distinctions like different EOA or different subaccount id when the adversary can still control both sides of the trade.
  • The goal is not ban every related-party liquidation in all cases. The goal is do not quietly assume the liquidation incentive is defensive if the attacker can cheaply become the liquidator too.

The main assumptions a healthy liquidation design should make explicit

1. different address is not the same thing as independent actor

  • Two EOAs, two helper contracts, or two subaccounts can still be one economic actor.
  • If liquidation profitability survives that equivalence, the protocol should assume the borrower can internalize the liquidation bonus.
  • Euler is the clean reminder: blocking only same-subaccount self-liquidation did not matter once the attacker used separate violator and liquidator contracts.

2. Liquidation incentives are part of the exploit surface, not just the recovery mechanism

  • Close factors, liquidation bonuses, discount curves, seizure formulas, and keeper fee splits are not neutral cleanup parameters.
  • Once the attacker controls the bad state and the liquidator, those parameters define the payout size.
  • A protocol should ask whether its own rescue premium becomes attacker profit when insolvency is borrower-authored instead of market-authored.

3. Borrower-controlled funding loops matter as much as identity checks

  • Even if the protocol never explicitly lets one address liquidate itself, the attacker may still fund the liquidator from the borrower side through flash loans, correlated collateral, or borrowed versions of the same asset.
  • The practical question is not only who calls liquidate() but where did the repay capital come from and what related position does it support elsewhere in the bundle?
  • Venus ZKsync wUSDM is the useful wrapper-side example: one account borrowed the same manipulated asset another account later used as profitable liquidation ammunition.

4. Liquidation helpers must pin canonical markets, assets, and settlement meaning

  • Many modern exploits do not just control both economic sides; they also control the helper surface that decides what debt is being repaid or what collateral is being seized.
  • If a liquidation helper accepts caller-supplied market identity, underlying asset identity, or settlement route, the protocol may be validating the wrong liquidation object before it even reaches the incentive question.
  • Onyx’s NFTLiquidation exploit is the clean warning here.

5. Same-family collateral and debt pairs deserve extra skepticism

  • Self-liquidation becomes easier when the asset used to create insolvency is also the asset used to fund liquidation or seize stronger reserves.
  • Donation-sensitive wrappers, thin LP receipts, fresh collateral listings, and same-asset borrow loops create exactly this shape.
  • A system should model whether one manipulated mark can power both the liquidatable state and the liquidator’s capital source.

6. Liquidation authority should not outpace collateral trust

  • If a fresh wrapper mark, donation-sensitive rate, or migration-era price path is only barely trusted for collateral use, it is usually too early to let that same mark drive full liquidation rights.
  • Liquidation is the most irreversible consumer of a questionable solvency state because it crystallizes the mark into seized collateral.
  • This is why collateral admission lag and recursive-borrow suppression are natural companions to this note.

What sound design looks like

  • Beneficial-control thinking, not only address-level thinking

    • Protocol reviews, simulations, and invariants treat borrower and liquidator as potentially colluding or identical in economic control.

  • Liquidation premium analyzed under adversarial ownership

    • The protocol asks what profit remains if the borrower also owns the liquidator, rather than assuming keeper incentives are always defensive.

  • Canonical liquidation object pinned before execution

    • Market identity, debt asset, collateral asset, repay semantics, and helper route are fixed to protocol-authenticated objects, not caller-supplied interface lookalikes.

  • Correlated-asset and same-family loops constrained early

    • Fresh collateral, printable wrapper assets, or same-thesis borrow pairs do not immediately become ammunition for profitable self-liquidation.

  • Questionable solvency states degrade gracefully

    • The protocol can reduce close factors, cap exposure, pause one market, or disable borrow / liquidation paths before one manipulated mark becomes a full seize-and-withdraw event.

Useful positive design shapes

1. Simulate borrower + liquidator as one adversary by default

  • Testing should assume the attacker can control both the unhealthy account and the liquidating account in one bundle.
  • This often surfaces payout rails that ordinary can a third-party liquidator profit? analysis misses.
  • Euler, Midas, and Sturdy all become clearer once the liquidator is modeled as attacker-owned.

2. Treat liquidation incentives as exposure caps that must survive collusion

  • Close factors, bonus curves, and discount ramps should be chosen with the possibility that the borrower internalizes them.
  • The protocol should ask: if the attacker authors the insolvency, how much real value can these parameters let them seize before circuit breakers or liquidity limits bite?
  • The answer should be smaller than the whole pool if the mark is wrong once.

3. Require canonical-market identity on every liquidation helper branch

  • Liquidation helpers should authenticate listed markets, listed underlyings, and canonical collateral semantics from the protocol’s own registry or comptroller layer.
  • Looks like an oToken, returns an underlying, or implements liquidateBorrow() is not enough.
  • This is the straightforward design answer to Onyx-style counterfeit helper substitution.

4. Separate collateral admission from liquidation readiness

  • Fresh wrapper assets, migrated oracles, or thin exchange-rate assets can enter observation or low-risk collateral states before they become full liquidation truth.
  • The useful move is not only lower borrow caps, but also delayed or constrained liquidation authority while the asset proves itself.
  • This keeps one fresh or manipulated mark from instantly becoming a seize-stronger-assets event.

5. Constrain same-family borrow / collateral loops during warmup

  • If an asset is fresh, printable, or thin, the protocol should be reluctant to allow it to appear on both sides of the balance sheet across sibling accounts.
  • Isolation mode, correlated-borrow restrictions, or lower caps on related pairs help stop borrow manipulated asset here, use it to liquidate there loops.
  • Venus ZKsync wUSDM is the warning case for this branch.

6. Make liquidator-side capital provenance a review question

  • Audits and launch reviews should ask whether liquidation capital can be sourced directly from the manipulated collateral family, the same wrapper, or an attacker-controlled helper path.
  • This is broader than onchain identity checks. It is about whether the protocol economically distinguishes outside rescuer from same attacker with a second wallet.
  • When the liquidator is honest but liquidation still assumes unrealistic funding access or venue depth, the sharper companion is liquidation-capital provenance and keeper-competition assumptions.

Red flags that usually mean the liquidation boundary is underdesigned

  • borrower != liquidator is treated as if it proves independence
  • not the same subaccount is treated as a meaningful anti-self-liquidation defense
  • liquidation helpers accept caller-supplied market or underlying addresses because they are interface-compatible
  • fresh or donation-sensitive collateral is borrowable and fully liquidatable on the same block its new mark becomes readable
  • the same wrapper or correlated asset can appear on both the borrower and liquidator side with no extra guardrails
  • protocol reviews discuss how insolvency can be created, but not who is allowed to capture the liquidation premium afterward
  • close factors and liquidation bonuses are tuned only for ordinary keeper competition, not adversarial self-liquidation

Design questions worth asking first

  • If the borrower and liquidator are beneficially the same actor, is liquidation still economically safe?
  • What exact object proves the liquidation helper is operating on canonical debt and collateral markets?
  • Can manipulated collateral or borrowed assets from one account directly fund liquidation on a sister account?
  • Does a fresh wrapper mark, exchange-rate jump, or oracle migration become liquidation truth faster than rollback or pause tools can react?
  • How much real value can be seized if the attacker creates the shortfall and owns the liquidator too?
  • Are there same-family borrow / collateral pairs whose only realistic liquidator in stress is the attacker themself?

Failure-prevention checklist

  • Model borrower + liquidator as one adversary in design review, invariant testing, and parameter tuning instead of assuming liquidation incentives are only ever consumed by outside keepers.
  • Choose close factors, liquidation bonuses, discount ramps, and seizure formulas under the assumption that the attacker may internalize them through sister accounts, flash-loan-funded helpers, or same-family collateral loops.
  • Authenticate liquidation objects against protocol-owned market registries and canonical collateral / debt mappings before any repay or seize path can consume user approvals, reserves, or liquidation discounts.
  • Delay or constrain liquidation authority for fresh, thin, donation-sensitive, or migration-era collateral until the asset has cleared the same trust gates needed for borrow-side use and rollback confidence.
  • Constrain same-family borrow / collateral loops during rollout, especially when one manipulated wrapper or thin market can both create insolvency and later fund the profitable liquidation leg.
  • Make liquidator-side capital provenance an explicit review item: ask whether repayment capital can be sourced from the manipulated asset family, counterfeit helpers, sibling positions, or protocol-authored routing shortcuts.
  • Add circuit breakers that reduce close factors, cap liquidation size, quarantine markets, or pause liquidation helpers when questionable marks, fresh listings, or route-authenticity failures would otherwise crystallize directly into seized good collateral.
  • Treat address inequality as presentation only; any guardrail that matters should survive beneficial-control equivalence, helper substitution, and same-transaction bundling.

Audit prompts

  • If the borrower, liquidator, and helper caller are all adversary-controlled in one bundle, what exact invariant still prevents the liquidation premium from becoming an attacker payout rail?
  • Which contract, registry, or comptroller object proves the liquidation helper is acting on canonical debt and collateral markets rather than caller-supplied lookalikes?
  • Can the manipulated collateral family also become the liquidator’s repay capital through flash loans, sibling accounts, borrowed wrappers, or correlated collateral loops?
  • Are close factors, bonuses, discount curves, and seizure formulas justified only for honest third-party keepers, or do they still behave safely when the borrower captures them?
  • Does a fresh wrapper mark, migration-era oracle, or thin exchange-rate asset become liquidation truth before the protocol has had time to quarantine, de-risk, or roll it back?
  • Where does the protocol distinguish economic independence from mere address separation, and what profitable self-liquidation path still survives if that distinction collapses?
  • Do liquidation helpers accept caller-supplied market identity, underlying identity, route selection, or repay semantics that can redefine what is being liquidated before incentive analysis even starts?
  • In a stress scenario, who is the realistic liquidator set, and how much of that set is actually the attacker wearing a second wallet, wrapper, or helper contract?

Lessons that should already be standard

  • borrower != liquidator is an address fact, not an economic-independence proof.
  • Liquidation bonuses and discount curves are not just recovery incentives; under collusion they are protocol-authored payout rails.
  • A manipulated asset should not be able to create insolvency on one side and fund profitable liquidation on the other without explicit extra skepticism.
  • Liquidation helpers need canonical market identity before they need clever pricing math.
  • Fresh or questionable collateral should earn liquidation authority slowly, not inherit full seize-and-withdraw power the moment one mark becomes readable.
  • If a protocol has not modeled beneficial-control equivalence, it has probably outsourced one of its core liquidation assumptions to folklore.
  • Stress-liquidation design is not only about can somebody liquidate; it is about whether the only somebody who can realistically do so is the attacker.

Negative exemplar cluster: what broken liquidator-independence assumptions look like

  • Euler Finance is the clean different contract, same attacker exemplar: the protocol rejected only direct subaccount self-liquidation while a sister contract captured Euler’s own soft-liquidation discount.
  • Venus ZKsync wUSDM is the strong manipulated wrapper rate plus split-account liquidation capital exemplar: one account borrowed the same inflated asset another account later used to seize WETH.
  • NFTLiquidation is the helper-integrity exemplar: the attacker owned both economic sides and also controlled the helper’s notion of canonical repay and collateral objects.
  • Abracadabra GMX V2 Cauldron is the asynchronous-order exemplar: liquidation consumed real pending-order assets while stale accounting kept the same pending collateral borrowable.
  • Midas Capital is the cleanup-step exemplar: the main exploit came from exchange-rate inflation, but attacker-owned liquidation still improved extraction materially.

How to use this note with the exploit corpus

Internal linkages

Control surface

Graph View

Backlinks