Cowrie Research

vault-share-truth-security-object

18 min read

Vault Share Truth as a Single Security Object

  • Name: vault share truth as a single security object
  • Category: vault-accounting reference / share-system design checklist / collateral-integrity reference / protocol-comparison note
  • Summary: Healthy vaults do not let share price, convertToAssets, pricePerShare, rebasing balances, redemption rights, transfer-time entitlement, callback-window valuation reads, and collateral value drift into separate stories. They keep one security object intact across asset recognition, share issuance, supply-state transitions, rate publication, balance movement, and every downstream consumer that is allowed to honor the result. The crucial ladder stays explicit: a local wrapper mark may be observable, then deliberately recognized or published as protocol accounting truth, and only later admitted as downstream collateral or redemption authority. If balances themselves carry live fee debt, reward debt, reserve-backed withdrawal rights, or same-transaction LP / wrapper marks that only make sense once an upstream venue settles, plain transfer and freshest read wins both belong inside that same object. Most donation, first-deposit, exchange-rate, transfer-entitlement, and wrapper-collateral exploits are different ways that one object gets split apart while the interface still looks like a vault share backed by assets.
  • Why this note exists:

The five joints a healthy vault share should keep fused

  1. Recognized backing assets

    • The vault needs one explicit answer to which assets count as backing right now?
    • Raw token balance, strategy mark, reward inventory, rescued funds, direct donations, rebasing drift, and pending harvest value should not all automatically collapse into the same backing truth unless the protocol truly wants them all to be money-good immediately.
    • This is the joint that breaks in balance-delta-provenance-failure and many donation-style cases.

  2. Issued-share ownership state

    • The capitalization table needs to stay meaningful across bootstrap, dilution, burns, migrations, and near-zero-supply states.
    • There are shares outstanding is not enough if dust supply, dead-share absence, or reversible initialization semantics let one actor cheaply dominate the whole claim structure.
    • This is the joint that breaks in first-deposit-inflation and bootstrap-state-replay-reversible-initialization-semantics.

  3. Conversion and publication semantics

    • A vault share system must decide what convertToAssets, previewRedeem, rebasing balanceOf, cached NAV, same-transaction LP / virtual-price reads, and related outputs actually mean: optimistic view, published protocol accounting, settlement-ready claim, collateral oracle, or some weaker presentation object.
    • The key separation is three-step, not one-step: the wrapper can print or observe a mark, the protocol chooses to publish or recognize that mark as meaningful accounting, and downstream consumers are allowed to spend, lend, liquidate, or redeem against it.
    • If user-facing conversion math and solvency-critical conversion math are the same object, then any path that perturbs the conversion rate becomes a treasury surface — including callback-window reads whose output is only locally true until an upstream venue finishes settling.
    • This is the joint that breaks in donation-share-price-manipulation and donation-share-price-manipulation.

  4. Supply-lifecycle and state-transition discipline

    • Healthy share truth includes rules for when the vault is in bootstrap, low-supply recovery, ordinary operation, distressed mode, or recapitalization mode.
    • If runtime state can silently move a live system back into new vault semantics, then share truth is no longer one stable object over time.
    • This is the joint that breaks in first-deposit replays, low-supply recurrences, and some migration or rescue flows.

  5. Downstream economic consumers and balance-mobility semantics

    • The vault needs a clear boundary around who may honor share truth: redemption, withdrawal, liquidation seize math, borrow collateral, routing, accounting snapshots, fee settlement, transfer-time entitlement movement, or cross-module wrappers.
    • A share price that is safe enough for display is not automatically safe enough for protocol-authored accounting publication, and published accounting truth is not automatically safe enough for lending collateral, same-block redemption, transfer-time reward inheritance, callback-window borrowing, or inverse borrow-side math.
    • If a balance carries live reward debt, reserve-backed withdrawal rights, pending fees, or some other economically active state, then transfer() and transferFrom() are no longer neutral plumbing. They are part of the same share-truth object.
    • This is the joint that breaks when wrapper-share value becomes immediate collateral truth in incidents like C.R.E.A.M. yUSD, Wise Lending, Venus wUSDM, and when movement paths reopen or duplicate entitlement in cases like Popsicle Finance Sorbetto Fragola PLP.

