Cowrie Research

collateral-liveness-and-right-consumption-discipline

15 min read

Collateral Liveness and Right-Consumption Discipline

  • Name: collateral liveness and right-consumption discipline
  • Category: lending-safety reference / collateral-liveness design note / representative-object consumption checklist / pending-collateral derecognition discipline
  • Summary: Healthy lending systems do not let an order, receipt, pending adapter object, or collateral record remain borrow-authoritative merely because the record still exists. They treat collateral liveness as one security object: the exact representative record, the exact backing assets or rights that still remain reachable through it, the exact paths allowed to consume that backing, and the exact state transition that retires or quarantines borrow authority when the backing is withdrawn, seized, refunded, failed, or otherwise spent. This note exists to preserve the positive-design companion for incidents like XCarnival and Abracadabra GMX V2, where the protocol kept trusting a surviving object after the real collateral it was supposed to prove had already been removed or partially consumed.
  • Why this note exists:
    • entrypoint-only-policy-off-path-state-mutation preserves the exploit-side family where policy sits on one path while a wider state object defines the real economic truth.
    • solvency-check-bypass preserves the adjacent family where debt or borrowing power survives a path that already consumed user equity or collateral.
    • collateral-membership-truth-security-object keeps the broader which assets support this debt right now? question explicit, but a narrower recurring failure keeps showing up inside representative objects such as orders, receipts, and async adapters: does this record still have any live backing left, and if not, why is it still borrow-authoritative?
    • This note keeps that liveness-and-consumption question explicit instead of forcing readers to reconstruct it only by inverting hollow-order and phantom-collateral exploits.

Fast classifier: what kind of collateral-liveness failure are you trying to avoid?

  • the order still exists, but the pledged asset already left custody — the representative record survives, but the actual NFT, LP token, or other pledged asset was already withdrawn through a sibling path. XCarnival is the clean exemplar.
  • liquidation or refund already consumed real backing, but solvency still trusts the old pending value — an async adapter or helper extracted actual assets while the reporting path kept publishing the original collateral value. Abracadabra GMX V2 is the clean exemplar.
  • a representative object has two contradictory meanings — one module treats it as remaining backing that can still pay, another treats it as historical or nominal order metadata, and the protocol never decides which one defines borrow authority.
  • the object is operationally open but economically dead — developers may describe it as active, pending, or not yet closed, but the remaining extractable value is already zero or smaller than the amount still being recognized for solvency.
  • Use this note when the sharper design question is what should make a collateral-representing object stop authorizing borrowing the moment its backing stops being live?

What this note means by collateral liveness

  • Collateral liveness means the representative object still has the backing properties the protocol is relying on right now:
    • the pledged asset or claim is still locked, reserved, or otherwise reachable through that object
    • the object still has some remaining extractable value or rights the protocol is willing to treat as collateral
    • no sibling path has already consumed, refunded, seized, or derecognized that value without also consuming the object’s borrow authority
  • The important design target is not merely the order id still exists or the record is marked active.
  • It is this exact record still has live backing, and every path that can consume that backing is forced to consume or reduce the same borrowable meaning.

Three questions reviewers should not collapse into one

  • does the object still exist?
    • This is the weakest question. Storage persistence, an active flag, or a pending-order record only proves the protocol still has an object to talk about.
  • does the object still have any live backing or extractable value?
    • This is the liveness question. It asks whether there is still collateral, refund value, or claimable inventory left behind the object after liquidation, cancellation, refund, seizure, or partial settlement.
  • even if some residual backing remains, does the object deserve immediate ordinary borrow authority?
    • This is the downstream-solvency question. Residual or disputed value may justify refund-only, exit-only, haircut, or quarantine treatment instead of ordinary borrowing.
  • Healthy systems keep those three questions separate. Object still exists is not yet object still has backing, and object still has some backing is not yet object deserves full live borrow authority.
  • The nearby companion is collateral-admission-lag-and-borrow-side-quarantine when the main design move is not only consume stale collateral truth correctly but also stage or quarantine the residual object before it regains ordinary credit power.

The six joints a healthy collateral-liveness object should keep fused

1. Canonical representative identity

  • The protocol needs one exact answer to which object currently stands in for collateral truth: order id, pending adapter position, NFT pledge receipt, queued withdrawal object, or other representative record.
  • Borrow logic should not infer collateral from some record exists somewhere; it should consume one canonical object whose semantics are explicit.
  • This is the joint that prevents ghost authority from surviving in stale side tables or helper-local metadata.

2. Backing custody or claim liveness

  • The representative object must stay bound to whether the underlying asset or claim is still actually present, locked, or reachable.
  • If the NFT has already been withdrawn, if pending order inventory was already seized, or if the refund right already paid out, the object is no longer fully live even if it remains structurally present in storage.
  • A healthy design makes this liveness field part of the borrowability truth, not optional context.

