Cowrie Research

exit-right-provenance-binding

15 min read

Exit-Right Provenance Binding / No Ambient Internal Balance Trust

  • Name: exit-right provenance binding / no ambient internal balance trust
  • Category: settlement reference / redemption-boundary checklist / withdrawal-solvency note / cashability provenance reference
  • Summary: Healthy protocols do not let internal balances, shares, claims, notes, or bridge credits become cashable merely because they exist in state. The safer shape is that every withdrawal, redemption, release, or claim path can point back to one backing-proven creation path for the exact right it honors. The recurring review mistake this note tries to stop is flattening three different cashability promotions into one vague the balance exists fact: some internal state or claim object exists, that state deserves to count as a backed redeemable right, and that accepted right deserves routine withdrawal, redemption, release, or claim authority right now. This note exists to make that downstream why is this balance actually cashable? layer more explicit than the broader proof effect truth and effect-ledger commitment notes, and to give the corpus a cleaner positive-design answer to incidents where ordinary exits later cash out state that should never have counted as real value.
  • Why this note exists:
    • Many systems are careful at creation time but dangerously trusting at exit time: once some internal state exists, later withdrawal code treats it as self-authenticating.
    • Exploits often do not need the final redemption path to be complicated. They only need one earlier path to create state whose provenance the exit rail never re-checks.
    • The reusable analytical question is often narrower than was the balance-sheet logic sound? and sharper than was the withdrawal function buggy?: what exact provenance makes this state redeemable for real assets?

What this note is trying to preserve

  • A withdrawable balance is not economically real just because protocol storage says it exists.
  • A healthy system keeps credit creation, backing event, and cash-out authority tied to the same security object or to tightly coupled objects whose equivalence is enforced.
  • The exit rail should inherit that provenance directly, not rely on a social assumption that earlier code must have created the balance correctly.

Three cashability promotions healthy exit systems should not collapse

  1. Some internal state or claim object exists

    • A balance slot is nonzero, a share supply increased, a claim leaf was recorded, a bridge credit was posted, or a note became visible in protocol state.
    • This is only the existence question: there is some state-shaped object the protocol might later honor.

  2. That state deserves to count as a backed redeemable right

    • The system still needs to prove the state came from one backing-valid creation path: deposited assets arrived, liabilities were burned, a bridge message was authentic and unspent, or a settled effect row already fused credit and backing.
    • This is the redeemability-truth question: this right is not just present, it is economically legitimate.

  3. That accepted right deserves downstream exit authority right now

    • Even a legitimately created right may still need one-time-use checks, quarantine, maturity, bridge-route consumption, rate limits, or other final authority gates before ordinary withdrawal, redemption, release, or claim code should pay it out.
    • This is the cash-out question: why is this proven right allowed to move real assets through this exit rail here and now?

Healthy systems keep those promotions explicit instead of collapsing them into the balance exists, so withdrawal is fine.

The four joints a healthy exit path should keep fused

  1. Cashable state and its creation provenance

    • Any balance, note, share, claim ticket, or bridge credit that can later release value should carry or point back to the exact creation path that made it valid.
    • This balance exists is weaker than this balance exists because the backing event already happened under the same trusted object.

  2. Backing-side evidence

    • The creation path for a cashable right should already have established the conserved source of value: deposited asset, consumed liability, burned wrapper, settled effect row, or authenticated bridge message.
    • If the backing event lives in a different object than the later redeemed right, the system is already asking operators or users to trust a hidden equivalence.

  3. Exit-side consumption rules

    • The withdrawal or redemption path should consume the same right whose creation provenance was proven, not a looser ambient balance that merely correlates with it.
    • A clean design spends a note, burns a share, consumes a claim leaf, nullifies a message, or debits a balance whose backed creation path is already known safe.

  4. No sibling path with weaker provenance

    • Standards, helpers, migration flows, and admin convenience routes should not let one public path mint or mark cashable state without the same provenance checks the main path enforces.
    • If deposit() proves backing but mint(), migrate(), claim(), or a batch helper can create equivalent redeemable state through a weaker path, the exit rail is only as sound as the weakest creator.

