L2BEAT Bridges is a work in progress. You might find incomplete research or inconsistent naming. Join our Discord to suggest improvements!
Across V3
About
Across V3 is a cross-chain optimistic bridge that uses actors called Relayers to fulfill user transfer requests on the destination chain.
About
Across V3 is a cross-chain optimistic bridge that uses actors called Relayers to fulfill user transfer requests on the destination chain.
Across V3 is a cross-chain optimistic bridge that uses actors called Relayers to fulfill user transfer requests on the destination chain.
Relayers are later reimbursed by providing a proof of their action to an Optimistic Oracle on Ethereum. Relayer reimbursements over a specific block range are bundled and posted on-chain as merkle roots which uniquely identify the set of all repayments and rebalance instructions. The architecture leverages a single liquidity pool on Ethereum and separate deposit/reimburse pools on destination chains that are rebalanced using canonical bridges.
Funds can be stolen if
Funds can be lost if
- owner invokes a "haircut" functionality, dedicated for irrecoverable loss of funds on L2. Calling the haircutReserves() function, the owner can decrease the token utilizedReserves on L1, decreasing the amount of funds in the bridge expected to flow from L2 to L1,
- third-party bridge infrastructure is compromised, such as canonical messaging services, Linea USDC bridge, and USDC Cross-Chain Transfer Protocol (CCTP) infrastructure,
- a re-org occurs on destination chain after the Optimistic Oracle dispute time passes.
Principle of operation
This bridge performs cross-chain swaps by borrowing liquidity from a network of Relayers who are then reimbursed on a chain of their choosing from a common liquidity pool (which consists of user deposits and deposits of independent Liquidity Providers). Specifically, when a user deposits funds for a swap into a dedicated pool on the origin chain, a Relayer first pays the user on the requested destination chain and then shows proof of that deposit to Optimistic Oracle on Ethereum (by proposing a merkle root). If the root remains unchallenged for 1h, it is optimistically finalized and the Relayer is reimbursed. Liquidity used for reimbursements is rebalanced between a main pool on Ethereum (called Hub Pool) and pools on destination chains (called Spoke Pools) via canonical chain bridges.
Funds can be frozen if owner pauses the Hub Pool contract, or changes bond, routes, or fees parameters in such a way as to make the escrow inoperable.
Funds can be lost if owner invokes a "haircut" functionality, dedicated for irrecoverable loss of funds on L2. Calling the haircutReserves() function, the owner can decrease the token utilizedReserves on L1, decreasing the amount of funds in the bridge expected to flow from L2 to L1.
Funds can be lost if third-party bridge infrastructure is compromised, such as canonical messaging services, Linea USDC bridge, and USDC Cross-Chain Transfer Protocol (CCTP) infrastructure.
Validation via Optimistic Oracle
Money from the liquidity pool is used to reimburse Relayers based on a proof of deposit on a destination chain that is provided to an Optimistic Oracle on Ethereum. The proof can be disputed in a configured time period.
Funds can be stolen if a false claim to the Optimistic Oracle is not disputed in time.
Funds can be lost if a re-org occurs on destination chain after the Optimistic Oracle dispute time passes.
Destination tokens
Only tokens that have been bridged using native chain bridges are supported.
The system uses the following set of permissioned addresses:
This is a Gnosis Safe with 3 / 5 threshold. It uses the following modules: OptimisticGovernor. Can invoke admin functions of HubPool contract, and by implication of other contracts.
Those are the participants of the HubPool Multisig.
Allowed to propose BondToken transfers.
The system consists of the following smart contracts on the host chain (Ethereum):
Escrow contract for ERC20 tokens and administration of other contracts. There is a 1h delay before a bundle proposal is considered finalized. This contract can store any token.
Token (ABT) used to bond the data worker for proposing Relayer refund bundles. It also used as a required bond to dispute a bundle proposal. Currently, the bond amount is set to 0.45 ABT.
UMA Optimistic Oracle smart contract. It registers dispute requests, status of disputes, and dispute settlement.
Owner of the Optimistic Oracle. This contract is used to execute a proposed UMA governance action that has been approved by UMA token holders.
Token used to vote on UMA Optimistic Oracle governance proposals.
Factory to deploy new LP tokens for L1 tokens, used to represent a liquidity provider position in the HubPool.
Provides addresses of the live contracts implementing certain interfaces, such as the whitelist interface for setting the Bond Token.
Contract enabling depositors to transfer assets from Ethereum to L2s, and relayers to fulfill transfer from L2s to Ethereum. Deposit orders are fulfilled by off-chain relayers with the fillV3Relay() function. Relayers are later refunded with destination token out of this contract when the data worker submits a proof that the relayer correctly submitted a relay on this SpokePool. This contract can store any token.
Contract deployed on Ethereum and Polygon PoS to facilitate token transfers from Polygon to the HubPool.
Contract storing configurations such as token rate models and minimum transfer thresholds, meant for off-chain consumption.
Value Locked is calculated based on these smart contracts and tokens:
The current deployment carries some associated risks:
Funds can be stolen if a Spoke Pool contract receives a malicious code upgrade. There is no delay on code upgrades.
