Cowrie Research

asset-identity-registry-poisoning

15 min read

Asset-Identity Registry Poisoning / Denomination Aliasing

  • Name: asset-identity registry poisoning / denomination aliasing
  • Category: exploit pattern / bridge security failure / asset-identity failure / metadata-trust failure / registry poisoning
  • Summary: Some bridges treat token-registration tables, denom mappings, symbol metadata, or other asset-identity registries as if they were harmless bookkeeping. They are not. Those registries decide which destination-side custody asset a source-side denomination is allowed to claim. If an attacker can poison that mapping, honest relayers, validators, and batch verifiers can all keep behaving correctly while the bridge releases the wrong asset. The exploit is not forged signatures; it is authentic signatures over a registry that already lies about what asset identity means. Gravity Bridge is the clean preserved exemplar: honest validators later signed ordinary outgoing batches only because deployERC20() plus handleErc20Deployed had already taught DenomToERC20Lookup that worthless Cosmos-side denoms redeemed real USDC, USDT, WETH, and PAXG custody.
  • What it is:
    • A bridge needs some mapping from source-side asset identity to destination-side wrapped token or custody asset.
    • That mapping may live in a token-registration flow, denom-to-ERC20 table, resource-ID registry, metadata cache, or another canonicalization layer.
    • Operators often narrate this layer as metadata, UX, or listing plumbing.
    • In reality it is part of the authenticity boundary, because downstream withdrawals and mints trust it to answer which real asset does this source-side thing correspond to?.
    • A registry-poisoning failure happens when an attacker can make that layer bind a fake or attacker-controlled source-side asset identity to a valuable destination-side custody asset.
    • Once the bad binding is accepted, later validator-signed withdrawals or relayer-driven releases can look perfectly normal while paying out the wrong token.
  • Typical preconditions:
    • The bridge supports permissionless or weakly authenticated asset registration.
    • Source-side denomination identity is represented as a string, path, resource key, or metadata bundle that an attacker can influence.
    • Destination-side registration checks only structural validity, metadata compatibility, or address format instead of proving canonical origin identity.
    • Downstream mint / withdraw paths trust the registry lookup without an independent balance-sheet or origin sanity check.
    • The attacker can create source-side assets whose metadata intentionally imitates a real bridged asset closely enough to satisfy shallow validation.
  • Common vulnerable surfaces:
    • permissionless deployERC20() or token-registration paths for non-home-chain assets
    • denom-to-token lookup tables that trust free-form path strings or attacker-shaped identifiers
    • metadata-based asset matching that treats name / symbol / decimals compatibility as evidence of canonical identity
    • bridge handlers that check is this an address-shaped token contract? without asking whether that contract is already reserved for a different origin asset
    • relayer or validator claim formats that let registration claims redefine asset identity before value-moving claims consume that mapping
    • custody bridges where outgoing batch construction reuses the registry answer as if it were ground truth
  • Exploit sequence:
    1. The attacker creates or acquires a worthless source-side asset whose metadata and denomination path they can shape.
    2. They reach a token-registration or asset-declaration path that the bridge treats as authoritative.
    3. That path records a false binding between the fake source-side asset identity and a valuable destination-side custody asset.
    4. Validators or relayers accept the registration claim because the input looks structurally valid and passes shallow metadata checks.
    5. The attacker then submits an otherwise ordinary bridge withdrawal, batch, or mint request for the fake source-side asset.
    6. Downstream bridge logic resolves the poisoned mapping and releases or mints the valuable destination-side asset instead.
    7. The theft therefore lands through the normal bridge execution path, not through a visibly forged verifier step.
  • Variants:
    • Free-form denom aliasing — the bridge accepts an attacker-controlled string or path as canonical asset identity even though that string can embed or collide with a real destination-side asset reference.
    • Metadata-equality confusion — the bridge treats matching symbol, name, or decimals as if they proved canonical asset sameness.
    • Wrapper-versus-custody collision — registration logic lets a fake source-side asset point at a destination-side contract already reserved for a home-chain custody asset rather than minting a fresh wrapper.
    • Registry-first authenticity failure — validators honestly attest to later withdrawals, but the registry they consult has already redefined which asset those honest attestations refer to.
    • Permissionless listing as security boundary — what product docs frame as open asset listing is actually a path to redefine redeemable bridge truth.
    • Reserve inheritance without explicit admission — a new source-side asset or route quietly inherits the redeemability semantics of an existing destination reserve because admission, reservation, and route-local balance-sheet isolation were collapsed into one registry write.

Three asset-identity promotions reviewers should not collapse

  1. Some asset-looking object exists

    • A denom string, IBC trace, metadata bundle, deploy request, or registration candidate showed up.
    • That only means something claims to be bridgeable.

  2. That object still counts as canonical identity for this exact origin asset

    • The harder question is whether the bridge proved one unique origin tuple — source chain, source contract or native denom, issuer domain, route, and custody mode — rather than letting a metadata match, path alias, or permissive registration helper answer that question more cheaply.
    • If user-shaped strings or registration flow can promote a candidate into canonical identity too easily, the registry is already drifting away from provenance truth.

  3. That admitted identity deserves this much destination-side redeemability authority right now

    • Even a correctly identified new asset should not automatically inherit an existing premium wrapper, deep reserve, or broad withdrawal rights.
    • This is where destination reservation, isolated wrappers, staged activation, and route-local balance-sheet discipline matter.

