Cowrie Research

bridge-route-local-redeemability-domain-discipline

16 min read

Bridge Route-Local Redeemability Domain Discipline

  • Name: bridge route-local redeemability domain discipline
  • Category: bridge reference / route-segregation design / asset-identity checklist / custody-domain discipline
  • Summary: Healthy bridges do not let one asset label, denom string, wrapper ticker, or nominal token identity silently collapse multiple routes into one redeemable balance sheet. They bind every mintable or withdrawable representation to the exact route, channel, peer, custody bucket, or issuer authority that actually backs it. If two routes carry the same nominal asset, the safe default is that they remain different redeemability domains until the bridge can prove they share the same backing object and can survive one route failing without socializing loss into the other. Review this family as three separate promotions rather than one vague same asset moment: a route- or asset-shaped object exists, that object is promoted into canonical membership in one redeemability domain, and that accepted membership is then allowed to inherit live mint / release / reserve authority.
  • Why this note exists:
    • Bridge deposit truth binding explains that a bridge must keep one canonical deposit security object intact from source-side custody change through destination-side mint or release.
    • Bridge source-provenance bundle and authoring-surface discipline explains that the right contract, channel, endpoint, and handler must be the ones allowed to author bridge truth.
    • Bridges also need a narrower design note for the follow-up question those two notes expose: when are two routes actually allowed to share one redeemable asset identity?
    • Axelar is the clean wrong channel inherited the same wrapper and escrow bucket exemplar.
    • Gravity Bridge is the clean new asset identity inherited an existing destination reserve exemplar.
    • The shared design question is the same in both cases: what exact proof says this route, channel, denom, or wrapper namespace is entitled to the balance sheet it is trying to touch?

Two preserved failure shapes worth comparing

1. Wrong-route fungibility collapse

  • Axelar is the clean channel-local case.
  • The bridge let same bare denom outrank same channel + same escrow bucket, so packets from attacker channel-227 minted the same saUSDT, saUSDC, saWETH, and other wrappers that the real Axelar lane later redeemed.
  • The healthy-side question is: why did one wrong channel get to join an existing redeemability domain at all?

2. New-asset reserve inheritance collapse

  • Gravity Bridge is the clean registry-mediated case.
  • The bridge let a freshly attacker-authored Cosmos-side asset identity inherit the destination-reserve semantics of real USDC, USDT, WETH, and PAXG once DenomToERC20Lookup was poisoned.
  • The healthy-side question is: why did asset discovered and existing reserve now redeemable collapse into the same state transition?

Secret and Gravity differ in mechanics, but they fail the same deeper design rule: same-looking metadata, same wrapper name, same denom text, or same registry namespace should not be enough to merge liabilities. The merge needs explicit proof and route-local containment.

Three redeemability-domain promotions reviewers should not collapse

  1. Some route- or asset-shaped object exists
    • A packet arrived on some channel, a peer was configured, a denom mapped cleanly, a wrapper already existed, or a registry entry looked familiar.
    • This is only the object exists somewhere in the bridge stage. It does not yet prove that the route belongs to any high-value redeemability domain.
  2. That object is promoted into canonical domain membership
    • This is the Secret / Axelar and Gravity question.
    • The dangerous jump is not just the bridge saw a familiar asset, but the bridge decided this exact channel, route, denom, or registry-authored identity counts as one of the canonical members allowed to share an existing balance sheet.
    • Healthy bridges demand explicit issuer, escrow, peer, or reserve-equivalence proof before making that promotion.
  3. That accepted domain membership inherits live reserve authority
    • Even after a route is admitted, the bridge still has to decide how much release, mint, withdrawal, or reserve-sharing authority that route receives right now.
    • A route that barely proved compatibility should not instantly inherit the same live reserve reach, daily throughput, or failure blast radius as the longest-standing canonical lane.

Healthy route-segregation design keeps all three steps separate. Most failures in this family happened because teams let familiar object exists, object counts as canonical member of the domain, and that accepted member may now touch the same reserve semantics collapse into one weak state transition.

The five joints a healthy route-local redeemability model should keep fused

  1. Canonical route or custody bucket

    • Every redeemable bridge liability should map to one explicit backing object: one escrow bucket, one burn authority, one issuer attestation lane, one peer-manager pair, one channel-local accounting bucket, or one equivalent route-local reserve.
    • Asset exists somewhere in the bridge is not enough. The system should be able to answer which exact route is backing this balance right now?

  2. Redeemability domain kept distinct from display identity

    • Symbol, denom text, wrapper name, and wallet presentation are not sufficient to decide fungibility.
    • Two routes can carry assets that look identical to users while still remaining different security objects until the bridge explicitly proves they share backing and failure domains.
    • USDC, uusdc, or saUSDC may be presentation labels; the real security question is which route and reserve those labels are allowed to draw from.

  3. Explicit merge authority rather than accidental aliasing

    • If a bridge wants multiple routes to share one representation, that merge needs an explicit authority story.
    • The system should prove why route A and route B are entitled to hit the same reserve semantics: same issuer-controlled mint authority, same canonical lockbox, same manager-scoped token, or another equally explicit basis.
    • A bridge is fragile if shared fungibility appears only because two paths happen to reuse the same denom string, resource ID, wrapper contract, or asset GUID.

  4. Route-local liability tracking and reconciliation

    • Supply, mint caps, withdrawal caps, and reserve reconciliation should key off the same route-local identity object that defines redeemability.
    • If operators can only see aggregate saUSDC or aggregate USDC without knowing which route authored which liabilities, one poisoned route can hide inside apparently healthy total balances.
    • Healthy bridges can answer both how much of this representation exists? and which route or reserve is responsible for each slice of it?

  5. Route-local failure containment even when fungibility is intentionally shared

    • Some systems intentionally make different routes converge into one user-facing token.
    • Even then, one route should not automatically inherit unlimited balance-sheet reach into all shared reserves.
    • Route-local caps, queues, throttles, quarantines, and fast pauses should keep one bad route from instantly socializing losses across the whole representation.

