Search
Search for projects by name
Across
L2BEAT Bridges is a work in progress. You might find incomplete research or inconsistent naming. Join our Discord to suggest improvements!
About
Across is a multichain optimistic bridge that uses actors called Relayers to fulfill user transfer requests (intents) on the destination chain.
About
Across is a multichain optimistic bridge that uses actors called Relayers to fulfill user transfer requests (intents) on the destination chain.
Across v4
2025 Jul 2nd
Features a new path to relay root bundles to destination chains using zk proofs (uses SP1Helios).
Across is a multichain optimistic bridge that uses actors called Relayers to fulfill user transfer requests (intents) on the destination chain.
Relayers are later reimbursed by providing an assertion to an optimistic oracle (HubPool) on Ethereum. Relayer reimbursements over a specific block range are bundled and posted on Ethereum 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 mainly 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, SP1Helios verifier, 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 later reimbursed from a common liquidity pool (which consists of user deposits and deposits of independent Liquidity Providers).
Specifically, when a user deposits funds into a dedicated pool on the origin chain, a Relayer pays the user on the requested destination chain (fills their intent). On most SpokePools, relayers can also specify a preference for their chain of reimbursement at fill time. A permissioned proposer (or data worker) collects data about fills by relayers and then posts an assertion to the HubPool on Ethereum. This is called a ‘root bundle’, which contains 3 merkle roots, chiefly a merkle root of all proposed Relayer reimbursements.
A root bundle proposal must be accompanied by a bond of 0.45 ABT (an ETH wrapper). It is validated optimistically in the HubPool contract and becomes executable after 30m (refunding the bond to the proposer) if not challenged. A challenge by anyone posting the same bond amount halts finalization of the root bundle and escalates the dispute to the UMA DVM.
UMA settles disputes by UMA token voting, with a commit- and reveal phase of 1d each. A settlement slashes the stake of the losing party and rewards the winning party with both bond amounts minus fees.
On finalization, a rootBundle can be 1) relayed to remote SpokePools and 2) executed. Execution of a relayerRefundLeaf (via a merkle proof) at its specified SpokePool contract refunds the relayer.
Relaying a rootBundle to a SpokePool is either done via canonical bridges or via a zk light client that is proven in the SP1Helios contract (based on the SP1 zkVM and the Helios Ethereum light client).
The permissioned proposer of the root bundle can also propose rebalancing liquidity used for reimbursements between a main pool on Ethereum (called Hub Pool) and pools on destination chains (called Spoke Pools). This is done via canonical chain bridges and other bridges (e.g. Circle CCTP) using adapters. For some chains, liquidity is not rebalanced and relayers are always reimbursed where the user deposited their funds.
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, SP1Helios verifier, and USDC Cross-Chain Transfer Protocol (CCTP) infrastructure.
Validation via Optimistic Oracle and UMA DVM
Money from the liquidity pool is used to reimburse Relayers based on a claim of deposit on a destination chain that is provided to an Optimistic Oracle on Ethereum (can be escalated to the UMA DVM). The assertion can be disputed for 30m.
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.
Ethereum
Roles:
Can propose new root bundles (containing settlement info to refund relayers), which are validated optimistically by the UMA oracle.
Actors:
Central UMA governance contract. It executes administrative proposals that have been passed by UMA token holder votes.
- Can interact with VotingV2
- set critical administrative parameters like migrating to a new contract and requesting governance actions (
requestPrice()) directly
- set critical administrative parameters like migrating to a new contract and requesting governance actions (
- Can interact with Registry
- manage registered contracts
- Can interact with Finder
- manage address mappings
- Can interact with ProposerV2
- set the bond amount
- Can interact with Store
- set fees for disputes and manage all roles in the contract
- Can interact with GovernorV2
- manage all roles in the contract
- Can interact with EmergencyProposer
- remove and slash proposals, set the bond amount and the expiry time, manage the executor address
- Can interact with IdentifierWhitelist
- manage the whitelist
- Can interact with AddressWhitelist
- manage the addresses on the whitelist
- Can interact with OptimisticOracleV3
- set critical administrative parameters like default bonds, bond token, fees
Optimistic Governance module allowing for proposals by anyone with a bond of 2 WETH. They become executable if not challenged within 2d. The rules for proposals can be read directly from the contract values.
- Can interact with AcrossConfigStore
- update configuration values Across Multisig
- Can interact with OptimisticGovernor
- set guard, avatar, target, delay, identifier, escalationManager, bond token and amount Across Multisig
- Can interact with HubPool
- pause the system, manage all fees, bonds and security parameters, manage tokens and chain support, and critical emergency actions like admin functions on remote SpokePools or deleting proposals (can steal funds) Across Multisig
- Can interact with AcrossBondToken (ABT)
- manage the proposer role Across Multisig
A Multisig with 3/5 threshold. It uses the following modules: OptimisticGovernor (Optimistic Governance module allowing for proposals by anyone with a bond of 2 WETH. They become executable if not challenged within 2d. The rules for proposals can be read directly from the contract values).
- Can interact with AcrossConfigStore
- update configuration values
- Can interact with OptimisticGovernor
- set guard, avatar, target, delay, identifier, escalationManager, bond token and amount
- Can interact with HubPool
- pause the system, manage all fees, bonds and security parameters, manage tokens and chain support, and critical emergency actions like admin functions on remote SpokePools or deleting proposals (can steal funds)
- Can interact with AcrossBondToken (ABT)
- manage the proposer role
Token governance contract allowing anyone to create a UMA governance proposal for a bond of 5,000 UMA tokens.
- Can interact with GovernorV2
- propose governance actions
Token governance contract allowing anyone to create a UMA governance proposal for a bond of 5,000,000 UMA tokens. This circumvents the UMA optimistic oracle but can only be executed or removed after 10d, and only by UMA Multisig.
- Can interact with GovernorV2
- can bypass the voting system and execute proposals immediately
A Multisig with 2/4 threshold.
- Can interact with EmergencyProposer
- remove proposals, execute emergency proposals
- Can interact with Store
- withdraw fees
- Can interact with AcrossBondToken (ABT)
- use ABT as a bond to the HubPool contract for root bundle proposals
- A Proposer - acting directly
Ethereum
This adapter can be used to send messages / root bundles to Hyperliquid. It stores calldata in the HubPoolStore on Ethereum, which can then be zk proven on a remote chain. This adapter also supports bridging OFTs via LayerZero.
Simple data store used by the Universal_Adapter to store message calldata hashes. The content of this calldata can be proven by Ethereum zk light clients on remote chains and then executed to relay root bundles or arbitrary messages.
The user-facing contract on each connected chain where funds are deposited to initiate a bridge transfer. It also receives settlement data from the HubPool to process refunds for the relayers who fulfilled those transfers.
- Roles:
- admin: HubPool
- owner: HubPool
- This contract can store any token.
This adapter can be used to send messages / root bundles to Binance Smart Chain. It stores calldata in the HubPoolStore on Ethereum, which can then be zk proven on a remote chain. This adapter also supports bridging OFTs via LayerZero.
This adapter can be used to send messages / root bundles to Plasma Mainnet. It stores calldata in the HubPoolStore on Ethereum, which can then be zk proven on a remote chain. This adapter also supports bridging OFTs via LayerZero.
The central L1 contract (hub) that manages liquidity from LPs and coordinates cross-chain settlements. It receives and secures settlement proposals (root bundles) using the UMA Optimistic Oracle, with a challenge period of 30m and a bond amount of 0.45 ABT.
- Roles:
- owner: Across Multisig; ultimately OptimisticGovernor
- This contract can store any token.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Core smart contract for UMA’s Data Verification Mechanism (DVM), serving as source of truth for disputed claims. UMA token holders collectively resolve price requests and earn rewards for correct participation. Commit- and reveal phases for the voting take 1d each.
- Roles:
- owner: GovernorV2
Simple, owner-controlled contract for storing protocol-wide, token-specific configuration data.
- Roles:
- owner: Across Multisig; ultimately OptimisticGovernor
Registry for contracts that are allowed to call requestPrice() in the UMA voting contracts (ie. request dispute resolution by the UMA DVM).
- Roles:
- owner: GovernorV2
Maps interface names to contract addresses (UMA protocol contracts).
- Roles:
- owner: GovernorV2
A helper contract for chain adapters on the hub chain that support OFT messaging. Handles token -> messenger mapping.
UMA protocol contract responsible for calculating and collecting regular and final fees for using the DVM.
- Roles:
- owner: GovernorV2
- withdrawer: EOA 1
Stores slashing parameters and calculates slashing amounts based on that (UMA protocol).
Keeps a list of whitelisted identifiers that are accepted by the UMA v3 protocol. Across uses the identifier ACROSS-V2 for its disputes.
- Roles:
- owner: GovernorV2
A simple address whitelist for tokens that can be used as bonds and/or fees. This whitelist is checked and enforced by various smart contracts in the UMA ecosystem.
- Roles:
- owner: GovernorV2
A bond token wrapping ETH for usage in the Across protocol. Implements modified ERC20 logic to only allow permissioned proposers to use it as a bond for root bundle proposals.
- Roles:
- owner: Across Multisig; ultimately OptimisticGovernor
- proposers: EOA 2
Validates bridge messages by allowing proposers to make bonded assertions about crosschain events. It enforces a challenge period during which any invalid claims can be disputed and escalated to UMA’s Data Verification Mechanism (DVM) for resolution.
Standard UMA optimistic oracle contract that allows anyone to make an arbitrary claim by posting a bond. The claim is considered true unless it is successfully disputed within a challenge window, with UMA’s DVM acting as the final arbiter for disputes.
- Roles:
- owner: GovernorV2
Value Secured 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.