Cowrie Research

reserve-backed-claim-truth-security-object

21 min read

Reserve-Backed Claim Truth as a Single Security Object

  • Name: reserve-backed claim truth as a single security object
  • Category: reserve-backed issuance reference / round-trip solvency checklist / mint-redeem boundary note / reserve-boundedness design reference
  • Summary: Healthy reserve-backed systems do not merely ask does minting work? and does redemption work? as two separate implementation questions. They keep one security object intact: the exact external value that entered, the exact claim quantity that may be created against it, the exact entrypoints allowed to create, move, or destroy that claim, the exact reserve pool that remains liable for redemption, and the exact bounds proving that an immediate round trip cannot extract more value than genuinely entered. Just as importantly, some asset effect landed is still not the same thing as the whole priced backing bundle arrived, and that is still not the same thing as this deployment is even allowed to treat that bundle as admissible reserve backing here. Only after those intake questions are answered should the protocol ask whether this path may mint a redeemable claim right now, and even then claim minted coherently here is still not the same thing as downstream markets should immediately honor it as money-good collateral or settlement truth. When a transferable balance also carries live fees, rewards, or reserve-backed withdrawal rights, even plain movement verbs belong inside that same security object. This note exists to make the positive design target explicit instead of leaving readers to reconstruct it only by inverting incidents like Truebit, Meta Pool mpETH, Cetus, Velocore, Fantasm, Bedrock, or Popsicle.
  • Why this note exists:
    • Many exploits in issuance-redemption-solvency-asymmetry look superficially different: unchecked arithmetic, inherited-standard misuse, fee-state corruption, wrong-chain mint paths, CLMM liquidity underquotes, or self-priced wrapper issuance that mistakes attacker-shaped execution for fair issue-side NAV.
    • The reusable positive-design question is the same across all of them: what exact object should have kept issuance-side cost and redemption-side liability fused together?
    • A protocol is already unsafe once one path can create a claim under weaker truth than the reserve-paying side later uses to honor that claim.
  • shared-standard entrypoint invariant drift is the narrower standards-surface companion when the sharper question is not generic reserve-bounded issuance, but which inherited or sibling public entrypoint still reaches a primitive whose backing proof moved elsewhere?
  • collateral-admission-lag-and-borrow-side-quarantine is the narrower downstream-solvency companion when the sharper follow-up is not could the protocol issue the claim safely at all?, but should that claim have become immediate borrowing or liquidation truth elsewhere?

Three review questions a healthy design should not collapse

  1. Did attributable, admissible external reserve value really enter?

  2. Did this exact path earn bounded claim-creation authority against that value?

  3. Should the newly created or newly moved claim become immediate downstream economic truth?

  • Healthy systems answer those three questions separately and in order. They do not let assets arrived silently imply claim may mint, they do not let claim minted silently imply every other module may now lend, liquidate, or settle against it, and they do not let claim transferred silently imply historical entitlement moved or reopened coherently unless that movement path was designed as part of the same reserve object.

