Search

Search for projects by name

L2BEAT Bridges is a work in progress. You might find incomplete research or inconsistent naming. Join our Discord to suggest improvements!
SummaryValue SecuredDetailed descriptionRisk summaryTechnologyPermissionsSmart contracts

Across V3 logoAcross V3

About

Across V3 is a cross-chain optimistic bridge that uses actors called Relayers to fulfill user transfer requests (intents) on the destination chain.

  • Total value secured
  • Destination
  • Validated by
    Optimistically
  • Type
    Liquidity Network
    • Explore more in Discovery UI

    About

    Across V3 is a cross-chain optimistic bridge that uses actors called Relayers to fulfill user transfer requests (intents) on the destination chain.

    Value Secured

    2024 Jul 05 — 2025 Jul 05

    Detailed description

    Across V3 is a cross-chain 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 on Ethereum. Relayer reimbursements over a specific block range are bundled and posted onchain 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.

    Risk summary

    Funds can be lost if

    1. 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,
    2. third-party bridge infrastructure is compromised, such as canonical messaging services, Linea USDC bridge, and USDC Cross-Chain Transfer Protocol (CCTP) infrastructure,
    3. a re-org occurs on destination chain after the Optimistic Oracle dispute time passes.

    Funds can be frozen if

    1. owner pauses the Hub Pool contract, or changes bond, routes, or fees parameters in such a way as to make the escrow inoperable.
    Technology

    Principle of operation

    This bridge performs cross-chain swaps by borrowing liquidity from a network of Relayers who are later reimbursed on a chain of their choosing and 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). A permissioned proposer can then post an assertion to the HubPool on Ethereum. The content is a ‘root bundle’, which contains a merkle root of all Relayer reimbursements and an obligatory bond of 0.45 ABT (an ETH wrapper). It is validated optimistically in the HubPool contract and becomes executable after 1h (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 Optimistic Oracle.

    The UMA oracle 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.

    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 and others using adapters.

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

    1. Across V3 Architecture

    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 1h.

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

    1. Across V3 Optimistic Oracle documentation

    Destination tokens

    Only tokens that have been bridged using native chain bridges are supported.

    Permissions
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    Disco UI BannerExplore in Disco

    Ethereum

    Roles:

    Proposer EOA 2

    Can propose new root bundles (containing settlement info to refund relayers), which are validated optimistically by the UMA oracle.

    Actors:

    ProposerV2 0x50ef…E7cC

    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
    GovernorV2 0x7b29…3fa8

    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
    • 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
    UMA Multisig 0x8180…A44a

    A Multisig with 2/4 threshold.

    • Can interact with EmergencyProposer
      • remove proposals, execute emergency proposals

    Participants (4):

    0x3636…9Bf50xcc40…e37d0x1d93…9F050x8372…c5fe
    OptimisticGovernor 0x8692…8991

    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
    EmergencyProposer 0x91F1…6748

    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
    Across Multisig 0xB524…3715

    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)

    Participants (5):

    0x1d93…9F050x8372…c5fe0x9962…65e90xcc40…e37d0x868C…FD34
    EOA 1 0x2bAa…cE25
    • Can interact with Store
      • withdraw fees
    EOA 2 0xf7bA…997c
    • Can interact with AcrossBondToken (ABT)
      • use ABT as a bond to the HubPool contract for root bundle proposals
    • A Proposer - acting directly
    Smart contracts
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    Disco UI BannerExplore in Disco
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    Ethereum

    Ethereum_SpokePool 0x5c7B…35C5Implementation (Upgradable)Admin

    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.
    HubPool 0xc186…bEda

    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 1h and a bond amount of 0.45 ABT.

    • Roles:
      • owner: Across Multisig; ultimately OptimisticGovernor
    • This contract can store any token.
    Zora_Adapter 0x024F…169b

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    Soneium_Adapter 0x0c9d…5FD2

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    Arbitrum_Adapter 0x100E…7210

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    Redstone_Adapter 0x188F…73fA

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    Universal_Adapter 0x2200…0833

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    Scroll_Adapter 0x2DA7…60d8

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    Boba_Adapter 0x33B0…5Af3

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    Ethereum_Adapter 0x527E…5084

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    Linea_Adapter 0x5A44…2787

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    ZkStack_CustomGasToken_Adapter 0x5e0B…24Cf

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    Alephzero_Adapter 0x6F40…15Af

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    Ink_Adapter 0x7e90…61d2

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    WorldChain_Adapter 0x8bbd…58D1

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    ZkStack_Adapter 0xA374…724f

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    Polygon_Adapter 0xb4Ae…912e

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    Base_Adapter 0xE142…529c

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    Optimism_Adapter 0xE1e7…612b

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    Lisk_Adapter 0xF039…c73b

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    Mode_Adapter 0xf1B5…16d0

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    Blast_Adapter 0xF2bE…dD81

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    DoctorWho_Adapter 0xFADc…29Fa

    Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.

    VotingV2 0x0043…34ac

    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
    HubPoolStore 0x1Ace…0E61

    Simple data store used by the Universal_Adapter to store message calldata hashes.

    AcrossConfigStore 0x3B03…43f5

    Simple, owner-controlled contract for storing protocol-wide, token-specific configuration data.

    • Roles:
      • owner: Across Multisig; ultimately OptimisticGovernor
    Registry 0x3e53…13aE

    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
    Finder 0x40f9…77c3

    Maps interface names to contract addresses (UMA protocol contracts).

    • Roles:
      • owner: GovernorV2
    Store 0x54f4…57BF

    UMA protocol contract responsible for calculating and collecting regular and final fees for using the DVM.

    • Roles:
      • owner: GovernorV2
      • withdrawer: EOA 1
    FixedSlashSlashingLibrary 0x9a40…e5cd

    Stores slashing parameters and calculates slashing amounts based on that (UMA protocol).

    IdentifierWhitelist 0xcF64…e570

    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
    AddressWhitelist 0xdBF9…58c7

    Implements a simple address whitelist for tokens that can be used as bonds and fees.

    • Roles:
      • owner: GovernorV2
    AcrossBondToken (ABT) 0xee1D…02ea

    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
    SkinnyOptimisticOracle 0xeE3A…7c24

    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.

    OptimisticOracleV3 0xfb55…C0dE

    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:

    Generic escrow 0xc186…bEda

    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.