Bridged Token

A bridged token is a synthetic representation of a native asset from one blockchain that exists and operates on a different blockchain, created through a cross-chain bridge. It is not the original asset but a wrapped or pegged version that is programmatically linked to it. For example, Wrapped Bitcoin (WBTC) on Ethereum is a bridged token representing Bitcoin, allowing BTC to be used within Ethereum's ecosystem of decentralized applications (dApps) and DeFi protocols. The value of a bridged token is intended to be 1:1 with the original asset, maintained through locking or burning mechanisms on the source chain.

The creation process, or bridging, typically involves locking the native asset in a secure smart contract or custodian on its original chain and minting an equivalent amount of the bridged token on the destination chain. This process is often managed by a bridge protocol which can be trusted (relying on a federation or custodian) or trust-minimized (using cryptographic proofs and decentralized networks). When a user wishes to reclaim the original asset, they "burn" or destroy the bridged token, which triggers the release of the locked collateral on the source chain.

Bridged tokens are fundamental to blockchain interoperability, enabling liquidity and functionality to flow between otherwise isolated networks. They allow assets to access different features, such as using Bitcoin in Ethereum's faster, smart contract-enabled environment for lending or yield farming. However, they introduce specific risks, primarily counterparty risk in trusted models and smart contract risk in all models. The security of the bridged token is entirely dependent on the security and correctness of the bridge infrastructure, which has been a significant attack vector in the ecosystem.

Common standards for bridged tokens exist within their destination chains. On Ethereum and other EVM-compatible networks, bridged tokens are most often issued as ERC-20 tokens. Distinguishing between a bridged token and a native wrapped token (like WETH, which wraps the chain's own native ETH) is important; a bridged token always represents an asset foreign to the chain it resides on. Prominent examples include Wrapped BTC (WBTC), Multichain's anyUSDC, and Wormhole's Wrapped Asset (WA) tokens.

When interacting with bridged tokens, users and developers must verify the canonical bridge authority, as multiple unofficial or fraudulent "wrapped" versions of an asset can exist. The canonical bridge is the officially recognized and most widely adopted bridge for that asset, often endorsed by the asset's originating project. Using non-canonical bridges can lead to illiquidity or total loss if the bridge fails. Auditing the bridge's security model—whether it uses lock-and-mint, burn-and-mint, or liquidity pool mechanisms—is a critical due diligence step.

A bridged token is a representation of a native asset from one blockchain that is locked or burned on its source chain and minted as a synthetic equivalent on a destination chain, enabling cross-chain liquidity and functionality. This process is facilitated by a bridge protocol, which acts as a trusted intermediary or a set of decentralized smart contracts to manage the asset's custody and the mint/burn operations. The canonical example is Wrapped Bitcoin (WBTC), an ERC-20 token on Ethereum that represents Bitcoin locked in a custodian's vault, allowing BTC to be used within Ethereum's DeFi ecosystem.

The core technical operation involves a lock-and-mint or burn-and-release model. In a lock-and-mint bridge, the original asset (e.g., ETH) is sent to a secure address (often a multi-signature wallet or a smart contract) on the source chain, which then triggers the minting of an equivalent amount of the bridged token (e.g., WETH on Arbitrum) on the destination chain. To return the asset, the bridged token is burned on the destination chain, providing cryptographic proof that releases the original asset from custody on the source chain. This mechanism requires a verification system, which can range from a centralized federation to a decentralized network of light clients or optimistic fraud proofs.

Different bridge architectures present distinct security and trust models. Trusted or custodial bridges rely on a central entity or a multi-sig committee to hold the locked assets, introducing counterparty risk. Trust-minimized bridges use cryptographic proofs and economic incentives; for example, light client bridges verify block headers from the source chain, while liquidity networks use atomic swaps and liquidity pools without centralized custody. The choice of model involves a fundamental trade-off between security, decentralization, and speed, with more secure bridges often being slower and more complex to operate.

Bridged tokens introduce unique risks, primarily bridge exploit risk, where a vulnerability in the bridge's smart contracts or validator set can lead to the theft of locked assets—a common vector for major crypto heists. There is also wrapping risk, where the bridged token's value becomes decoupled from its underlying asset if the custodian becomes insolvent or the bridge fails. Furthermore, canonical bridges (officially endorsed by the destination chain) and third-party bridges compete, leading to fragmentation where multiple representations of the same asset (e.g., USDC.e and native USDC) exist on one chain, creating complexity for users and protocols.

For developers and protocols, integrating bridged tokens requires careful consideration. Smart contracts must account for the specific token standard and decimal precision of the bridged asset, which may differ from the native version. Protocols often implement allowlists for specific bridge origins to manage risk and may offer incentives for liquidity migration to a canonical version. The long-term evolution points toward native cross-chain messaging and interoperability protocols like the Inter-Blockchain Communication (IBC) protocol, which aim to make asset transfers a seamless, trustless primitive rather than a layered abstraction.