3. Remaining extractable value

  • The protocol should know not only whether backing once existed, but how much value remains reachable right now through that representative object.
  • Pending-order adapters, partial seizures, staged unwinds, and liquidation helpers make this especially important: historical input amount is weaker than remaining amount still claimable.
  • If remaining value can shrink through liquidation, refunds, or helper extraction, solvency must read the shrinking quantity rather than a static creation-time record.

4. Shared consumption across all paths

  • Every path that can consume the backing must also consume or reduce the same representative object’s collateral meaning.
  • That includes withdrawals, liquidation seizures, refunds, order cancellations, emergency exits, rescue helpers, and asynchronous settlement callbacks.
  • The dangerous anti-pattern is a split where one path moves real assets and another path continues publishing unchanged collateral authority.

5. Borrow and solvency consumers only trust live state

  • Borrow gates, health checks, LTV math, and liquidation logic should read a liveness-aware, post-consumption view of the representative object.
  • Active, exists, or pending are not enough if those flags can survive after backing leaves.
  • A healthy system lets representative objects become non-borrowable sooner than they become fully garbage-collected if necessary.

6. Explicit terminal and quarantined lifecycle states

  • Representative objects should have legible states such as:
    • live and fully backed
    • partially consumed / partially backed
    • refund-only or exit-only residual
    • quarantined pending reconciliation
    • fully closed / zero-backed / non-borrowable
  • Not yet deleted is not a valid collateral lifecycle state.
  • If closure is asynchronous, the safe default is to narrow authority during the gap rather than to keep full borrow meaning alive.

What sound design looks like

  • Borrow authority is derived from backing, not from record persistence

    • A surviving object should not matter if its backing has already left custody or been seized.
    • The protocol should make object still stored strictly weaker than object still collateral-valid.

  • Every consumption path updates the same remaining-value object

    • Withdrawal, refund, seizure, liquidation, and cancellation paths should all reduce or retire the same quantity later trusted by solvency.
    • The system should not have one field for what still pays and a separate untouched field for what borrowing still trusts unless one is deliberately non-authoritative.

  • Asynchronous or partial states narrow authority rather than preserve full borrowability

    • If a pending order can fail, partially fill, refund, or be seized, the safe posture is to haircut, quarantine, or fully derecognize it until remaining value is recomputed from settled state.
    • Unsettled external middleware should usually be weaker collateral than fully settled custody.
    • The useful ladder is explicit: representative object still visible → some residual backing may remain → ordinary borrowing may resume only after the protocol re-earns that trust.

  • Representative objects close economically before they close cosmetically

    • The system may keep records for auditability, retries, or UX, but borrow authority should disappear as soon as live backing no longer supports it.
    • Archive retention and collateral authority should not be the same question.

  • The clean reviewer question is: if this object paid out or released value one more time right now, what exact field would stop the protocol from still borrowing against the old amount afterward?

Useful positive design shapes

1. One canonical remaining backing variable

  • Keep one authoritative quantity or state bundle for what collateral value is still reachable through the representative object.
  • Creation-time fields like inputAmount, pledge metadata, or original order value may still exist for history, but solvency should read the live remaining-backing field instead.

2. Consumption-first helper design

  • Design helper functions like withdraw, sendValue, cancel, refund, and liquidate so they mutate the representative object’s borrowable meaning before or atomically with external asset movement.
  • If a helper cannot update the representative object immediately, the safer default is to freeze borrowability until reconciliation finishes.

3. Residual-mode instead of fake liveness

  • When an object still needs to exist for refunds, claims, or dispute windows, classify it as residual or exit-only rather than as live collateral.
  • If some backing may still remain but its exact amount, timing, or extractability is no longer clean enough for borrowing, keep the object in a narrower quarantine state rather than letting partly alive collapse back into fully borrowable.
  • The nearby companions are exit-only-residual-surface-discipline when the main question becomes how to keep such residual authority narrow and legible, and collateral-admission-lag-and-borrow-side-quarantine when the follow-up question is how a residual or repriced object should re-earn ordinary credit power.

4. Recompute from settled extractable value

  • For async adapters, pending orders, or routed positions, collateral recognition should be derived from what can still actually be extracted under current state, not from stale order intents or initial deposits.
  • If current extractable value is expensive or ambiguous to compute, that is often a reason to quarantine or heavily haircut the object rather than a reason to trust the stale nominal value.

5. Shared closure rules across sibling paths

  • If withdrawNFT(), sendValueInCollateral(), cancelOrder(), refund(), and liquidate() all touch the same economic backing, they should all inherit one closure rule for when the object stops counting as collateral.
  • The nearby companion is helper-path-invariant-reuse-and-fail-closed-discipline when the sharper question is why sibling paths must preserve one invariant rather than each carrying their own partial story.

