Cowrie Research

unexpected-balance-quarantine-and-explicit-recognition-discipline

16 min read

Unexpected-Balance Quarantine and Explicit Recognition Discipline

  • Name: unexpected-balance quarantine and explicit recognition discipline
  • Category: accounting-boundary reference / ambient-inventory control note / reserve-recognition design checklist / donation-neutrality companion
  • Summary: Healthy protocols do not let tokens are now sitting here instantly mean those tokens now back existing claims. Unexpected balances can appear through direct donation, prefunding, third-party top-ups of upstream recipient-owned positions, stale leftovers, fee or rounding residue, rescues, callback-time transfers, or direct transfers into lending receipt-token contracts whose raw balances are readable by flash-loan and withdrawal paths. The positive-design requirement is to keep those balances in an unrecognized inventory state until one explicit, narrow, and reviewable adoption step decides whether they should be ignored, swept, quarantined, socialized, returned, or admitted into canonical reserves. A second equally important requirement is to keep recognized locally separate from already live for redemptions, flash loans, borrowing, liquidation, or wallet-balance truth. This note exists to preserve the healthy-side boundary behind Spartan, Wise, ParaSpace, ZeroLend, dTRINITY, and similar incidents: ambient inventory is not yet solvency truth, and even recognized inventory is not automatically fully activated solvency truth.

Why this note exists

  • Many exploit notes correctly say raw balance growth is not earned value, but teams still need a design note that answers the next question: what should the system do with unexpected balances before they become recognized reserves, share backing, or collateral truth?
  • Spartan Protocol is the AMM warning: live pool balances were treated as already-recognized LP backing before reserve accounting had actually adopted them.
  • Wise Lending is the vault warning: even an anti-donation posture failed because _cleanUp() still admitted below-throttle unexpected balances into canonical pool state.
  • cAPE is the wrapper warning: upstream recipient-owned staking balances grew, and the system treated that growth as if existing shares had legitimately earned it.
  • Belt Finance is the cached-ledger warning: direct transfers changed branch conditions and let the protocol publish a false smaller recognized balance even though actual inventory was higher.
  • ZeroLend PT-LBTC is the lending-reserve warning: direct transfers to the aToken contract increased flash-loanable raw balance without increasing the scaled-liquidity denominator used for supplier accounting, so unexpected inventory became fee-bearing and later collateral-visible by accident.
  • dTRINITY dLEND cbBTC is the fresh-market reserve warning: public reconstruction indicates direct transfer into the aToken widened the same raw-balance / scaled-supply gap while the reserve was still thin enough that fee socialization and collateral admission remained attacker-authored.
  • Silo Finance is the utilization-boundary warning: raw donated WETH became borrowable liquidity before any recognition step adopted it into the deposits ledger the rate model trusted, so a second account could borrow that ambient inventory and push the market into attacker-authored utilization > 100% collateral math.
  • These incidents differ in mechanics, but they rhyme on one control surface: the protocol had no durable, explicit boundary between inventory exists and inventory is now allowed to change claims, flash-loan capacity, or collateral truth.

The five joints a healthy system should keep fused

  1. Inventory versus recognized reserves

    • The system distinguishes tokens are present from tokens have been admitted into the reserve or backing ledger that outstanding claims are allowed to redeem against.
    • Direct transfers, prefunds, residue, rescues, and upstream-recipient growth should not silently skip that distinction.

  2. Explicit recognition authority

    • One narrow mechanism owns the decision to adopt unexpected balances.
    • The allowed outcomes are explicit: ignore, quarantine, sweep, socialize, return, or recognize.
    • Recognition should also be where exposure policy is re-applied: if the protocol has supply caps, reserve ceilings, borrow-side budgets, or collateral-admission limits, off-path inventory should not skip those controls just because it arrived outside deposit() or mint().
    • The next user action happens to consult the balance is not a recognition policy.

  3. Ledger-local ownership binding

    • Recognition happens at the right scope: pool, pair, tranche, market, wrapper share base, staking recipient, or reward bucket.
    • Contract-wide balance growth is too coarse if claims are ledger-local.

  4. Publication after recognition, not before

    • Share price, rebasing index, reserve snapshots, cached NAV, and collateral adapters should consume recognized state, not raw inventory.
    • A cache or sync helper should not be the first place where unexpected inventory becomes economic truth.

  5. Downstream distrust of newly recognized value

    • Even after a balance is recognized locally, downstream collateral, liquidation, and borrowing systems may still need delay, haircuts, caps, or quarantine.
    • Recognition and immediate monetization should be separate decisions.