Three wrapper-share promotions reviewers should not collapse

  1. A local wrapper mark exists

    • The vault, wrapper, or strategy may be able to print a new convertToAssets, rebasing balanceOf, pricePerShare, cached NAV, or equivalent exchange-rate mark.
    • That still only answers what does the wrapper currently say?

  2. The protocol published that mark as canonical share truth

    • A recognition, harvest, sync, cache write, rescue reconciliation, or other accounting transition may move that wrapper-local mark into canonical holder economics.
    • That is a stronger claim: the protocol now socializes this value across outstanding shares as current accounting truth.

  3. Downstream systems honored that share truth as spendable authority

    • Redemption paths, lending adapters, liquidation engines, routing systems, or sibling wrappers may then treat the published mark as immediate money-good authority.
    • That is stronger again: other balance sheets may now pay out, lend against, seize against, or recursively build on this mark.

Most wrapper-share incidents do not break at only one step. The exploit is usually the collapse between them.

Three balance-mobility questions healthy share systems should not collapse

  1. Did the balance move?

    • This is the narrow token-accounting question.
    • It only answers who now holds the units?

  2. Did the live reserve-backed entitlement move coherently with the balance?

    • This is the fee-debt, reward-debt, pending-withdrawal-right, and reserve-backed-claim question.
    • It asks whether the economic right attached to the balance moved exactly once with the balance, instead of staying behind, duplicating, or being silently reopened.

  3. Did consumed-state and downstream authority stay monotone after the movement?

    • This is the checkpoint, claim-consumption, and post-transfer solvency question.
    • It asks whether the protocol still knows which portions of the share’s history were already consumed, settled, or recognized, and whether downstream withdrawal or reward paths will honor that answer coherently.

Healthy vaults answer those three questions separately. They do not let the ERC-20 balance moved silently imply the reserve-backed economic right moved correctly too, and they do not let the right moved silently imply all claim-consumption and later payout paths are still monotone.

What sound design looks like

Healthy architectural shapes

1. Internal-ledger vaults with explicit recognition

  • The cleanest design distinguishes assets physically present from assets economically recognized.
  • Direct donations, rescued funds, reward drips, rebasing drift, and strategy-side transfers land in a staging or reserve concept first, then move into canonical share backing only through a named reconciliation path.
  • This shape is strongest when the recognition path itself cannot be attacker-timed into collateral or redemption authority.

2. Virtual-liquidity or seeded-supply vaults

  • The cleanest bootstrap defense is to make opening capitalization-table manipulation expensive.
  • Dead shares, virtual assets / shares, trusted seeding, or non-burnable minimum liquidity can keep a dust depositor from buying control over future share pricing.
  • This shape is strongest when the protection also survives low-supply recovery, not only initial deployment.

3. Three-stage publication and admission models

  • The vault may expose one fast local mark for UX, one stricter protocol-authored accounting view, and one even narrower or slower path for collateral, liquidation, or redemption-critical consumers.
  • This shape is strongest when the protocol can explain exactly how a value graduates from observed to recognized / published to money-good for downstream risk engines.

4. Wrapper-collateral systems with quarantine gates

  • If vault shares are accepted elsewhere as collateral, healthy systems delay admission, cap exposure, enforce minimum share supply, and challenge sudden share-price jumps before full borrow authority is enabled.
  • This shape is strongest when wrapper-share truth is treated as one structured asset with its own manipulation model rather than as a standard ERC-20 with incidental yield.

5. Explicit distress and recapitalization modes

  • When bad debt, migration, rescue, or extreme redemptions thin out supply, the safest systems switch into an explicit repair path rather than letting the next ordinary user deposit silently become the new capitalization table.
  • This shape is strongest when recapitalization policy is already defined before the incident, not improvised after low-supply conditions appear.