6. Non-authoritative history fields

  • Historical fields may still be useful for analytics, dispute review, or event reconstruction, but they should be clearly segregated from the fields that power solvency and borrowing.
  • If the protocol needs both what this object originally represented and what it still represents now, make the distinction machine-readable and reviewable.

Design questions worth asking first

  • What exact object currently stands in for this collateral, and what fields inside it are authoritative for borrowing or solvency?
  • Which functions can reduce the object’s real backing: withdraw, refund, liquidation, emergency exit, partial cancel, rescue, settlement callback, or operator action?
  • Do all of those paths consume or reduce the exact same quantity later trusted by borrow and health checks?
  • Can the object remain marked active or pending after the remaining backing is already zero or materially smaller than the published collateral value?
  • If the object is asynchronous or partially fillable, what forces solvency to read settled remaining value instead of historical nominal value?
  • What state does the object enter after backing is consumed but before cosmetic cleanup completes, and is that state definitely non-borrowable?

Red flags that usually mean the protocol is authenticating the wrong object

  • borrowability depends on order exists, status == active, or pending == true while backing-custody truth lives in a separate field or module
  • withdrawals, refunds, or liquidation helpers can move real assets without mutating the fields later read by solvency
  • creation-time fields like inputAmount, initialAmount, or pledgedAt are reused as live collateral value after partial fills or seizures
  • closure or zeroing only happens on one happy-path callback, while other realistic failure or liquidation paths can already consume the backing
  • residual records keep ordinary collateral rights because cleanup is asynchronous or operationally inconvenient
  • reviewers can describe how the object is created, but not the exact moment it stops being collateral-valid

Failure-prevention checklist

  • Define one canonical representative object for every non-trivial collateral type, especially orders, receipts, async adapters, and staged settlement positions.
  • Distinguish historical metadata from live backing state; make solvency read only the latter.
  • Enumerate every path that can consume or reduce real backing, including liquidation helpers, refunds, cancellations, emergency exits, and partial-settlement flows.
  • Force those paths to consume, reduce, or quarantine the same representative object state that borrow and health checks trust.
  • Add invariants that prove remaining backing == 0 implies borrowable value == 0 and collateral-valid == false.
  • Treat asynchronous cleanup gaps as quarantine states, not as excuses to preserve ordinary collateral authority.
  • Haircut or derecognize pending external-order state unless remaining extractable value can be recomputed safely and cheaply from settled reality.
  • Test repeated-consumption scenarios explicitly: withdraw then borrow, liquidate then reborrow, refund then borrow, partial seize then borrow the full original amount, and fail-order then reuse historical metadata.
  • Require incident reviews and audits to name the exact field or state transition that retires borrow authority when backing leaves.
  • Preserve operator telemetry for backing consumption and derecognition so responders can quickly answer which representative objects still have live value and which are just historical shells.

Audit prompts

  • What exact state transition makes this representative object stop counting as collateral?
  • Which paths can move or consume backing before that transition fires?
  • After a partial seizure or refund, what exact fields are reduced, and are those the same fields health checks read?
  • Can an attacker keep the object visually or administratively open while economically emptying it?
  • Does any helper or callback consume real assets while leaving nominal order metadata unchanged?
  • If cleanup is asynchronous, what prevents the object from remaining fully borrowable during the lag?
  • Could a historical amount, pledge record, or pending-order intent survive as solvency truth after the object has already paid out once?
  • What negative tests prove that an object can never fund borrowing after its backing has already been withdrawn, seized, or refunded?

Lessons that should already be standard

  • Records are not collateral. Backing is collateral.
  • A protocol should be able to answer what value is still reachable through this object right now? more easily than what did this object mean when it was created?
  • Consumption paths are part of collateral design, not just cleanup plumbing.
  • If real assets can leave through a helper, refund, or liquidation path, the object’s collateral meaning has to leave with them.
  • Asynchronous adapters are dangerous precisely because they create long-lived representative objects whose backing changes outside the borrow path.
  • Historical metadata and solvency truth should never share a field just because it is convenient.
  • The safest default after uncertain settlement, partial failure, or partial seizure is narrower authority, not optimistic full collateral recognition.
  • The right invariant is blunt: once the backing is gone, the borrowing right is gone, even if the object is still around for bookkeeping.

Negative exemplar cluster: what broken collateral liveness looks like

  • XCarnival is the clean withdrawn-collateral order exemplar: the NFT left custody through withdrawNFT(), but the surviving order still authorized later borrowing because the borrow gate ignored _order.isWithdraw.
  • Abracadabra GMX V2 is the clean async-order consumption exemplar: liquidation extracted real RouterOrder value, but orderValueInCollateral() kept publishing the old pending collateral.

How to use this note with the exploit corpus

Internal linkages

Control surface

Graph View

Backlinks