Three balance promotions reviewers should not collapse

  1. Ambient inventory exists

    • Tokens are physically sitting in the pool, vault, wrapper, reserve wrapper, or upstream recipient-owned position.
    • This is only a custody fact. It does not yet answer who economically owns the increment or which claim object, if any, deserves to reference it.

  2. Recognized reserve or backing exists

    • The protocol has explicitly adopted some portion of that inventory into the reserve, share-backing, or liability ledger that local accounting is allowed to treat as real.
    • This is the boundary Spartan missed in its LP-burn path: tokens are in the pool right now was not yet the same thing as these tokens now back the LP shares being burned right now.
    • It is also the boundary Wise, ParaSpace, and ZeroLend-style incidents keep testing from other angles.

  3. Economically active truth exists

    • Downstream paths such as redemption, flash-loan capacity, balanceOf, borrow power, liquidation, and reserve-spending logic are now allowed to consume that recognized value.
    • This promotion still deserves its own distrust boundary. Recognized locally is often not yet the same thing as safe to activate everywhere right now.

The design target is to answer three separate questions cleanly: what tokens are here?, which of those tokens now count as canonical backing or reserves?, and which of those recognized tokens may already affect economically forceful paths?

What sound design looks like

1. Unexpected balances stay economically inert by default

  • The clean default is that unexpected balances do not affect share price, reserve redemption, borrow capacity, liquidation marks, or reward entitlement until an explicit recognition step runs.
  • If the protocol cannot explain why a balance increased, it should not let that increase change someone else’s claim.

2. The protocol keeps a named unrecognized-inventory bucket

  • Healthy designs often need an internal concept like unaccountedAssets, surplus, pendingRewards, donationBuffer, rescueInventory, or an equivalent ledger.
  • The important point is not the variable name. It is that unexpected inventory has a holding area distinct from canonical reserves.
  • That holding area gives governance, operators, or deterministic code a chance to decide what the inventory means before users can redeem or borrow against it.

3. Recognition is narrow, typed, and policy-driven

  • Different unexpected balances deserve different treatment:
    • direct donations may be ignored or socialized slowly
    • rounding residue may be amortized or discarded
    • rescue top-ups may need explicit recapitalization accounting
    • third-party top-ups of upstream staking recipients may need full exclusion from wrapper-share value
    • prefunds may need return or isolated settlement
  • Recognition also needs to answer a separate exposure question: if this inventory is adopted, which cap, reserve budget, collateral bucket, or flash-loan budget does it now consume? Venus-style failures happen when off-path balance is eventually treated as economically real without being charged against the same quantity limits the polite deposit path obeys.
  • A healthy system does not collapse all of those cases into balance went up, so price went up.

4. Reserve-sync and share-price publication consume recognized state only

  • sync, harvest, gulp, cache writes, rebases, reward settlement, and NAV publication should read from the recognized ledger or a tightly controlled adoption routine.
  • If these helpers read raw balances directly, they become the place where ambient inventory turns into solvency truth.

5. The same explicit boundary survives composition

  • Vaults, AMMs, wrappers, rebasing collateral, and lending adapters all need the same discipline even when the surprise inventory sits one layer deeper.
  • ParaSpace matters because the dangerous inventory did not land in the wrapper contract directly; it landed in the wrapper’s upstream staking recipient. The healthy boundary is still the same: upstream balance increased is not yet existing shares earned more backing.
  • ZeroLend and dTRINITY matter because the dangerous inventory sat at the lending-wrapper boundary itself: raw tokens appeared at the aToken, flash-loan and balance-reading paths could see them, but supplier-accounting and collateral-safety logic were still dividing by a different recognized ledger.
  • Venus-style markets add the cap-policy version of the same lesson: even if a protocol wants to recognize some off-path inventory eventually, recognition cannot mean this now counts toward exchange-rate or collateral quantity while staying outside the supply-cap or exposure-budget ledger. The healthy design is still one fused object: recognized reserve quantity and risk-bounded collateral quantity should not diverge.

