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


...


Tokens:

Description

This project includes unverified contracts (CRITICAL).

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.

If you find something wrong on this page you can submit an issue or edit the information.

Risk summary

Note: This project's overview requires more research and might not present accurate information. If you want to contribute you can edit the information on Github. Alternatively you contact the project team on Twitter and encourage them to contribute a PR.

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

Permissioned Addresses

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 (Unverified source code) 0x5a51…d2Eb

Unverified contract on Etherscan. Can pause the contracts and update implementation of EthCrossChainData contract.

Owner of LockProxy 0x250e 0x8B35…4106

Can update address of EthCrossChainManagerProxy contract.

Owner at LockProxy 0x3Ee7... 0x52D8…d459

Can update address of EthCrossChainManagerProxy contract.

Owner of LockProxy 0x53D2... 0xeF86…5d8c

Can update address of EthCrossChainManagerProxy contract.

Smart Contracts

The system consists of the following smart contracts:

PolyWrapper 0x8191…386A

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

Escrow and proxy contract for the Bridge. This contract stores the following tokens: ETH, USDT, USDC, WBTC, DAI, UNI, SHIB, renBTC, FEI.

Proxy contract for the Bridge.

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

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

EthCrossChainManager 0x1441…488C

Contract responsible for building cross-chain messages and validating incoming messages, including Merkle proofs.

EthCrossChainData (Unverified source code) 0xcF2a…10f2

Contract unverified on Etherscan. Used to store Keepers' signatures and other parameters used by EthCrossChainManager. The source code of this contract is not verified on Etherscan.

EthCrossChainManagerProxy (Unverified source code) 0xcF2a…10f2

Contract unverified on Etherscan. Used to proxy requests from LockProxy to EthCrossChainManager. The source code of this contract is not verified on Etherscan.

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).

  • the source code of unverified contracts contains malicious code (CRITICAL).