The six joints a healthy reserve-backed claim should keep fused

  1. Canonical value intake

    • The system must know what exact external value really entered and may therefore justify new claim creation.
    • A transfer call returned, raw balance changed, msg.value was nonzero, or a quote looked cheap enough are not themselves reserve-backing proofs.
    • Healthy systems also keep three intake promotions separate: some token or native-asset effect happened, the whole priced backing bundle actually arrived, and this exact asset domain is admissible reserve backing on this deployment.
    • This is the joint that breaks in issuance-redemption-solvency-asymmetry cases like Meta Pool mpETH, ForceDAO xFORCE, Fantasm Finance XFTM, and Bedrock uniBTC.

  2. Canonical claim quantity

    • The same state that proves value intake must also bound how many redeemable claims can be minted, credited, or represented as liquidity.
    • If arithmetic, scaling, cached pricing, or fee-state corruption can inflate claim quantity while the reserve side stays real, the system has already split the object.
    • This is the joint that breaks in Truebit, Cetus, and Velocore.

  3. Entrypoint equivalence

    • Every public way to create, move, or reshape the claim should hit the same backing proof and the same issuance or entitlement bound.
    • deposit() being safe is not enough if mint(), a migration helper, a payable side path, a pool-local internal-looking verb, a legacy quote function, or a plain transfer()-family path that also moves live fee / reward / withdrawal rights can still affect the same liability object under weaker truth.
    • This is the joint that breaks whenever the protocol keeps the familiar claim surface but moves the real receipt, pricing, or entitlement invariant somewhere only some entrypoints respect.

  4. Reserve liability identity

    • The protocol must know which exact reserve pool, treasury, vault inventory, AMM reserves, or redemption bucket remains liable for the claim.
    • Healthy designs do not let one path mint claims against a fiction while another path still cashes them out against a different, more conservative notion of reserve reality.
    • xToken xSNXa is the useful wrapper-side reminder: the issue path treated attacker-shaped routed execution as if it defined fair SNX contribution, while burn and Balancer exits still reached firmer reserve or market-liability rails.
    • This is why CLMM liquidity-overmint cases belong in the same family as token mint/burn exploits: the claim may be LP liquidity or position value rather than a fungible token, but the reserve-paying side still exists.

  5. Immediate round-trip boundedness

    • The system needs a stronger invariant than buy logic seems plausible and sell logic seems plausible.
    • It needs the same-state inequality that an immediate issue -> redeem, buy -> sell, or add-liquidity -> remove-liquidity loop cannot return more reserve value than actually entered, once explicit fees and tolerated rounding are applied.
    • This is the joint that breaks when intentional spread, convexity, fees, or stateful pool math are reviewed locally rather than as one reserve-bounded round trip.

  6. Lifecycle and residual-surface discipline

    • A reserve-backed claim stays dangerous as long as any old contract, old library, stale entrypoint, or deployment-surface-specific mint path can still create liabilities against live reserves.
    • Age, low usage, UI retirement, or social deprecation are not safety controls.
    • This is the joint that keeps long-lived reserve contracts like Truebit interesting years after active maintenance faded.

What sound design looks like

  • One external value proof, one bounded claim creation

    • The same event that proves new value entered should be the one that authorizes the exact amount of new claim exposure.
    • But the protocol should still say that second step out loud: receipt proof is not self-executing mint authority unless the path explicitly binds that receipt to one bounded claim-creation rule.
    • Healthy issuance paths also keep the intake ladder explicit before mint authority appears at all: some effect landed is weaker than the whole priced backing bundle arrived, and that is still weaker than this deployment is allowed to treat that bundle as reserve backing for this claim family.
    • If the protocol infers reserve backing from a weaker surrogate than the redemption side later trusts, it is already relying on folklore.

  • Every claim-creating entrypoint should hit the same receipt and pricing boundary

    • Safe designs do not depend on humans remembering which public verb is the real one.
    • If several entrypoints can reach claim creation, they should all prove asset receipt, pricing safety, and issuance bounds themselves or be hard-disabled.

  • Arithmetic and scaling are part of the custody boundary

    • Wide-integer helpers, fee multipliers, cached quote math, decimal conversions, previews, and final composed numerators are not harmless utilities.
    • Once they help decide claim quantity against a real reserve, they are custody-critical state.

  • Quote helpers and previews are already payment-certification logic once minting trusts them

    • A previewMint, getPurchasePrice, liquidity quote, or internal pricing helper does not stay informational if one live path treats its output as sufficient proof that the user paid enough.
    • The exact function that says this much value buys this much claim is already part of reserve truth, even if the codebase labels it as a helper.
    • Healthy designs either keep preview and settlement math identical or prove that any looser preview can never expand claim quantity beyond what the reserve-paying side will later honor.

  • Reserve liability should be explicit and localizable

    • The protocol should be able to answer which reserve pays this claim? before the claim is created, not only after redemption time.
    • If claim creation and reserve payout consult different states, assets, scales, or trust assumptions, the solvency object is already split.

  • Claim movement should stay inside the same entitlement boundary when balances are transferable

    • If a share or receipt token carries pending fees, reward debt, or another reserve-backed withdrawal right, then transfer() and transferFrom() are not mere UX plumbing.
    • Healthy designs either move that live entitlement coherently with the balance, settle it exactly once before movement, or fail closed.
    • Plain balance movement is not a permission to reopen historical reward or reserve rights under weaker truth.

  • Immediate round trips should fail closed under extreme states

    • Security cannot rely on the claim surface only being used by ordinary trade sizes, ordinary tick ranges, or ordinary fee values.
    • The path should stay reserve-bounded at max-size inputs, low-liquidity states, dust states, same-block repeated execution, and deployment-specific edge conditions.

