Search

Search for projects by name or address

SummaryVolume and flowsDescriptionTop tokens by volumeTransfersUpdatesPermissionsSmart contracts

Across logo
Across

1 recent update

About

Intent framework specialised on popular chains and assets, speed and security.

    Last 24h volume
    $46.64 M
    Last 24h transfer count
    36.24 K
    Last 24h top path
    baseethereum$12.62 M
    Last 24h avg. transfer time
    12s
    Last 24h avg. transfer value
    $1.28 K
    Tokens by volume
    ETHUSDCUSDG
    +6
    Transfer size
    Under $100
    $100-$1K
    $1K-$10K
    $10K-$100K
    Over $100K
    Transfer type distribution
    Non-minting

    About

    Intent framework specialised on popular chains and assets, speed and security.

    Top token

    ETH
    ETH
    Volume
    $28.74 M
    Transaction count
    21.48 K
    Volume and flows
    Description

    Intent framework specialised on popular chains and assets, speed and security.

    Crosschain transfer flow

    The user initiates a transfer (sometimes called an intent) by depositing into the local chain “SpokePool” contract. The deposit specifies the recipient, the destination chain, the amount, the input token, the output token, a fill deadline by which the destination chain transfer must complete, and an optional exclusivity window during which only a chosen relayer can fill. User funds remain in the SpokePool; the deposit’s parameters are not persisted in contract storage but only captured in a FundsDeposited event log, which relayers index offchain to learn about deposits.

    Relayers fill a crosschain request by calling the destination chain’s SpokePool. During the exclusivity window only the chosen relayer can fill; after it expires anyone can. No fill is accepted past the fill deadline. Funds go to the user and the relay hash is marked Filled in the SpokePool’s fillStatuses mapping to prevent double-fills.

    Across V5 Gateway executions

    Deposits tagged with a special message prefix commit to an execution in the new Gateway contract and can only be filled through it: regular fills and the slow-fill path are blocked for them, and unfilled V5 deposits are refunded on the origin chain after the fill deadline like any other deposit. A V5 user signs a Merkle tree of alternative execution paths (e.g. different destination chains or routes) instead of one fixed order. Any solver can then execute one of the committed paths through the Gateway, which pulls the user’s funds via standing token approvals or signed permits (Permit2, EIP-3009, ERC-2612) and runs the committed steps, of which the bridge fill can be one among several (e.g. swaps). The destination SpokePool validates the fill against the user’s committed bounds (recipient, output token, minimum output amount) and pulls the output tokens from the standing approvals of the solver, who is then repaid through the unchanged root bundle settlement. The Gateway can be upgraded without delay by a multisig, which puts standing token approvals to the Gateway (and, transitively, relayers’ standing approvals to the SpokePools) at risk if it is compromised.

    Relayer repayments

    When a crosschain transfer is fulfilled, the relayer specifies on which chain and to which address they want to be repaid. A whitelisted proposer periodically posts a “root bundle” to the HubPool containing how much the protocol owes to each relayer (relayer refunds) and the pool rebalances needed so that there is enough liquidity on each chain for the refunds to be paid. The correctness of these roots is crucial; otherwise relayers could lie about filling a transfer and capture user funds.

    Root bundles settle in two levels:

    1. Optimistic (Across-native): the proposer bonds 0.45 ABT (a simple ETH wrapper, not to be confused with the ACX governance token) and the root sits in a challenge period of 30m. If unchallenged, the bundle executes; UMA is not involved in this happy path.
    2. Dispute escalation (UMA): anyone can call disputeRootBundle() within the challenge period by posting an equal counter-bond. The disputed bundle is discarded immediately so a new proposal can be submitted, while the dispute itself is escalated to UMA’s optimistic oracle, which resolves via UMA token voting; the losing party loses their bond.

    For chains with a canonical L1 to L2 messenger, tokens and admin / refund messages move from the HubPool to each SpokePool through that chain’s canonical bridge via a per-chain adapter. For chains without one (BNB Smart Chain, HyperEVM, Plasma, Tempo, Tron, …), Across uses universal adapters: the HubPool writes the message calldata into the HubPoolStore on Ethereum, and the destination chain reads it by verifying a storage proof against Ethereum’s state through a light client contract on the destination. Tokens travel via LayerZero OFT, or via Circle CCTP for USDC.

    LPs can provide single-token liquidity to the HubPool to front relayer refunds across chains, earning yield from an LP fee captured on every transfer.

    Top tokens by volume
    Symbol
    Last 24h Volume
    Last 24h transfer count
    Last 24h avg. transfer time
    Last 24h avg. transfer value
    Transfers
    From
    To
    Timestamp
    Tokens
    Value
    Bridge
    Transfer time
    Chains
    Updates
    2026 August 25, 08:49 UTC
    High severity
    3changes

    7702 auth removed.

    7702 auth removed.

    EOA (eth:0x9A8f92a830A5cB89a3816e3D267CB7791c16b04D) {
    +++ description: None
    sourceHashes:
    - ["0x3e6b48b0583e724b7006fcec0d9a021abd698deb8f7699582cdfee96bd65db4f"]
    proxyType:
    - "EIP7702 EOA"
    + "EOA"
    values:
    - {"$implementation":"eth:0x69007702764179f14F51cdce752f4f775d74E139","accountId":"alchemy.sma-7702.1.0.0","entryPoint":"eth:0x0000000071727De22E5E9d8BAf0edAc6f37da032","getFallbackSignerData":["eth:0x9A8f92a830A5cB89a3816e3D267CB7791c16b04D",false]}
    }
    2026 August 17, 08:58 UTC
    High severity
    21changes

    Across V5 upgrade: new Gateway contract and two new fill entrypoints for v5 deposits. In executor mode, the SpokePool pulls the output tokens from the Gateway's current solver using the relayer's standing approvals to the SpokePool. The Gateway executes user-signed intent 'paths': anyone can submit one, and the Gateway pulls the depositor's funds via standing allowances or signed permits (Permit2 witness, EIP-3009, ERC-2612, EIP-712 transferFrom auths). It is owned and upgradable (no delay) by a new 3/5 'Across Gateway Multisig'.

    Across V5 upgrade: new Gateway contract and two new fill entrypoints for v5 deposits. In executor mode, the SpokePool pulls the output tokens from the Gateway’s current solver using the relayer’s standing approvals to the SpokePool.

    The Gateway executes user-signed intent ‘paths’: anyone can submit one, and the Gateway pulls the depositor’s funds via standing allowances or signed permits (Permit2 witness, EIP-3009, ERC-2612, EIP-712 transferFrom auths). It is owned and upgradable (no delay) by a new 3/5 ‘Across Gateway Multisig’.

    contract Ethereum_SpokePool (eth:0x5c7BCd6E7De5423a257D81B442095A1a6ced35C5) [acrossv3/SpokePool] {
    +++ description: 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. Since the V5 upgrade, deposits tagged with a special message prefix can only be filled through the Across V5 Gateway, which authenticates the fill and identifies the relayer paying for it.
    sourceHashes.1:
    - "0x7c82111265c69f8a894d8029e30766541164d55fb1e814bf29ddacecaeee12c1"
    + "0x667fb3db67749e9488a6511b73f11c5acfa08bd66fa64944fe1d3064fa551c6e"
    values.$implementation:
    - "eth:0x5E5B726C81f43B953a62AD87E2835C85c4D9Dd3B"
    + "eth:0x456Ac26E5ec083EE9889eBa0d1a0A582502B8e84"
    values.$pastUpgrades.11:
    + ["2026-08-14T18:02:35.000Z","0x8149765132e15fb4f1dce1cab83f087ca099d778fee49191dff408069b734ad3",["eth:0x456Ac26E5ec083EE9889eBa0d1a0A582502B8e84"]]
    values.$upgradeCount:
    - 11
    + 12
    values.gateway:
    + "eth:0x998d7c178A1F9607b47eA3A8e22426451b3ce707"
    values.V5_MAGIC_PREFIX:
    + "0x89ae4bc75915265a3f10e926c3894a29534f1d6362ee8959cb0e5be00f3527fd"
    implementationNames.eth:0x5E5B726C81f43B953a62AD87E2835C85c4D9Dd3B:
    - "Ethereum_SpokePool"
    implementationNames.eth:0x456Ac26E5ec083EE9889eBa0d1a0A582502B8e84:
    + "Ethereum_SpokePool"
    }
    contract OP_SpokePool (oeth:0x6f26Bf09B1C792e3228e5467807a900A503c0281) [acrossv3/SpokePool] {
    +++ description: 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. Since the V5 upgrade, deposits tagged with a special message prefix can only be filled through the Across V5 Gateway, which authenticates the fill and identifies the relayer paying for it.
    name:
    - "Optimism_SpokePool"
    + "OP_SpokePool"
    sourceHashes.1:
    - "0xa7af88e42066dce1580a5c39e3bd045de8511f8a453056cd46140e3df8b96f19"
    + "0x63512362033eb12727887f57a9397e800b1fa1b98ff0fe2742abe67f53d493f1"
    values.$implementation:
    - "oeth:0x0966F5034261CC50926fB9D5C1603A5034Ffa81c"
    + "oeth:0x60674c53a4cC4ED350659C95fb8020B5AC61cA1D"
    values.$pastUpgrades.15:
    + ["2026-08-14T17:51:57.000Z","0x5ef940d028891d65c1ab1383d1cf63e514e1906c1a4f7483c1bdb6e2b9ca39bd",["oeth:0x60674c53a4cC4ED350659C95fb8020B5AC61cA1D"]]
    values.$upgradeCount:
    - 15
    + 16
    values.gateway:
    + "oeth:0x998d7c178A1F9607b47eA3A8e22426451b3ce707"
    values.V5_MAGIC_PREFIX:
    + "0x89ae4bc75915265a3f10e926c3894a29534f1d6362ee8959cb0e5be00f3527fd"
    implementationNames.oeth:0x0966F5034261CC50926fB9D5C1603A5034Ffa81c:
    - "Optimism_SpokePool"
    implementationNames.oeth:0x60674c53a4cC4ED350659C95fb8020B5AC61cA1D:
    + "OP_SpokePool"
    }
    + Status: CREATED
    contract Across Gateway Multisig (eth:0x4c45F70B1d9a7A6D1984daccAd74D0E973B73F01) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract Gateway (eth:0x998d7c178A1F9607b47eA3A8e22426451b3ce707) [acrossv3/Gateway]
    +++ description: Entry point for Across V5 intent executions. Anyone can submit a user-signed execution path: the Gateway pulls the depositor's funds via standing token approvals or signed permits (Permit2 witness permits, EIP-3009, ERC-2612, EIP-712 transfer authorizations), then calls the committed executor. While executing, it exposes the execution context (submitter, executor, step commitment) that the SpokePool trusts to authenticate V5 fills.
    + Status: CREATED
    contract Gateway (oeth:0x998d7c178A1F9607b47eA3A8e22426451b3ce707) [acrossv3/Gateway]
    +++ description: Entry point for Across V5 intent executions. Anyone can submit a user-signed execution path: the Gateway pulls the depositor's funds via standing token approvals or signed permits (Permit2 witness permits, EIP-3009, ERC-2612, EIP-712 transfer authorizations), then calls the committed executor. While executing, it exposes the execution context (submitter, executor, step commitment) that the SpokePool trusts to authenticate V5 fills.
    + Status: CREATED
    contract Across Gateway Multisig (oeth:0xd396CcB6770EAB84045c9Bce2939c478639E2A7F) [GnosisSafe]
    +++ description: None
    2026 August 12, 12:20 UTC
    7changes

    More pool rebalance routes were disabled (see below for explanation).

    More pool rebalance routes were disabled (see below for explanation).

    contract HubPool (eth:0xc186fA914353c44b2E33eBE05f21846F1048bEda) [acrossv3/HubPool] {
    +++ description: 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.
    values.poolRebalanceRoutes.Ethereum.4.destinationToken:
    - "eth:0x6B175474E89094C44Da98b954EedeAC495271d0F"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.Lens.0.destinationToken:
    - "eth:0xE5ecd226b3032910CEaa43ba92EE8232f8237553"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.Lens.2.destinationToken:
    - "eth:0x88F08E304EC4f90D644Cec3Fb69b8aD414acf884"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.ZKsync Era.0.destinationToken:
    - "eth:0x3355df6D4c9C3035724Fd0e3914dE96A5a83aaf4"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.ZKsync Era.1.destinationToken:
    - "eth:0x493257fD37EDB34451f62EDf8D2a0C418852bA4C"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.ZKsync Era.2.destinationToken:
    - "eth:0xBBeB516fb02a01611cBBE0453Fe3c580D7281011"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.ZKsync Era.3.destinationToken:
    - "eth:0x5AEa5775959fBC2557Cc8789bC1bf90A239D9a91"
    + "eth:0x0000000000000000000000000000000000000000"
    }
    2026 August 10, 08:52 UTC
    4changes

    More pool rebalance routes across ten destination chains were disabled (see below for explanation).

    More pool rebalance routes across ten destination chains were disabled (see below for explanation).

    contract HubPool (eth:0xc186fA914353c44b2E33eBE05f21846F1048bEda) [acrossv3/HubPool] {
    +++ description: 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.
    values.poolRebalanceRoutes.Ink.1.destinationToken:
    - "eth:0x2D270e6886d130D724215A266106e6832161EAEd"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.Blast.0.destinationToken:
    - "eth:0x4300000000000000000000000000000000000004"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.Blast.1.destinationToken:
    - "eth:0xF7bc58b8D8f97ADC129cfC4c9f45Ce3C0E1D2692"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.Blast.2.destinationToken:
    - "eth:0x4300000000000000000000000000000000000003"
    + "eth:0x0000000000000000000000000000000000000000"
    }
    2026 July 29, 11:39 UTC
    13changes

    13 pool rebalance routes across ten destination chains were disabled by setting their destination token to the zero address. HubPool rejects root-bundle execution for disabled routes, so these token/chain pairs can no longer be used for pool rebalances and relayer refunds.

    13 pool rebalance routes across ten destination chains were disabled by setting their destination token to the zero address. HubPool rejects root-bundle execution for disabled routes, so these token/chain pairs can no longer be used for pool rebalances and relayer refunds.

    contract HubPool (eth:0xc186fA914353c44b2E33eBE05f21846F1048bEda) [acrossv3/HubPool] {
    +++ description: 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.
    values.poolRebalanceRoutes.OP Mainnet.1.destinationToken:
    - "eth:0x0b2C639c533813f4Aa9D7837CAf62653d097Ff85"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.Unichain.1.destinationToken:
    - "eth:0x078D782b760474a361dDA0AF3839290b0EF57AD6"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.Polygon PoS.1.destinationToken:
    - "eth:0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.Polygon PoS.7.destinationToken:
    - "eth:0xc2132D05D31c914a87C6611C10748AEb04B58e8F"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.Monad.0.destinationToken:
    - "eth:0x754704Bc059F8C67012fEd69BC8A327a5aafb603"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.Monad.1.destinationToken:
    - "eth:0xe7cd86e13AC4309349F30B3435a9d337750fC82D"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.World Chain.2.destinationToken:
    - "eth:0x79A02482A880bCE3F13e09Da970dC34db4CD24d1"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.HyperEVM.0.destinationToken:
    - "eth:0xb88339CB7199b77E23DB6E890353E22632Ba630f"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.Base.1.destinationToken:
    - "eth:0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.Plasma.0.destinationToken:
    - "eth:0xB8CE59FC3717ada4C02eaDF9682A9e934F625ebb"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.Arbitrum One.1.destinationToken:
    - "eth:0xaf88d065e77c8cC2239327C5EDb3A432268e5831"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.Arbitrum One.7.destinationToken:
    - "eth:0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9"
    + "eth:0x0000000000000000000000000000000000000000"
    values.poolRebalanceRoutes.Solana.0.destinationToken:
    - "eth:0xaBc97431B1Bbe4C2D2f6E0E47ca60203452f5d61"
    + "eth:0x0000000000000000000000000000000000000000"
    }
    Permissions

    Ethereum

    Actors:

    OptimisticGovernor0x8692…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 upgrade with 2d delay
      • Ethereum_SpokePool
      • OP_SpokePool
    • Can interact with AcrossConfigStore
      • update configuration values with 2d delay
    • Can interact with AdapterStore
      • set the token-to-messenger mappings that adapters use to route OFT cross-chain transfers with 2d delay
    • Can interact with Ethereum_SpokePool
      • relay and delete root bundles, pause the contract, manage routes, set the withdrawal recipient (crosschain rebalancing target) with 2d delay
    • Can interact with OptimisticGovernor
      • set guard, avatar, target, delay, identifier, escalationManager, bond token and amount with 2d delay
    • 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) with 2d delay
    • Can interact with AcrossBondToken (ABT)
      • manage the proposer role with 2d delay
    • Can interact with OP_SpokePool
      • relay and delete root bundles, pause the contract, manage routes, set the withdrawal recipient (crosschain rebalancing target) with 2d delay
    Across Multisig0xB524…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 upgrade with no delay
      • Ethereum_SpokePool
      • OP_SpokePool
    • Can interact with AcrossConfigStore
      • update configuration values
    • Can interact with AdapterStore
      • set the token-to-messenger mappings that adapters use to route OFT cross-chain transfers
    • Can interact with Ethereum_SpokePool
      • relay and delete root bundles, pause the contract, manage routes, set the withdrawal recipient (crosschain rebalancing target)
    • 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)
    • Can interact with OP_SpokePool
      • relay and delete root bundles, pause the contract, manage routes, set the withdrawal recipient (crosschain rebalancing target)

    Participants (5):

    0x72b3…E7660x8372…c5fe0x9962…65e90xcc40…e37d0x868C…FD34
    GovernorV20x7b29…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
    Across Gateway Multisig0x4c45…3F01

    A Multisig with 3/5 threshold.

    • Can upgrade with no delay
      • Gateway

    Participants (5):

    0x8372…c5fe0x2B9C…AE030x9962…65e90xe767…BDB40x4851…609e
    Gateway0x998d…e707

    Entry point for Across V5 intent executions. Anyone can submit a user-signed execution path: the Gateway pulls the depositor’s funds via standing token approvals or signed permits (Permit2 witness permits, EIP-3009, ERC-2612, EIP-712 transfer authorizations), then calls the committed executor. While executing, it exposes the execution context (submitter, executor, step commitment) that the SpokePool trusts to authenticate V5 fills.

    • Can interact with Ethereum_SpokePool
      • authenticate fills of V5-tagged deposits: only calls from this contract’s live execution context can fill them, and executor-mode fills pull the output tokens from the standing token approvals that the current submitter (relayer) granted to the SpokePool
    ProposerV20x50ef…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
    UMA Multisig0x8180…A44a

    A Multisig with 2/4 threshold.

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

    Participants (4):

    0x3636…9Bf50xcc40…e37d0x72b3…E7660x8372…c5fe
    EmergencyProposer0x91F1…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
    EOA 10xf7bA…997c
    • Can interact with AcrossBondToken (ABT)
      • propose new root bundles to the HubPool by posting an ABT bond. Proposals settle optimistically; only disputes (via disputeRootBundle()) escalate to UMA token voting
    EOA 30x2bAa…cE25
    • Can interact with Store
      • withdraw fees

    OP Mainnet

    Actors:

    Gateway0x998d…e707

    Entry point for Across V5 intent executions. Anyone can submit a user-signed execution path: the Gateway pulls the depositor’s funds via standing token approvals or signed permits (Permit2 witness permits, EIP-3009, ERC-2612, EIP-712 transfer authorizations), then calls the committed executor. While executing, it exposes the execution context (submitter, executor, step commitment) that the SpokePool trusts to authenticate V5 fills.

    • Can interact with OP_SpokePool
      • authenticate fills of V5-tagged deposits: only calls from this contract’s live execution context can fill them, and executor-mode fills pull the output tokens from the standing token approvals that the current submitter (relayer) granted to the SpokePool
    Across Gateway Multisig0xd396…2A7F

    A Multisig with 3/5 threshold.

    • Can upgrade with no delay
      • Gateway

    Participants (5):

    0x8372…c5fe0x2B9C…AE030x9962…65e90xe767…BDB40x4851…609e
    EOA 20x0000…0000
    • Can upgrade with no delay
      • OP_SpokePool
    Smart contracts
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    Ethereum

    HubPoolStore0x1Ace…0E61

    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.

    AcrossConfigStore0x3B03…43f5

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

    • Roles:
      • owner: Across Multisig; ultimately OptimisticGovernor
    AdapterStore0x42df…D63b

    A helper contract for chain adapters on the hub chain that support OFT messaging. Handles token -> messenger mapping.

    • Roles:
      • owner: Across Multisig; ultimately OptimisticGovernor
    Ethereum_SpokePool0x5c7B…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. Since the V5 upgrade, deposits tagged with a special message prefix can only be filled through the Across V5 Gateway, which authenticates the fill and identifies the relayer paying for it.

    • Roles:
      • crossDomainAdmin: HubPool; ultimately Across Multisig, OptimisticGovernor
      • gateway: Gateway
    Can be upgraded by:
    OptimisticGovernor with 2d delayAcross Multisig with no delay
    HubPool0xc186…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 30m and a bond amount of 0.45 ABT.

    • Roles:
      • owner: Across Multisig; ultimately OptimisticGovernor
    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 1
    VotingV20x0043…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
    Registry0x3e53…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
    Finder0x40f9…77c3

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

    • Roles:
      • owner: GovernorV2
    Store0x54f4…57BF

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

    • Roles:
      • owner: GovernorV2
      • withdrawer: EOA 3
    FixedSlashSlashingLibrary0x9a40…e5cd

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

    IdentifierWhitelist0xcF64…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
    AddressWhitelist0xdBF9…58c7

    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
    SkinnyOptimisticOracle0xeE3A…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.

    OptimisticOracleV30xfb55…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
    Zora_Adapter0x024F…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_Adapter0x0c9d…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.

    HyperEVM_Adapter0x0ec7…4D2B

    This adapter can be used to send messages / root bundles to HyperEVM. 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 and USDC via CCTP.

    Redstone_Adapter0x188F…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.

    Avalance_Adapter0x1af6…1838

    This adapter can be used to send messages / root bundles to chains that do not have a canonical adapter. 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 and USDC via CCTP.

    Scroll_Adapter0x2DA7…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_Adapter0x33B0…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.

    Optimism_Adapter0x3562…ebE5

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

    Tempo_Adapter0x4577…A57c

    This adapter can be used to send messages / root bundles to Tempo. 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 and USDC via CCTP.

    Ethereum_Adapter0x527E…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.

    Polygon_Adapter0x537a…E655

    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_Adapter0x545E…70B5

    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_Adapter0x5A44…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.

    Lens_Adapter0x5e0B…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.

    BNBSmartChain_Adapter0x6f1C…084b

    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.

    Alephzero_Adapter0x6F40…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.

    Base_Adapter0x799B…897f

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

    Unichain_Adapter0x8956…A0D1

    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_Adapter0x8bbd…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.

    Solana_Adapter0x9F78…D7B3

    Adapter for Solana. Uses CCTP v1 AMB to relay root bundles to the Solana spokepool.

    Tron_Adapter0xA1da…c3Db

    This adapter can be used to send messages / root bundles to Tron. 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 and USDC via CCTP.

    ZkSyncEra_Adapter0xA374…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.

    Plasma_Adapter0xb47f…2363

    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.

    Universal_Adapter
    2 instances
    0xbc5E…c6780xCA5f…7eBD

    This adapter can be used to send messages / root bundles to chains that do not have a canonical adapter. 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 and USDC via CCTP.

    Arbitrum_Adapter0xc0b6…79B3

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

    Monad_Adapter0xC29a…8452

    This adapter can be used to send messages / root bundles to chains that do not have a canonical adapter. 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 and USDC via CCTP.

    MegaETH_Adapter0xE1f0…78Ac

    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_Adapter0xF039…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_Adapter0xf1B5…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_Adapter0xF2bE…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.

    OP Mainnet

    OP_SpokePool0x6f26…0281Implementation (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. Since the V5 upgrade, deposits tagged with a special message prefix can only be filled through the Across V5 Gateway, which authenticates the fill and identifies the relayer paying for it.

    • Roles:
      • admin: EOA 2
      • crossDomainAdmin: HubPool; ultimately Across Multisig, OptimisticGovernor
      • gateway: Gateway
    Can be upgraded by:
    OptimisticGovernor with 2d delayAcross Multisig with no delayEOA 2 with no delay