What sound design looks like

  • Segregate by default, merge by proof
    • The safe default is new route -> new liability bucket.
    • A bridge should need explicit, reviewable logic to let that route share an existing redeemability domain.
  • Route identity is part of asset identity
    • Channel IDs, peer-manager bindings, domain pairs, source chains, and custody modes are part of what the asset means inside the bridge.
    • A route change is therefore an asset-identity change, not just a networking detail.
  • Shared representations need one clear authority story
    • If two routes mint or release the same representation, the bridge should be able to explain why they are equivalent in issuer authority, escrow backing, and failure domain.
    • They both carry USDC is not an authority story.
  • Destination release logic should spend from route-aware reserves
    • Release and mint logic should consume route-local liabilities, route-local quotas, or explicitly merged canonical reserves rather than any ambient pool attached to the display asset.
    • A route that was never entitled to a reserve should not gain that entitlement through wrapper reuse.
  • Monitoring should surface route drift early
    • Reconciliation, alerting, and dashboards should break balances down by route-local backing bucket and representation, not just by symbol.
    • Healthy operations can spot channel-227 authored liabilities that channel-69 is about to honor before a week passes.
  • Compatibility paths do not get free fungibility
    • Migrations, wrapper introductions, resource remaps, and route additions should begin life quarantined or separately represented until review proves they deserve canonical status.
    • Convenience features should not be allowed to redefine what balance sheet an asset can redeem from.
  • Containment sits underneath correctness
    • Even healthy route-segregation design should assume one wrong merge or wrong-channel liability may still land once.
    • Bridge bounded release design is the companion for making sure that single mistake cannot immediately reach the full reserve base.

Useful positive design shapes

1. Issuer-operated domain pairs with one mint authority per domain set

  • CCTP is useful because route admission is explicit and issuer-scoped: Circle decides which domains, attestation paths, and mint authorities are part of the live USDC mobility graph.
  • The design lesson is not that issuer control is always desirable. It is that shared redeemability across domains is explicit and tied to one authority boundary rather than emerging from metadata similarity.
  • When a new path joins, it joins because the issuer admits it, not because a bridge parser notices a familiar asset label.

2. Token-side bridge admission with per-bridge quotas

  • ERC-7281 is useful because the token issuer explicitly chooses which bridges may mint or burn and how much each may do.
  • That makes route membership in the token’s redeemability domain an allowlisted transition rather than a side effect of bridge-local alias tables.
  • The reusable lesson is that shared fungibility should be granted by explicit bridge admission, not by accidental wrapper or denom convergence.

3. Manager-scoped peers and per-lane throttles

  • Wormhole Native Token Transfers is useful because NttManager owns peer mappings, token accounting, and rate limits for one token deployment.
  • Different transceivers can exist underneath, but token movement still flows through manager-defined peers and lane-specific throughput policy.
  • The key design move is that route membership and route limits stay manager-scoped instead of dissolving into one ambient wrapped-asset bucket.

4. Channel-aware voucher handling and channel-local accounting

  • IBC-style token handling is healthy when denom trace, source channel, and per-channel escrow accounting stay fused.
  • Secret / Axelar is useful precisely because it shows what happens when parse_voucher_denom(...) and reduce_channel_balance(...) disappear: same-looking denoms from different channels collapse into one falsely shared redeemability domain.
  • The lesson is broader than IBC. Any bridge carrying the same nominal asset over multiple lanes needs route-local accounting that survives parser convenience and wrapper reuse.

Design questions worth asking first

  • What exact object defines redeemability for this representation: route ID, source domain, channel, peer, escrow bucket, issuer authority, token contract, or some combination?
  • If two routes both carry the same asset, what explicit proof says they are entitled to share one balance sheet instead of staying segregated?
  • Can a new route, channel, or peer start minting into an existing representation without a fresh reserve review or issuer admission step?
  • Are caps, monitoring, and reconciliations keyed by route-local identity or only by user-facing symbol and total supply?
  • If one route goes bad today, what concrete mechanism stops it from consuming the reserves or mint authority associated with the other routes sharing that representation?
  • During migrations or wrapper changes, when does a route stop being quarantined and start being treated as canonical?