Useful positive design shapes

1. A single backing proof shared across issuance verbs

  • The clean design target is that deposit, mint, migration, liquidity-add, and any internal helper that creates the same liability all hit one shared proof of value intake and one shared claim-bound check.
  • Meta Pool mpETH is the clean contrast case because the ERC-4626-looking surface survived after the receipt proof moved.

2. Round-trip reserve-boundedness tests, not just local formula review

  • The protocol should test issue then redeem immediately and buy then sell immediately under the same state snapshot, including extreme values and adversarial sequencing.
  • Truebit is the clean reminder that a curve can look fine until the final unchecked composition step turns the round trip into a reserve drain.

3. Quote helpers, previews, and final composition steps reviewed as custody truth

  • The decisive reserve boundary is often not the external mint function body but the helper it trusts to certify price, quantity, or required payment.
  • If a preview, quote, or final numerator/denominator assembly says this much claim is now earned, reviewers should treat that function as reserve-authorization logic even when the codebase presents it as UX support or reusable math.
  • Truebit is the canonical reminder that the last composed arithmetic step can be the real custody boundary.

4. Claim-creation math treated as a live solvency surface

  • CLMM liquidity quotes, fee multipliers, price conversions, or wrapper-scale math should be reviewed as issuance logic, not as mere accounting details.
  • Cetus and Velocore are useful because they make the same point in AMM form: undercharging a liquidity claim is still claim issuance under fiction.

5. Bundle completeness and asset-domain admission proved before mint authority

  • A reserve-backed issuer should prove not only that one payment component landed, but that the whole priced backing bundle landed on a deployment surface where that bundle is even allowed to count as reserve truth.
  • msg.value arrived, one token burn succeeded, or one wrapper receipt exists are still weaker than the exact reserve package this claim price assumed is now present and admissible here.
  • Fantasm Finance XFTM is the clean bundle-completeness reminder, and Bedrock uniBTC is the clean asset-domain reminder.

6. Deployment-surface-specific mint paths either proved safe everywhere or disabled elsewhere

  • If a claim surface behaves differently across chains, asset wrappers, or execution environments, the unsafe paths should be removed rather than left socially unsupported.
  • Bedrock uniBTC is the clean contrast case because the mint path only made sense on a different chain surface.

7. Transfer mobility reviewed as reserve-backed claim movement when balances carry live entitlement

  • If the claim is transferable and the balance itself carries pending fees, reward debt, reserve-backed withdrawal rights, or another economically live state, then token mobility is part of the same solvency surface.
  • A pure transfer should not mint new entitlement, preserve old entitlement for the sender while also opening it for the receiver, or let the same claim cash out twice through later withdrawal paths.
  • Popsicle Finance Sorbetto Fragola PLP is the clean reminder that moving a balance can still move — or fail to move — a reserve-backed economic right.

8. Residual reserve contracts treated like production until emptied or extinguished

  • A reserve-holding contract is live as long as it can still issue or redeem claims.
  • Nobody uses this anymore is not a solvency invariant.
  • Truebit is again the canonical reminder.

Design questions worth asking first

  • What exact event proves fresh external value really entered the reserve?
  • Which exact entrypoints can create the same economic claim, directly or indirectly?
  • Do all of those entrypoints enforce the same receipt proof and claim-bound check?
  • What arithmetic helpers, scaling constants, fee states, or cache writes decide claim quantity?
  • Which reserve pool or treasury is liable for redemption, and does issuance consult the same notion of value?
  • If the claim is transferable, does pure balance movement also move fee, reward, or withdrawal entitlement, and is that movement explicitly conserved?
  • Can an immediate same-state round trip ever return more value than entered?
  • Are any legacy or chain-specific entrypoints still live against meaningful reserves?

