Asset Teleportation

This is the foundational two-way peg model. To teleport an asset from Chain A to Chain B:

• Lock: The original asset (e.g., 1 BTC) is cryptographically locked in a smart contract or multi-signature vault on the source chain.
• Mint: An equivalent, representation token (e.g., 1 wBTC) is minted on the destination chain, backed 1:1 by the locked collateral.
• Burn-and-Release: To return, the representation token is burned on the destination chain, triggering the release of the original asset from the source chain vault.

Also known as Liquidity Network Bridges, these use decentralized liquidity pools on both chains instead of locking assets. Users swap assets directly via Automated Market Makers (AMMs).

• A user swaps ETH on Ethereum for a liquidity provider's ETH on Arbitrum.
• The liquidity provider's inventory is rebalanced across chains via arbitrageurs.
• This model enables faster, more capital-efficient transfers but introduces different trust assumptions regarding pool security and oracle reliability.

A critical distinction in teleported assets:

• Canonical (Native) Assets: Are the 'official' teleported assets, minted and burned by the canonical bridge protocol native to the destination chain (e.g., Optimism's bridged ETH). They are redeemable directly via the protocol.
• Wrapped Assets: Are secondary representations created by third-party bridges (e.g., Multichain's anyETH). They introduce additional trust in the bridge operator and create fragmentation, as wETH from Bridge A is not fungible with wETH from Bridge B.

Bridges vary widely in their security, defined by who validates transfers:

• Externally Verified (Federated/Multisig): A committee of known entities signs off on transfers. Trust Assumption: Honest majority of signers.
• Natively Verified (Light Client/Relay): The destination chain verifies source chain block headers via light clients. Trust Assumption: Security of the underlying source chain.
• Locally Verified (Liquidity Network): Security relies on the economic incentives of liquidity providers and oracles. Trust Assumption: Honest oracle and sufficient liquidity.

An emerging architecture that aggregates liquidity from multiple independent bridges into a single network layer. This solves the liquidity fragmentation problem of wrapped assets.

• Users access the best available rate across all integrated bridges.
• The layer provides a unified canonical representation of the asset on the destination chain.
• It enhances security through risk diversification and sophisticated routing that can avoid compromised bridges.

A purely peer-to-peer method for cross-chain asset transfer without intermediaries. It uses:

• Hash Time-Locked Contracts (HTLCs): Cryptographic contracts that lock funds until a secret is revealed or a timeout expires.
• Process: Alice locks asset A on Chain 1 with a secret hash. Bob locks asset B on Chain 2, able to claim Alice's asset only if he reveals the secret, which then allows Alice to claim Bob's asset.
• This enables trustless exchange but requires a counterparty and is typically used for swaps, not one-way teleportation.

The canonical model for wrapped assets. Assets are locked in a smart contract on the source chain, and an equivalent synthetic version is minted on the destination chain. To return, the synthetic asset is burned, unlocking the original. This creates a 1:1 pegged representation.

• Example: Wrapped Bitcoin (WBTC) on Ethereum.
• Security: Relies on the custodian or multi-sig governing the lock contract.

Uses liquidity pools on both chains. Users deposit an asset into a pool on Chain A and receive it from a pool on Chain B. No locking or minting of synthetic assets occurs; it's a swap facilitated by liquidity providers.

• Example: Stargate Finance and Synapse Protocol.
• Advantage: Often faster and supports native assets.
• Risk: Relies on the security of the bridge's smart contracts and the economic security of its liquidity.

Enables trustless cross-chain swaps using Hash Time-Locked Contracts (HTLCs). A user on Chain A locks funds with a secret hash. A counterparty on Chain B can claim them by revealing the secret within a time window, which also unlocks funds for the first user. No intermediary custody is required.

• Mechanism: Based on cryptographic conditional payments.
• Use Case: Direct peer-to-peer cross-chain exchanges.
• Limitation: Requires a counterparty with matching liquidity and intent.

Employs a fraud-proof system similar to Optimistic Rollups. A Notary or Relayer submits a state root attestation, which is assumed valid unless challenged during a dispute period. This reduces operational cost but introduces a withdrawal delay for security.

• Example: Nomad Bridge (prior to its exploit).
• Trade-off: Security through economic incentives and a challenge period versus slower finality.

The most cryptographically secure model. Light client smart contracts on the destination chain verify Zero-Knowledge proofs (e.g., zk-SNARKs) that prove the validity of transactions on the source chain. This allows the destination chain to trustlessly verify the source chain's state.

• Example: zkBridge projects and Polygon zkEVM's bridge.
• Advantage: Trust-minimized, with security derived from the source chain's validators.
• Challenge: High computational cost for proof generation and verification.

Official, chain-native bridges maintained by the core development team of a blockchain or rollup. They are the sanctioned path for moving assets to and from a specific Layer 1 or Layer 2.

• Examples:
  • Arbitrum Bridge (Ethereum ↔ Arbitrum)
  • Polygon POS Bridge (Ethereum ↔ Polygon)
  • Optimism Gateway (Ethereum ↔ Optimism)
• Trust Model: Typically uses a multi-sig or a set of trusted validators appointed by the foundation.

Most teleportation systems rely on a validator set or oracle network to attest to events on the source chain. A malicious majority (e.g., >⅔) can approve fraudulent transfers, minting unlimited tokens on the destination chain. This is a consensus-level attack. Security models vary:

• Proof-of-Stake with Slashing: Validators stake assets that can be destroyed for malicious acts.
• Multi-Party Computation (MPC): Requires a threshold of signatures, distributing trust.
• Fraud Proofs: A challenge period where anyone can submit proof of invalid state transitions.

A replay attack occurs when a valid message authorizing a transfer on one chain is maliciously reused to authorize a duplicate transfer. Prevention requires robust nonce management and domain separation. Each message must include a unique identifier (nonce) and be explicitly bound to the specific chain IDs of both the source and destination networks. Without this, a signed approval could be replayed on a forked chain or a different deployment of the same bridge.

Teleportation often involves wrapped assets (e.g., wBTC, axlUSDC) backed by a locked reserve. Security is only as strong as the collateralization ratio and the custody of the reserve. If the reserve is compromised or undercollateralized, the wrapped asset depegs. Furthermore, liquidity pool risks exist for pool-based models; a sudden withdrawal can cause insolvency or extreme slippage, breaking the peg of the bridged asset.

The relayer network or validators responsible for submitting transactions to the destination chain may censor users or fail entirely (liveness failure). This can strand assets in transit. Decentralized, permissionless relayers or incentivized relay networks mitigate this. Some designs also allow users to self-relay the final transaction by submitting the validity proof themselves, though this requires paying gas on the destination chain.

Many bridge contracts have upgradeable proxies controlled by a multi-sig wallet or DAO. This creates a centralization vector where a small group can change bridge logic, potentially minting tokens or stealing funds. The security model shifts from code-based trust to social/political trust in the governing entity. Transparent, time-locked upgrades with broad governance (e.g., via the destination chain's native governance) reduce this risk.