Red flags that usually mean route-local redeemability is under-specified

  • Same symbol means same asset appears anywhere in the bridge’s trust story
  • multiple routes can mint the same representation because they share denom text, address formatting, or resource IDs rather than an explicit admission policy
  • monitoring tracks total wrapped supply per ticker but cannot attribute that supply to route-local backing buckets
  • route additions or channel changes do not force a review of reserve semantics, only of networking or operational readiness
  • wrong-channel packets, new peers, or helper routes hit the same mint or release surface as canonical traffic once they parse cleanly
  • destination release logic spends from one ambient reserve for all route variants of a token
  • new routes inherit the same limits and release authority as long-established canonical routes on day one
  • migrations, aliases, or wrapper introductions can silently collapse previously separate liabilities into one token without derecognition or pause options

Failure-prevention checklist

  • Define one canonical redeemability object per bridge liability: route or channel identity, source asset identity, custody mode, backing bucket, and destination representation.
  • Keep route identity inside that object all the way through registration, minting, release, monitoring, reconciliation, and cap logic. Do not let later handlers re-derive meaning from weaker metadata such as symbol, bare denom, or wrapper name.
  • Default new routes, peers, channels, and bridge integrations to isolated liability buckets, fresh wrappers, candidate status, or low-cap quarantine until explicit review proves they deserve shared redeemability.
  • Require an explicit authority story before merging routes into one representation: same issuer boundary, same lockbox, same canonical reserve, or another equally strong basis.
  • Key mint caps, withdrawal caps, and reserve reconciliations by route-local identity, not just by user-facing token name. Operators should be able to pause one route without freezing every unrelated route carrying a similar asset.
  • Spend from route-aware reserves or explicitly merged canonical reserves only. Do not let one route drain another route’s escrow because both map to the same wrapper contract or denom text.
  • Review resource remaps, denom allowlists, peer-map changes, wrapper reuse, route additions, channel migrations, and registry writes as balance-sheet changes. These operations can redefine who may touch an existing reserve.
  • Keep new asset discovered, new route admitted, and existing reserve now reachable as separate lifecycle states. Wrapper deployment, registry population, or metadata acceptance should not by themselves merge liabilities.
  • Keep fast route-local brakes beneath any intentionally shared representation: per-route queueing, rate limits, pause switches, delayed large withdrawals, and quarantine thresholds.
  • Reconcile liabilities against backing by route frequently enough to catch new route minted into old reserve failures before downstream lenders, AMMs, or exchanges absorb the counterfeit inventory.
  • Test adversarially for alias collapse: same symbol on different routes, wrong-channel packets, duplicate route bindings, helper-path wrapper reuse, and migrations that accidentally merge previously separate liability buckets.

Audit prompts

  • What exact tuple defines this representation’s redeemability domain, and which fields in that tuple can a user, relayer, or newly admitted route influence directly?
  • If the protocol says two routes are fungible, where is that equivalence proven and who is allowed to grant it?
  • Can any route addition, peer update, channel migration, denom remap, or registry write silently expand the reserves reachable by an existing wrapped asset?
  • Do release and mint handlers consume route-local balances, or could one route spend against whichever reserve happens to back the same display asset right now?
  • Are dashboards, alerts, and accounting broken down by route-local backing bucket, or would a poisoned route be visible only as a change in aggregate total supply?
  • If one route fails authenticity today, what stops already-issued liabilities from being redeemed through healthier routes that share the same representation?
  • Can wrapper or registry code accidentally merge liabilities from two routes that were supposed to stay separate?
  • What is the first state transition where a newly added route stops being isolated and starts being allowed to touch canonical reserves, and what review happens there?
  • If governance or issuers intentionally merge routes, how do they preserve rollback, derecognition, and route-specific pause options afterward?
  • During incident response, can operators freeze one route’s reach into a shared representation without shutting down every user-facing token that looks the same?

Lessons that should already be standard

  • A bridge asset is not just what token name users see; it is also which route and which reserve are allowed to stand behind that name. Route visibility is not route admission, and route admission is not yet unlimited reserve authority.
  • Shared wrapper contracts and shared symbols are UX conveniences, not proof that liabilities are genuinely fungible.
  • Route additions are balance-sheet changes. If a new channel can mint into an old representation, the bridge has widened reserve access whether or not any verifier code changed.
  • Monitoring by ticker is not enough. Operators need route-local liability views or they will discover counterfeit inventory only when a healthy route runs out of real backing.
  • The safest default is segregated liabilities with explicit merge authority later, not ambient fungibility first and forensic accounting later.
  • A healthy bridge can explain not only why a route is valid, but also why that route is entitled to the exact reserve semantics attached to a shared representation.
  • Wrong-channel or wrong-peer traffic is not merely a provenance bug. It is often a balance-sheet merging bug in disguise.
  • If one route failure can instantly reach all reserves behind a shared asset, the bridge treated route identity as metadata instead of as custody authority.

How to use this note with the exploit corpus

Internal linkages

Control surface

Graph View

Backlinks