Red flags that usually mean reserve-backed claim truth has already split

  • The transfer succeeded, so the assets must have arrived
  • Only one public mint path matters while sibling standards entrypoints or internal-looking pool verbs still create the same liability
  • The spread is large enough that local math bugs should not matter
  • This helper only affects quotes / fees / scaling even though downstream claim quantity depends on it
  • That deployment path is only for another chain while the function remains callable here
  • The old reserve contract is dormant while it still holds assets and exposes issuance or redemption logic

Failure-prevention checklist

  • Define one canonical proof of reserve intake for every claim-creating surface. ERC-4626 deposit/mint, pool buy/sell, liquidity-add helpers, migration paths, payable wrappers, and chain-specific bridges or native-asset adapters should all either consume the same receipt proof or fail closed.
  • Keep the intake ladder explicit before claim creation: some asset effect happened, the whole priced backing bundle arrived, and this deployment / asset domain may treat that bundle as reserve backing here are different gates, not one vague payment succeeded conclusion.
  • Write down the handoff from value entered to claim may now exist explicitly. A measured receipt, successful conversion, or observed balance increase should not silently become mint authority without one bounded claim-creation rule that names the liable reserve bucket.
  • Keep claim-quantity math inside the same custody boundary as reserve receipt. Decimal scaling, quote composition, previews, fee multipliers, tick math, liquidity estimators, and final numerator/denominator assembly should be reviewed as solvency code, not as harmless pricing utilities.
  • Treat quote helpers and previews as payment-certification surfaces when live minting or liquidity-add paths trust them. If a helper says how much the user must pay or how much claim they earn, its final composed output needs the same review rigor as the external function that consumes it.
  • If transferable balances also carry live fee, reward, or withdrawal rights, treat transfer()-family paths as part of the reserve-backed claim surface. Movement should either carry entitlement coherently, settle it exactly once before movement, or fail closed.
  • Prove immediate round-trip boundedness under one state snapshot. Test issue -> redeem, buy -> sell, and add-liquidity -> remove-liquidity loops across max-size inputs, thin liquidity, dust reserves, unusual fee settings, and repeated same-block execution.
  • Treat every economically equivalent public verb as live issuance authority. If a protocol supports sibling standard entrypoints, legacy verbs, migration helpers, rescue paths, or deployment-specific wrappers, remove the unsafe ones rather than relying on UI guidance or social deprecation.
  • Make reserve liability identity explicit before claim creation. The code should be able to answer which exact pool, vault inventory, treasury bucket, or AMM reserve is paying the claim, and issuance should consult that same notion of value rather than a looser surrogate.
  • Distinguish raw balance movement from attributable reserve backing. msg.value, balanceOf, wrapper receipts, callback-side transfers, or internal inventory changes should not all silently share one meaning unless the protocol truly intends every one of them to authorize liability creation.
  • Add explicit chain-surface and asset-surface invariants. If a mint path only makes sense for ERC-20 assets, one native-asset environment, one bridge domain, or one wrapper family, encode that restriction directly instead of assuming operators will avoid the wrong deployment context.
  • Treat residual or deprecated reserve contracts as production until authority and value are actually extinguished. Emptying reserves, revoking issuance rights, disabling legacy entrypoints, and proving no live redemption bucket remains should be part of decommissioning, not implied by low usage.
  • Monitor the fused joints directly: unexpected claim growth without matching reserve intake, reserve-liability bucket drift, sudden low-cost round trips, and disagreement between issuance-side receipt proof and redemption-side payout logic.
  • Add release gates that specifically replay known family shapes: missing transfer validation, unchecked final quote composition, liquidity overmint from truncation or overflow, legacy sibling entrypoints, and chain-specific mint paths that skip one receipt or conversion step.