What sound design looks like

  • Cashability authority stays staged rather than collapsing into one balance fact.
    • The design should keep state exists, state counts as a backed redeemable right, and that right deserves exit authority now as separate promotions with explicit checks and provenance at each step.
    • The fastest way to hide an exit-provenance bug is to narrate all three promotions as one the balance is there observation.
  • Exit rails distrust naked internal balances.
    • Withdrawal, redemption, and bridge-release code should assume state may have been created incorrectly unless its provenance is already machine-checkable.
  • Creation and cash-out talk about the same object.
    • The redeemed right should be the same note, share, leaf, message, or balance object whose creation path already proved backing.
  • Backing proof happens before cashability.
    • Systems are healthier when state cannot become withdrawable first and reconciled later only by convention.
  • Sibling entrypoints share one provenance boundary.
    • All public ways to create an economically equivalent right should pass through the same backing checks or through strictly stronger ones.
  • Emergency accounting does not widen provenance.
    • Recovery, replay, migration, and batch-settlement helpers should preserve or narrow the proof required for cashability, not create softer shadow balances that ordinary exits later honor.

Useful positive design shapes

1. Note- or leaf-based exits

  • Systems that make withdrawals consume an explicit committed note, claim leaf, or message nullifier are easier to reason about than systems that later trust an ambient running balance.
  • The reusable point is not use Merkle trees; it is make the cash-out path spend one object whose backed creation is already committed.

2. Shares whose mint and burn paths share one backing boundary

  • Vault and wrapper systems are healthier when every share-creating entrypoint enforces the same asset-intake proof before the resulting share can later be burned for assets.
  • This is the positive-design answer to ERC-4626-shaped incidents where one sibling path quietly creates redeemable shares without moving assets.

3. Bridge exits keyed to one authenticated message object

  • Bridge release paths are healthier when they consume the exact authenticated deposit / burn / message object whose provenance already proved canonical source, custody change, asset identity, and one-time use.
  • The bad smell is release because local credit exists; the healthier shape is release because this authenticated, unspent bridge right exists.

4. Settlement systems that make credit creation provenance reachable at exit time

  • Proof systems, rollups, and batch processors are healthier when later exits can still point back to the committed effect object or another tightly bound creation record that already fused credit and backing.
  • If ordinary exits only see a local balance map while the proof / settlement details live elsewhere, the system is depending on invisible history.

5. Residual-service exits with sidecar redeemability inventories

  • Deprecated systems, bridge wrappers, and migration-era exit rails are healthier when they inventory not only headline balances but also every wrapper, sidecar, and route-local unwind right that old internal credit can still monetize.
  • The practical design target is that a residual exit path can still answer what exact backing-proven right is this cashing out, on which route, and through which remaining redemption surface? before ambient internal balance reaches another bridge, wrapper, or adapter that can turn it back into liquid assets.
  • This is the positive-design answer to Aztec Connect’s second-wave lesson: after the obvious reserves were gone, old internal balances could still reach wa2*, wcDAI, TB-*, and similar sidecars whose external redeemability kept the exit surface wider than the naive token inventory.

Design questions worth asking first

  • What exact object makes this balance, note, share, or claim redeemable for real assets?
  • Does the exit path consume that same object, or only a looser ambient balance derived from it?
  • Where was the backing event for this right established, and is that evidence still bound to the redeemed object?
  • Can a sibling entrypoint create an economically equivalent right without passing through the same backing checks?
  • If one internal balance were created by a subset bug, migration bug, or helper-path omission, would the ordinary exit rail still cash it out?
  • Is the system relying on that state could only have been created safely as folklore rather than as an enforced invariant?

Red flags

  • Withdrawals are simple; the complex checks already happened earlier
  • This balance is in protocol state, so it must be real
  • Only one entrypoint is supposed to mint this right
  • The bridge / rollup / vault keeps an internal credit first and reconciles the backing later
  • The main path checks asset movement, but this helper path creates equivalent shares / claims more efficiently
  • Exit code does not need to know provenance because upstream accounting guarantees it