Design questions worth asking first

  • What exact state changes are allowed to increase canonical backing per share: deposits, realized strategy PnL, approved rewards, debt repayments, donations, rebases, rescue flows, or operator syncs?
  • Which output is the real economic truth object at each stage: local wrapper math, protocol-authored accounting, redemption quote, or collateral price feed?
  • What exact event promotes a printed or observed wrapper mark into canonical protocol accounting, and what separate event lets that accounting become redeemable or borrowable truth?
  • Can the live system revisit launch-dangerous states after burns, bad-debt socialization, migrations, claims, or emergency exits?
  • Who is allowed to crystallize pending value into canonical share truth: harvest, sync, cache publication, strategy report, rebasing index update, fee settlement, or rescue reconciliation?
  • If the share price jumps 5x or 50x in one block, which downstream consumers stop trusting it first, and which continue to honor it automatically?
  • If shares are transferable and carry live entitlement, what exactly moves on transfer: only units, or units plus checkpointed fee / reward / withdrawal rights too? What prevents those rights from being duplicated or reopened?
  • If another protocol accepts this share as collateral, what assumptions from the vault’s accounting model have effectively become oracle assumptions for the whole stack?
  • What exact upstream state object ultimately authors this wrapper’s value in the hottest path: recognized backing, cached NAV, parent-vault exchange rate, LP virtual price, reserve ratio, or some same-transaction helper that is only safe once another venue settles?

Red flags that usually mean share truth is being authenticated by folklore

  • totalAssets is just the token balance with no policy for unsolicited transfers, stealth donations, rebases, or rescued funds.
  • The vault already follows ERC-4626 used as if standard conformance proved economic safety under donation, rounding, or low-supply conditions.
  • balanceOf or convertToAssets is used for UX and for collateral with no distinction between presentation and settlement authority.
  • The first-deposit problem is solved at launch even though burns, migrations, or redemptions can later recreate dust supply.
  • Rewards are harmless because they are yield when anyone can time or influence when those rewards become canonical share backing.
  • transfer() is treated as just ERC-20 plumbing even though the balance also carries live fee, reward, reserve, or withdrawal entitlement.
  • Wrapper shares are just another collateral token even though their value is locally publishable by the wrapper’s own accounting decisions.

Failure-prevention checklist

  • Define one canonical recognized-backing ledger and make every share-price, redemption, and collateral-critical path derive from it instead of from ambient token balances alone.
  • Decide explicitly how direct donations, rebasing drift, fee leftovers, rescued funds, strategy-side transfers, and reward drips enter share truth. If they should not become user-owned backing immediately, quarantine them.
  • Add meaningful virtual assets / shares, dead shares, or non-burnable minimum liquidity so bootstrap and low-supply states cannot be cheaply captured by a dust holder.
  • Make bootstrap one-way and low-supply recovery explicit. Ordinary user flows should not silently restore new vault semantics after redemptions, migrations, claims, or bad-debt cleanup.
  • Separate presentation from protocol accounting authority and from solvency authority. convertToAssets, preview*, cached NAV, and rebasing balances should not automatically become canonical accounting, same-block reserve-backed payout truth, collateral truth, or redemption authority without additional checks.
  • Encode the promotion ladder explicitly: wrapper mark readable is one state, protocol recognizes / publishes it as accounting truth is a second state, and downstream systems may lend, liquidate, route withdrawals, or redeem against it is a third.
  • Restrict and monitor who can publish value into canonical share state: harvest, sync, strategy reports, cache writes, reward settlement, and rescue reconciliation are security-sensitive authority surfaces.
  • If balances carry live fee, reward, reserve, or withdrawal entitlement, make transfer-time semantics explicit. Movement should carry entitlement coherently, settle it exactly once before movement, or fail closed rather than reopening historical claims under weaker truth.
  • Apply collateral haircuts, admission delays, borrow caps, and supply-floor requirements before wrapper shares become system-wide borrow power.
  • Inventory transitive valuation dependencies for every wrapper collateral path. If a wrapper bottoms out in an upstream get_virtual_price(), getRate(), totalAssets(), or other same-transaction-sensitive read, either gate that read behind an explicit safe-read surface or refuse to grant same-block borrow authority at all.
  • Bound rounding residue and stealth-donation accumulation across every deposit, mint, withdraw, redeem, repay, liquidation, and fee-accrual path; do not let repeated dust become a user-owned issuance rail.
  • Add monitors for supply near zero, share price outpacing plausible strategy yield, unexpected backing delta, and dominant-holder concentration so the system notices when one actor is close to owning share truth.
  • Define a distress playbook: what pauses, haircuts, re-recognition steps, or recapitalization actions happen when share truth is suspected to be attacker-authored.