Audit prompts

  • What exact event proves fresh external value entered the reserve, and which code paths are allowed to treat that event as claim-backing truth?
  • Where does the protocol distinguish some asset effect happened, the whole priced backing bundle arrived, and this deployment is even allowed to count that bundle as admissible reserve backing for this claim?
  • Once that event exists, what exact rule turns it into bounded claim-creation authority rather than merely assets are now somewhere inside the system?
  • Do all economically equivalent claim-creating entrypoints enforce the same receipt proof, issuance bound, and reserve-liability identity, or are some still reaching older logic or deployment-specific shortcuts?
  • Which arithmetic helpers, fee states, decimal conversions, previews, quote builders, or liquidity estimators decide claim quantity, and have they been reviewed as custody-critical rather than informational math?
  • Which exact helper output is treated as a payment certificate for minting or liquidity issuance, and does its final composed step still preserve the same reserve bound the redemption side later honors?
  • If balances are transferable, what exact check proves a pure transfer cannot reopen historical reward, fee, or withdrawal entitlement or move the claim without moving its consumed-state boundary too?
  • If a user issued and immediately redeemed under the same state, what explicit inequality proves the protocol cannot pay out more reserve value than entered after fees and tolerated rounding?
  • Where can raw balance changes, callback-delivered funds, wrapper conversions, or native-asset handling create the appearance of backing without the same attributable intake proof the redemption side later trusts?
  • Which reserve bucket actually pays this claim, and can issuance ever consult a different asset, scale, cache, or trust assumption than redemption does?
  • Are there any legacy contracts, deprecated verbs, migration helpers, sibling standards surfaces, or wrong-chain deployments that can still create liabilities against live reserves?
  • If the main issuance path were paused tomorrow, what other callable surface could still mint, quote, or represent the same economic claim under weaker truth?
  • What happens at dust states, max-size trades, extreme fee values, near-empty liquidity, or same-block repeated execution? Does the round trip stay reserve-bounded there too?
  • If this protocol lost money through one reserve-backed claim bug tomorrow, which joint would have failed first: intake proof, claim quantity, entrypoint equivalence, reserve-liability identity, round-trip boundedness, or lifecycle discipline?

Lessons that should already be standard

  • Reserve-backed systems fail as one object, not as separate mint bug and redeem bug anecdotes. If issuance-side truth and redemption-side liability do not consult the same proof, solvency is already folklore.
  • Some asset effect landed is not yet the same thing as the whole priced backing bundle arrived, and that is still not the same thing as this deployment may treat that bundle as admissible reserve backing here.
  • Real assets arrived is not yet the same thing as a redeemable claim may be created right now, and claim created coherently here is not yet the same thing as downstream modules should immediately extend borrow, liquidation, or settlement authority against it.
  • Economically equivalent entrypoints are equivalent security authority. A sibling ERC-4626 verb, migration helper, pool-local function, or chain-specific wrapper is enough to break the reserve boundary even when the main happy path looks correct.
  • Quote math is custody math once it determines how much redeemable claim leaves the contract. Overflow, truncation, previews, final composition, scaling, and fee composition belong inside the solvency review scope.
  • A helper stops being just a preview the moment live minting trusts it as sufficient payment truth. Labels like view, preview, or quote do not reduce custody significance.
  • If a transferable balance carries live economic rights, plain movement is already part of reserve truth. transfer() is not neutral plumbing once sender and receiver entitlement can diverge from the same reserve-backed claim.
  • Immediate round-trip tests catch failures that local function review misses. A protocol can look plausible on the buy side and on the sell side while still paying out more value than entered when both paths compose.
  • Deployment context is part of the security boundary. A path designed for one asset model, one chain surface, or one wrapper family should not remain callable everywhere else just because the ABI matches.
  • Deprecated reserve contracts stay dangerous until value and authority are both gone. Low usage, old branding, or front-end retirement does not deauthorize a live reserve bucket.
  • Transfer succeeded is not a reserve proof by itself. Receipt validation, attributable intake, and reserve-liability identity need to be explicit if the system is going to mint against them.
  • Whoever can preserve or reactivate a stale issuance surface controls live solvency, even if that surface survives only for compatibility, migration convenience, or forgotten historical reasons.

How to use this note with the exploit corpus

Internal linkages

Control surface

Graph View

Backlinks