Useful positive design shapes

1. Internal ledger plus explicit skim / sweep / socialize lanes

  • Keep canonical reserves in one ledger and unexpected balances in another.
  • Add explicit functions or policy-controlled routines to skim, sweep, socialize, or ignore surplus.
  • The key property is that the adoption decision is visible and bounded.

2. Donation-neutral share math

  • Vaults and wrappers should avoid using raw token balances as direct share-backing truth.
  • Internal accounting, dead shares, virtual offsets, or explicit donation buffers are all acceptable shapes if they stop surprise inventory from becoming cheap exchange-rate authority.
  • This is the narrower implementation companion to vault-share-truth-security-object.

3. Reserve adoption before LP redemption or quote publication

  • AMMs should redeem LP shares and produce price-sensitive reserve outputs from synchronized reserve state rather than from ambient balances.
  • If direct transfers can inflate the inventory seen by a burn before reserve adoption is journaled, Spartan-style over-redemption is still available.

4. Wrapper backing sourced from issuance or recognized rewards only

  • Rebasing wrappers and collateral adapters should define which rails are allowed to increase per-share backing: wrapper mints, earned rewards through named harvest logic, or explicitly recognized recapitalization.
  • Third-party deposits into upstream staking recipients, strategy accounts, or reward sinks should remain excluded or quarantined until a separate policy path adopts them.

5. Publication quarantine plus downstream quarantine

6. Flash-loanable balance and supplier backing read the same recognized ledger

  • Lending systems need one extra rule stated bluntly: raw underlying sitting in the receipt-token contract is not automatically lendable reserve, supplier-earned backing, or collateral-visible value.
  • If flash loans, withdrawals, reserve utilization, or fee-routing logic can see underlying.balanceOf(aToken) before the recognition path has decided what that balance means, the protocol has split reserve truth into attacker-choosable ledgers.
  • If the market also advertises a supply cap or reserve ceiling, the same recognized ledger has to be the object that the cap constrains. Otherwise the protocol has only capped the friendly entrypoint while leaving the economically forceful reserve quantity open to off-path growth.
  • Healthy designs either keep unexpected balances economically inert, park them in a suspense lane, or reconcile them through one explicit adoption path before any flash-loan premium, liquidityIndex, reserve rate, or collateral reader is allowed to consult them.

Design questions worth asking first

  • What exact balance changes are allowed to become canonical reserves or share backing, and which should remain unrecognized inventory?
  • Does the architecture have a first-class place for unexpected balances to live before they are interpreted?
  • Which function or module is the sole authority allowed to recognize that inventory, and what policy does it apply?
  • Does recognition happen at the right ledger scope, or is contract-wide balance growth being assigned to a smaller claim object by accident?
  • If unexpected inventory is ever recognized, which cap, reserve ceiling, collateral bucket, or risk budget is it charged against, and is that the same budget the official deposit path consumes?
  • Can sync, harvest, gulp, cache publication, rebasing, flash-loan settlement, or collateral adapters bypass the recognition boundary by reading raw balances directly?
  • In lending systems, do flash-loanable balance, supplier backing, utilization, and collateral readers all consume the same recognized reserve ledger, or can direct transfers make those subsystems disagree?
  • After local recognition, what stops the newly recognized value from becoming same-block borrow power, liquidation authority, or spendable presentation truth?

Red flags

  • Any balance increase improves reserves.
  • Unexpected donations are harmless because they help everyone.
  • The next deposit / burn / sync call will naturally account for it.
  • Our anti-donation throttle is enough when below-threshold balances still move canonical state.
  • The upstream staking position belongs to us, so any increase must belong to existing shares.
  • The cache is only a gas optimization when it is the first place raw inventory becomes canonical rate or balance truth.
  • The cap only applies to deposits when raw-balance recognition, exchange-rate math, or reserve activation can still enlarge the economically trusted quantity off-path.
  • We can always reconcile later when users can already redeem, borrow, or liquidate against the unrecognized value now.