Audit prompts

  • Which exact code paths can increase the numerator behind share value without minting proportional shares or without passing through explicit recognition?
  • What invariant distinguishes assets physically here from assets economically backing redeemable shares, and where is that invariant enforced?
  • Can a live system be pushed back into totalSupply == 0, near-zero supply, or equivalent bootstrap-sensitive state after launch?
  • Are previewDeposit, previewRedeem, convertToAssets, balanceOf, liquidation valuation, and actual settlement guaranteed to consume the same or intentionally different truth objects?
  • Who can trigger harvest, sync, cache publication, rebasing-index updates, reward settlement, or rescue bookkeeping, and can those writes be timed around downstream collateral or redemption consumers?
  • If balances are transferable, what exact check proves a transfer cannot duplicate, strand, or reopen fee debt, reward debt, withdrawal rights, or other reserve-backed entitlement attached to the share history?
  • If a wrapper share is used as collateral elsewhere, what independent guardrail limits the damage from a sudden locally authored exchange-rate jump?
  • Can rounding or fee behavior create repeated stealth donations that compound into canonical share value rather than bounded one-off dust loss?
  • If an attacker controls most surviving shares during a thin-supply period, what prevents them from converting off-path backing growth into immediate borrow or redemption authority?
  • When distressed recovery happens, what exact object re-establishes the new capitalization table, and why can the next ordinary user flow not accidentally become that object?
  • If the protocol’s answer to a 10x share-price jump is that should never happen, what code actually enforces that claim?

Lessons that should already be standard

  • A vault share is not just ERC-20 balance plus math. It is a claim on a particular recognized-backing policy, supply-state policy, and downstream honoring policy.
  • Donation resistance is not a narrow vault trick. It is part of a broader rule that unexpected balance changes should not silently become redeemable or borrowable truth.
  • Low supply is a live risk state, not a historical deployment detail. If the system can revisit it, the system still owns the bootstrap problem.
  • Readable wrapper math is not yet canonical accounting truth, and canonical accounting truth is not yet immediate redemption, borrow, or liquidation authority. Healthy systems keep both promotion steps explicit.
  • Presentation functions are inside the security boundary once any other module treats them as protocol accounting or solvency truth.
  • If a share balance carries live economic entitlement, moving the balance is already moving the claim. Transfer semantics belong inside the same security review scope as mint, redeem, harvest, and settle.
  • Wrapper collateral is oracle risk wearing accounting clothes. The exploit becomes real when a locally printable share mark is first canonized by the protocol and then honored somewhere else as globally valid wealth.
  • Wrapper layers do not invent new safe-read surfaces. If the wrapper still resolves to an upstream callback-window or same-block-sensitive mark, the upstream venue is still authoring solvency truth for the whole stack.
  • Whoever can publish or recognize backing changes is part of the custody model, even if the function was added for gas efficiency, reward sync, or operational convenience.
  • The safest vaults can explain, at any moment, why current backing exists, why current share supply is fair, and which downstream consumers are entitled to trust that answer.

How to use this note with the exploit corpus

Internal linkages

Control surface

Graph View

Backlinks