L2BEAT Bridges is a work in progress. You might find incomplete research or inconsistent naming. Join our Discord to suggest improvements!
Transporter
About
Transporter is a Token Bridge based on Chainlink’s Cross-Chain Interoperability Protocol (CCIP) network.
About
Transporter is a Token Bridge based on Chainlink’s Cross-Chain Interoperability Protocol (CCIP) network.
Transporter is a Token Bridge based on Chainlink’s Cross-Chain Interoperability Protocol (CCIP) network.
Transporter is a hybrid bridge that can work either as a Token Bridge or Liquidity Network depending on the requirements of tokens. It is using Chainlink CCIP standard for cross-chain communication, and it makes use of a secondary network of nodes, called Risk Management Network, responsible for validating the messages or halt the bridge.
Funds can be stolen if
Users can be censored if
Principle of operation
Transporter is a Token Bridge based on the CCIP network. The CCIP network is an AMB (Arbitrary Message Bridge) that enables the cross-chain transfer of arbitrary messages that are attested by ChainLink Oracles as well as a separate Risk Management Network. On each chain it has a singleton Router contract. For each route (”lane”) there is a triplet of OnRamp, OffRamp and CommitStore contracts defined. OnRamp is used to send messages to a destination chain, while OffRamp and CommitStore are used to receive messages. The CommitStore is used to store Merkle roots of CCIP messages sent from the Source chain, while OffRamp is used to verify and execute incoming messages. Both OnRamps and OffRamps use TokenPools to escrow tokens, one TokenPool per token. TokenPools - depending on token - may Lock/Release or Mint/Burn tokens. They may also use some custom setup, like e.g. for USDC where TokenPool is a wrapper for Circle’s CCTP bridge.
Oracle Network
Chainlink Oracle network is responsible for validating cross-chain messages. For additional security, CCIP uses an off-chain secondary validation network called Risk Management Network. Each pathway between a source and a destination blockchain contains two Oracle committees. One committee interacts with the CommitStore contract on the destination chain to store the Merkle root of the finalized messages on the source blockchain. After the Risk Management Network verifies the merkle root and submits a voteToBless() transaction, the second oracle committee can execute the message on the destination chain.
Users can be censored if oracle network fails to facilitate the transfer.
Funds can be stolen if oracle network is compromised and Risk Management Network fails to halt ("curse") the bridge. Both networks would need to be separately compromised.
The system uses the following set of permissioned addresses:
Role-based Access Control Timelock (RBACTimelock) smart contract. Onchain security-critical configuration changes and upgrades to the CCIP must pass through this contract. CCIP contract upgrades have to go through a 3h timelock.
Admins of the RBACTimelock contract. Can modify all other roles.
Proposers of the RBACTimelock contract. Can propose upgrades.
Cancellers of the RBACTimelock contract. Can cancel pending upgrades.
Contract through which RBACTimelock proposals are executed. Proposals execution can be initiated by anyone.
The system consists of the following smart contracts on the host chain (Ethereum):
Central contract in CCIP responsible for the configuration of OnRamp, OffRamp and Commit Stores for different chains. This is an example Router contract for one of the lanes. There are many more lanes in the system, please check the specific smart contract for the lane you are interested in.
OnRamp for outgoing messages to Arbitrum. This is an example OnRamp contract for one of the lanes. There are many more lanes in the system, please check the specific smart contract for the lane you are interested in.
OffRamp for incoming messages from Arbitrum. This is an example OffRamp contract for one of the lanes. There are many more lanes in the system, please check the specific smart contract for the lane you are interested in.
CommitStore for storing incoming message roots from Arbitrum. This is an example CommitStore contract for one of the lanes. There are many more lanes in the system, please check the specific smart contract for the lane you are interested in.
The contract that manages the Risk Management Network, allowing blessing (validation) of messages and cursing (halting) the chain.
CCIP contract upgrades have to go through a 3h timelock.
Value Locked is calculated based on these smart contracts and tokens:
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is a 3h delay on code upgrades, during which designated Cancellers can veto the upgrade.