Healthy bridge review gets materially better once teams stop flattening those three promotions into one vague moment called asset registered.

  • Detection heuristics:
    • Ask what exact object defines canonical asset identity across the bridge: hash, path, native contract address, issuer-controlled registry entry, or something weaker.
    • Treat token-registration and denom-mapping code as custody-critical verification logic, not metadata plumbing.
    • Review whether user-controlled strings, paths, or metadata can reach the canonical mapping table before a strong origin check occurs.
    • Search for code paths that confirm metadata matches or address is valid without confirming this asset identity is uniquely entitled to that destination token.
    • Check whether outgoing batches, mints, or withdrawals have any second layer of defense once the registry answer is wrong.
    • Look for places where the bridge could have minted a new wrapper but instead is allowed to bind a source-side asset to an existing high-value custody token.
  • Boundary tests that keep this pattern sharp:
    • Classify it here when the decisive lie is durable registry state. If honest validators or relayers later release the wrong asset because a canonical lookup table already says the fake source-side denomination redeems real custody, this note should do the analytical heavy lifting.
    • Classify it under cross-layer-interpretation-mismatch when one bridge payload means different things to different layers without first poisoning a long-lived registry. Syscoin is the clean contrast: the exploit paid because one ambiguous transaction resolved to different assets in Core and the relay, not because a standing denom table was rewritten ahead of time.
    • Classify it under message-source-authentication-failure when the bridge mainly accepted a message from the wrong emitter, channel, or handler path. That family breaks before asset identity lookup even becomes the main question.
    • Classify it under deposit-signal-locked-value-mismatch when the bridge lies about whether value was ever really locked or burned, rather than lying about which asset identity a real-looking record may redeem.
    • Escalate to bridge-asset-identity-admission-and-destination-reservation-discipline when the sharper question becomes how a healthy bridge should have kept new asset discovered separate from existing destination reserve now redeemable.
    • Escalate to bridge-route-local-redeemability-domain-discipline when the sharper question becomes why one route, channel, or wrapper namespace was ever allowed to share another route’s balance sheet in the first place.
  • Defenses:
    • Make canonical asset identity unforgeable and origin-specific: hash the real home-chain identifier, issuer domain, or verified source contract rather than trusting free-form metadata.
    • Separate asset discovery from asset authority; permissionless listing should not by itself decide what custody asset a denomination redeems.
    • Run provenance and reservation checks before cosmetic or governance-admission checks. The bridge should first reject denoms or resource identifiers that do not qualify for the intended origin class, then reject any collision with already-reserved destination assets in both directions (origin -> destination and destination -> origin), and only then compare metadata or allowlist status.
    • Refuse registration flows that can alias a new source-side asset onto an already-reserved destination-side custody token.
    • Treat symbol/name/decimal equality as presentation hints only, never as security evidence.
    • Add invariant checks around registration: if an asset is already known as destination-native or home-chain canonical, no external registration path should be able to overwrite or shadow it.
    • Add per-asset circuit breakers and accounting sanity checks so a new mapping cannot immediately drain established custody.

What sound design looks like

  • A healthy bridge keeps three promotions explicit instead of collapsing them into asset registered: candidate asset observed, canonical origin identity admitted, and destination-side redeemability authority granted. Each step should have a stronger gate than the one before it.

  • A healthy bridge treats asset identity as one canonical security object, not as a pile of loosely related names. The same origin chain, source contract or native denom, issuer domain, custody mode, and destination-side entitlement need to stay bound together from admission through redemption.

  • Discovery should be cheap, but redeemability should be expensive. A protocol can let users surface new assets permissionlessly while still requiring a stronger origin-verification step before those assets are allowed to touch existing custody or inherit a trusted wrapper identity.

  • Destination-native reserves and previously admitted canonical wrappers should be fenced off from new listings by construction. If a new source-side asset is unknown, the safe default is isolation into a fresh wrapper with low caps and delayed activation rather than silent reuse of a premium destination token contract.

  • Honest downstream execution should be unable to reinterpret identity. Once an asset is admitted, relayers, batch builders, and withdraw paths should all consult the same collision-resistant key and arrive at the same answer about what reserve that asset may redeem.

  • Monitoring should follow identity, not just ticker symbols. Operators need a route-aware balance-sheet view that can answer which exact origin asset is backing which exact destination liability right now? before a poisoned registry entry can hide inside aggregate USDC- or WETH-looking totals.

  • Positive-design companion worth preserving:

    • Bridge asset-identity admission and destination reservation discipline — use this when the sharper question is how a healthy bridge should separate discovery from redeemability, reserve destination-native assets from permissionless registration, and force new origin assets into isolated wrappers or staged activation until a stronger admission authority explicitly upgrades them.

  • High-signal incidents:

