L2BEAT Bridges is a work in progress. You might find incomplete research or inconsistent naming. Join our discord to suggest improvements!

Poly Bridge logoPoly Bridge

Poly Bridge allows users to transfer assets between different blockchains using Lock-Mint swap.
  • Total value locked
    $2.53 M8.50%
  • Destination
    Various
  • Validated by
    Third Party
  • Type
    Token Bridge
  • ...

    Tokens

    Choose token

    Bridged Tokens (Top 15)

    Wrapped BTC (WBTC)
    Metis Token (Metis)
    Tribe (TRIBE)
    Ether (ETH)
    Radio Caca V2 (RACA)
    Pax Dollar (USDP)
    renBTC (renBTC)
    USD Coin (USDC)
    Tether USD (USDT)
    Fei USD (FEI)
    Wrapped Ether (WETH)
    Dai Stablecoin (DAI)
    Milestones

    Compromised multisig steals funds

    2023 Jul 3rd

    Contracts hacked for $611M

    2021 Aug 10th

    Detailed description

    Poly Bridge allows users to transfer assets between different blockchains using Lock-Mint swap.

    It uses a PolyNetwork chain to verify and coordinate message passing between Relayers on supported chains. Each chain has a set of Relayers, while PolyNetwork chain has a set of Keepers that sign cross-chain messages. Chains integrated with Poly Bridge need to support light client verification, since validation of cross-chain messages includes verifying block headers and transactions via Merkle proofs. Some of the smart contracts used by the bridge infrastructure are not verified on Etherscan.

    Risk summary
    This project includes unverified contracts. (CRITICAL)
    Technology

    Principle of operation

    Note: This section requires more research and might not present accurate information.

    Poly Bridge operation is centered around PolyNetwork chain that acts as a type of a light client for all supported chains. Each supported chain has a set or Relayers that transmit successive block headers to the PolyNetwork chain, as well as lock or burn events. Those events, after passing verification on PolyNetwork chain, are relayed to the destination chain by Relayers that are responsible for the destination chain. Relayers on the destination chain pass messages to appropriate contracts that mint or release corresponding tokens to the user after verifying validity of the message.

    • Funds can be frozen if contract Owner pauses one of the bridge contracts.

    1. PolyNetwork docs from source code
    2. Ethereum-related PolyNetwork docs from source code

    Validation of cross-chain transactions

    Note: This section requires more research and might not present accurate information.

    Each supported chain has a set of Relayers that are responsible for sending successive block headers since pre-specified origin to the PolyNetwork chain, which stores these blocks after validating their aspects, such as structure, difficulty, consistency with previous blocks, etc. When user locks or burns an asset for a cross-chain swap, an event is relayed by Relayer to the PolyNetwork chain with a Merkle proof of that transaction being included in a block. The PolyNetwork chain is able to verify Merkle proof using block headers that it keeps. PolyNetwork chain itself uses a set of Keepers to sign transactions after checking their validity. Once a cross-chain transaction is verified on PolyNetwork, an event is emitted that is picked by Relayers on the destination chain. The block header and Merkle proof for a transaction on a source chain is validated by a contract on the destination chain (if it supports such verification) and the asset is minted or released to the recipient.

    • Users can be censored if chain Relayers decide to not pass certain transactions to the destination chain (CRITICAL).

    • Funds can be stolen if a fake block header is relayed through the PolyNetwork chain that allows to prove a burn/mint transaction that never occurred on the source chain (CRITICAL).

    • Funds can be frozen if chain Relayers don't relay messages.

    • Funds can be frozen if the PolyNetwork Keepers don't sign messages.

    1. Header verification source code
    Permissions

    The system uses the following set of permissioned addresses:

    Owner and Fee Collector at PolyWrapper and owner at LockProxyWithLP 0x0E86…8A57

    Can add new bridge contracts (Escrows, LockProxy), pause the bridge, and transfer to itself all funds and ERC20 tokens of the PolyWrapper contract.

    Owner of EthCrossChainManager 0x5a51…d2Eb

    Can pause the contracts and update implementation of EthCrossChainData contract.

    Can update address of EthCrossChainManagerProxy contract.

    Smart contracts

    The system consists of the following smart contracts on the host chain (Ethereum):

    PolyWrapper 0x8191…386A

    Entrypoint contract for the bridge. It proxies requests to LockProxy.

    Lock Proxy 1 0x250e…c906

    Escrow and proxy contract for the Bridge. This contract can store any token.

    Lock Proxy 2 0x7b9B…DB54

    Escrow and proxy contract for the Bridge.

    Lock Proxy 3 0x3Ee7…0035

    Escrow and proxy contract for the Bridge. The source code of this contract is not verified on Etherscan.

    Lock Proxy 4 0x53D2…B868

    Escrow and proxy contract for the Bridge. This contract stores the following tokens: ETH.

    Lock Proxy 5 0xf637…7b27

    Escrow and proxy contract for the Bridge.

    Lock Proxy 6 0x669E…d1BC

    Escrow and proxy contract for the Bridge. The source code of this contract is not verified on Etherscan.

    Lock Proxy 7 0x51ba…968D

    Escrow and proxy contract for the Bridge.

    Lock Proxy 8 0xead1…DFc0

    Escrow and proxy contract for the Bridge.

    EthCrossChainManager 0x1441…488C

    Contract responsible for building cross-chain messages and validating incoming messages, including Merkle proofs. The contract is pausable by EthCrossChainManager.

    EthCrossChainData 0xcF2a…10f2

    Used to store Keepers’ signatures and other parameters used by EthCrossChainManager.

    EthCrossChainManagerProxy 0x5a51…d2Eb

    Used to proxy requests from LockProxy to EthCrossChainManager. The contract is pausable by EthCrossChainManager.

    The current deployment carries some associated risks:

    • Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).

    • Funds can be stolen if the source code of unverified contracts contains malicious code (CRITICAL).