Failure-prevention checklist

  • Define a default policy for every unexpected-balance rail: direct donation, prefund, rounding residue, rescue top-up, debt-repayment residue, third-party upstream deposit, strategy-side drift, and callback-time transfer.
  • Keep a separate recognized-reserve ledger and do not let raw balanceOf or upstream position size directly reprice shares, reserves, flash-loan capacity, or collateral without explicit adoption.
  • Make one component the recognition authority. deposit, withdraw, redeem, sync, harvest, gulp, rebase, and collateral adapters should not each reinterpret unexpected inventory independently.
  • Reconcile at the right scope: pool-wide, pair-wide, tranche-wide, wrapper-wide, or recipient-local as needed. Do not let contract-wide balance changes leak into smaller claim ledgers.
  • If recognized inventory is allowed to graduate into economically active reserve, charge it against the same supply caps, reserve ceilings, collateral limits, or flash-loan budgets that the official issuance / deposit path would have consumed.
  • Ensure LP burns, share redemptions, flash-loan capacity, and collateral valuations consume synchronized recognized state, not ambient balances.
  • Treat upstream recipient-owned positions as part of the same threat model. If outsiders can top up the recipient, the wrapper still has an unexpected-balance problem even when its own contract balance never changes.
  • Separate recognition from publication and from monetization. A newly adopted balance should not automatically become same-block balanceOf, borrow power, or liquidation truth.
  • Add low-supply tests for unexpected-balance paths. Thin share supply makes even small surprise balances disproportionately dangerous.
  • Fuzz combined edge cases: direct transfer plus stale cache, donation plus low supply, upstream third-party top-up plus collateral revaluation, and rescue recapitalization plus immediate redemption.
  • Monitor balance increased without journal entry conditions in production and alert when raw inventory, upstream recipient balances, or strategy holdings move without the expected recognition event.

Audit prompts

  • What exact event moves assets from ambient inventory into recognized reserves here?
  • Can a user cause the protocol to consult raw balances before that recognition step completes?
  • If an unexpected balance appears today, which line of code decides whether it is ignored, socialized, swept, quarantined, or recognized?
  • Does the system prove which pool, wrapper, pair, or claim owns the unexpected inventory, or does it infer ownership from whichever action runs next?
  • Can a helper such as sync, gulp, harvest, rebase, or cache publication be attacker-timed so that raw inventory becomes canonical price or reserve truth?
  • If an upstream staking or reward recipient balance increases, what proves that increase came through the wrapper’s own issuance or reward-recognition path rather than from a third-party top-up?
  • If the protocol recognized a large off-path balance tomorrow, which exact cap or risk budget would absorb it, and what prevents the system from treating that recognized quantity as outside the same exposure limits normal deposits obey?
  • After recognition, what additional control prevents same-block borrowing or withdrawal against value that may still be economically contestable?
  • If raw tokens arrive at a lending receipt-token contract outside the official supply path, which subsystems change immediately: flash-loanable balance, reserve utilization, supplier index, withdrawal capacity, or collateral value? Which of those changes are actually intended?
  • In a near-empty pool or vault, how expensive is it for an attacker to create a meaningful recognized-state distortion from a small unexpected balance?
  • If operators must recapitalize or rescue the system, how does that fresh inventory avoid being mistaken for ordinary earned value or user-attributable backing?
  • Which production alerts would fire if balances rose without the matching recognition journal entry, reserve adoption event, or wrapper-share issuance event?

Lessons that should already be standard

  • Inventory is not reserves until the protocol says so.
  • Unexpected balance helped the pool is not a security argument. The real question is who is allowed to monetize that help, when, and through which ledger.
  • Anti-donation logic fails if any leftover path still promotes attacker-authored balances into canonical state.
  • Upstream recipient-owned balances are part of the same accounting boundary as wrapper balances once share price or collateral value depends on them.
  • Reserve publication helpers are not housekeeping. If they can canonize ambient balances, they are solvency code.
  • Thin-supply states make recognition mistakes far more dangerous because tiny surprise balances can dominate per-share or per-LP economics.
  • Rescue capital, recapitalization, and donations should not share one undifferentiated path. Different balance origins need different adoption policies.
  • A cap on the friendly deposit path is not a cap on economic exposure if off-path inventory can still become recognized reserve or collateral quantity without consuming the same budget.
  • A protocol that cannot answer where do unexpected balances live before we decide what they mean? has not actually closed its accounting boundary.

How to use this note with the exploit corpus

Internal linkages

Control surface

Graph View

Backlinks