Bridged Token

Overview

Bridging creates a way to use an asset in another blockchain ecosystem. For example, a token native to Ethereum can be locked in a bridge contract while a representation is minted on a different chain.

The security model varies. A centralized custodian can control release keys. A multisignature or validator set can attest to source-chain events. More trust-minimized systems use light clients, fraud proofs, or validity proofs. Every design adds assumptions beyond the source token.

A destination token’s value relies on redemption. If the bridge is hacked, paused, insolvent, or unable to process withdrawals, the representation can trade below the original asset. Liquidity can also fragment across several unofficial bridged versions.

Asset identity must include source chain, destination chain, bridge, and contract address. A symbol such as USDC, ETH, or BTC can identify several representations with different issuers and redemption routes.

Applications should monitor both source reserves and destination supply where possible. They should also define how upgrades, bridge deprecation, and token migration are handled. Sending a bridged token to a service that supports only the canonical version can lead to loss.

A bridged token expands interoperability but does not become the original asset. Its risk is the combined risk of the source asset, bridge, destination chain, and available redemption path.

Bridge deprecation deserves explicit handling. A representation can remain transferable after the official redemption route closes, causing price divergence and trapped liquidity. Applications should monitor supported canonical routes and warn users before accepting a token whose bridge, issuer, or destination contract is being retired.