Failure-prevention checklist

  • Keep asset observed, identity admitted, and reserve redeemable as separate state transitions. Discovery should not by itself activate destination-side cashability.
  • Define one canonical asset-identity key per bridge route, and make it derive from origin-chain facts the attacker cannot author cheaply: source chain, source contract or native denom, verified issuer domain, and custody mode.
  • Reserve destination-native and already-listed custody assets explicitly. New registration flows should only mint a fresh wrapper or reject; they should never silently bind a novel source-side asset to an existing high-value token contract.
  • Separate discovery from admission. Permissionless asset listing may create a candidate record, but redeemability should activate only after a stronger origin-verification step and a human-reviewed or cryptographically constrained allow-list transition.
  • Reject metadata-equality as security evidence. symbol, name, decimals, display paths, and icon hashes are presentation hints, not proof that two assets may share redemption rights.
  • Make registry updates monotonic and collision-resistant: no overwrites, no ambiguous aliases, no shadow entries that differ only by formatting, casing, path normalization, or wrapper-vs-native representation.
  • Bind outgoing batch construction and redemption logic to the same canonical identity object used at admission time. If a later value-moving path can reinterpret the asset differently, the registry is too weak.
  • Add supply-versus-backing reconciliation per asset identity, not just per token symbol. The monitoring question is whether this exact origin asset is entitled to this exact destination liability.
  • Put blast-radius limits under new registrations: low initial caps, staged activation, withdrawal delays, and fast pause authority for assets that have not yet earned trust.
  • Treat token-registration handlers, denom-normalization code, and asset-deployment helpers as verifier-grade code during audits, upgrades, and incident response.
  • Log and alert on all identity-table mutations, especially any event that would newly associate a known custody asset with a previously unseen source-side identifier.

Audit prompts

  • What exact tuple defines canonical asset identity on this bridge, and where is that tuple computed and stored?
  • Can any user-controlled string, path, memo, metadata field, or deployment helper influence the registry key before origin authenticity is proven?
  • Which code paths are allowed to associate a source-side asset with an already-existing destination token contract, and what stops a fake asset from claiming a premium contract instead of receiving a fresh wrapper?
  • Are there normalization collisions between native denoms, IBC traces, wrapped representations, casing, checksummed addresses, or resource IDs that can cause two distinct origins to resolve to one destination asset?
  • If an attacker lists an asset with the same symbol, name, and decimals as a real bridged asset, where is redemption denied?
  • Can validators or relayers honestly attest to withdrawals whose semantic meaning depends entirely on a mutable registry entry created earlier by an attacker?
  • Does any upgrade, governance action, or operator tool permit overwriting or shadowing existing registry entries, and how is that monitored?
  • If the bridge mints wrappers for unknown assets, what guarantees that the wrapper factory can never return a reserved custody token address instead?
  • Are accounting checks keyed by canonical identity, or can aggregate totals hide the fact that a fake denom is draining the reserve for a real asset?
  • What emergency control contains a newly poisoned mapping before large outgoing batches or redemptions execute?

Lessons that should already be standard

  • Asset observed, asset identity admitted, and asset may redeem this reserve are different promotions. Bridges that collapse them hand listing and normalization code too much balance-sheet authority.
  • Asset registries are not metadata tables. They are the dictionary the bridge uses to decide what reserve a withdrawal is allowed to touch.
  • Honest signatures over poisoned identity state are still poisonous. Once the mapping lies, downstream validator honesty no longer protects custody.
  • Permissionless listing is a product decision only until it gains the power to define redeemability. After that, it is verification logic.
  • Metadata similarity is almost never a safe stand-in for canonical origin identity. Users care about symbols; bridges must care about provenance.
  • The dangerous transition is new asset observed to existing valuable reserve now redeemable. Safe designs keep those states far apart.
  • Collision resistance matters at the naming layer too. Formatting quirks, path aliases, and wrapper/native ambiguity can be just as fatal as signature bugs if they collapse distinct assets into one redeemable identity.
  • Monitoring by token symbol or TVL bucket is too coarse. Operators need to know which exact origin asset is backing which exact liability.
  • The safest default for unknown assets is isolation: new wrapper, low caps, delayed unlocks, and no path to commandeer established custody.

Where this pattern stops

  • Use cross-layer-interpretation-mismatch when one authenticated bridge artifact had no single canonical meaning across layers, as in Syscoin; there the exploit paid because the same payload resolved differently in different components, not because a standing registry had already been rewritten.
  • Use message-source-authentication-failure when the bridge mainly authenticated the wrong emitter, channel, or handler path before asset lookup was even the decisive question.
  • Use deposit-signal-locked-value-mismatch when the main lie is that source-side value was never really locked or burned, rather than that a real-looking source-side asset was allowed to redeem the wrong destination reserve.
  • Escalate to bridge-asset-identity-admission-and-destination-reservation-discipline when the sharper design question is how discovery, admission, and destination-reserve reservation should have been separated so the registry could never grant premium redeemability rights by default.
  • Escalate to bridge-route-local-redeemability-domain-discipline when the sharper design question is why a new route, wrapper, or namespace was allowed to inherit another route’s balance sheet at all.

Internal linkages

Control surface

Graph View

Backlinks