Failure-prevention checklist

  • Review three separate promotions every time: some internal state exists, that state already counts as a backed redeemable right, and that right still deserves this exit authority now. Healthy systems prove all three instead of assuming one implies the next.
  • Define the cashable object explicitly. Reviewers should be able to point to the exact note, share, claim leaf, bridge message, or balance unit whose creation event makes later withdrawal legitimate.
  • Make every cash-out path consume or debit that same provenance-bearing object, not a looser ambient balance that merely correlates with it after the fact.
  • Keep creation-side backing checks mandatory across sibling entrypoints. deposit, mint, claim, migrate, settle, admin recovery helpers, and batch verbs should all preserve the same or a stricter proof of backing before equivalent exit rights exist.
  • Refuse credit now, reconcile later for anything that can become redeemable value. If deferred reconciliation is unavoidable, quarantine the resulting state from ordinary withdrawal, collateral use, transferability, and bridge release until backing is finalized.
  • Keep bridge, rollup, and vault exits provenance-aware. A release path should know which authenticated message, settled effect row, or asset-backed share it is honoring rather than trusting local credit in the abstract.
  • Treat migration and emergency repair code as custody code. Replay tools, debt socialization, recaps, airdrop claims, and recovery batches should narrow provenance requirements or preserve them exactly, never create a softer shadow balance that routine exits later honor.
  • Add explicit equivalence tests across sibling creation and exit paths: no backed creation path exists without cashability and no cashability exists without a backed creation path.
  • Instrument reconciliations that compare outstanding redeemable liabilities against the backing events that supposedly created them. If the system cannot explain why a liability is cashable, the liability should not be treated as money-good.
  • Inventory residual sidecars explicitly. Wrapper receipts, bridge adapter balances, migration helper positions, pending unwind rights, and route-local redeemability should stay on the same liability sheet as obvious token balances if old internal credit can still cash them out.
  • Require one audit artifact that states the invariant plainly: every redeemable unit in state can trace to one consumed backing event under the same trusted object or an explicitly enforced equivalent object.
  • Re-run those provenance checks during upgrades, standard-library changes, migration launches, bridge adapter swaps, and new batch-helper deployments. Exit rails often stay unchanged while the weaker sibling creator is introduced elsewhere.

Audit prompts

  • What exact object makes this state redeemable for real assets, and where is that object created?
  • When an exit succeeds, what exact earlier backing event does it point to: deposited asset, burned liability, consumed claim leaf, authenticated bridge message, or settled proof effect?
  • Does the exit path consume that same object, or does it merely debit a local balance bucket that could have been reached through multiple unequal creation paths?
  • Can any sibling verb create an economically equivalent right while skipping one intake, burn, identity, or one-time-use check the main path enforces?
  • If a migration, batch helper, or admin recovery path minted one bad unit of internal state, would an ordinary user exit later cash it out without noticing the provenance gap?
  • Are there any balances marked pending, internal, wrapped, bridge credit, claimable, or virtual that can quietly cross into ordinary redemption without a second provenance gate?
  • During incident response, where is the kill switch that can freeze or quarantine suspect internally created balances before routine exit flows monetize them?
  • Can monitoring explain, per liability class, which backing events still remain unconsumed and which outstanding exit rights they support?
  • After the obvious reserves are gone, which wrapper sidecars, bridge adapters, migration helper positions, or route-local redemption paths can still monetize the same internal credit through a second exit surface?
  • Does the protocol rely anywhere on only this entrypoint can create that balance as an assumption rather than a mechanically enforced invariant?
  • If the answer to why is this redeemable? is a story about upstream code rather than a machine-checkable object, what concrete design change would eliminate that ambient trust?

Lessons that should already be standard

  • Internal state is not economic truth by itself. Balances become money-good only when the system can still point to the backing event that made them legitimate.
  • Exit review should keep three questions separate: does this state exist?, is it a backed redeemable right?, and does it deserve this exact withdrawal or release authority now? Most cashability bugs hide in the step reviewers skipped.
  • Exit simplicity is not safety. The simplest withdrawal function in the world is dangerous if it honors ambient balances created by a weaker sibling path.
  • Shared economic rights need one shared provenance boundary. Multiple public verbs may exist, but they should not produce cashable state under different backing standards.
  • Deferred reconciliation is a quarantine problem, not a bookkeeping convenience. If backing is not final, the resulting state should not already behave like real collateral or withdrawable cash.
  • Emergency or migration tooling is part of the liability surface. Users eventually meet those balances through ordinary exits, so admin-only helper is not a reason to relax provenance discipline.
  • The healthiest systems make why is this redeemable? answerable with one object and one backing story, not with folklore about which earlier code path must have run.

How to use this note with the exploit corpus

Internal linkages

Control surface

Graph View

Backlinks