Search
Search for projects by name or address
Across
About
Intent framework specialised on popular chains and assets, speed and security.
About
Intent framework specialised on popular chains and assets, speed and security.
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.
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:
- 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.
- 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.
Symbol | Last 24h
Volume | Last 24h
transfer count | Last 24h avg.
transfer time | Last 24h avg.
transfer value | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Timestamp | Tokens | Value | Transfer time | Chains | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Ethereum
Actors:
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 Across Multisig with 2d delay → HubPool
- Optimism_SpokePool Across Multisig with 2d delay → HubPool
- Can interact with AcrossConfigStore
- update configuration values with 2d delay Across Multisig 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 Across Multisig 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 Across Multisig with 2d delay → HubPool
- Can interact with OptimisticGovernor
- set guard, avatar, target, delay, identifier, escalationManager, bond token and amount with 2d delay Across Multisig 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 Across Multisig with 2d delay
- Can interact with AcrossBondToken (ABT)
- manage the proposer role with 2d delay Across Multisig with 2d delay
- Can interact with Optimism_SpokePool
- relay and delete root bundles, pause the contract, manage routes, set the withdrawal recipient (crosschain rebalancing target) with 2d delay Across Multisig with 2d delay → HubPool
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 HubPool
- Optimism_SpokePool HubPool
- 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) HubPool
- 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
- Can interact with Optimism_SpokePool
- relay and delete root bundles, pause the contract, manage routes, set the withdrawal recipient (crosschain rebalancing target) HubPool
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
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
A Multisig with 2/4 threshold.
- Can interact with EmergencyProposer
- remove proposals, execute emergency proposals
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
- 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
- propose new root bundles to the HubPool by posting an ABT bond. Proposals settle optimistically; only disputes (via
- Can interact with Store
- withdraw fees
OP Mainnet
Actors:
- Can upgrade with no delay
- Optimism_SpokePool
Ethereum
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.
Simple, owner-controlled contract for storing protocol-wide, token-specific configuration data.
- Roles:
- owner: Across Multisig; ultimately OptimisticGovernor
A helper contract for chain adapters on the hub chain that support OFT messaging. Handles token -> messenger mapping.
- Roles:
- owner: Across Multisig; ultimately OptimisticGovernor
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:
- crossDomainAdmin: HubPool; ultimately Across Multisig, OptimisticGovernor
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
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
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
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
UMA protocol contract responsible for calculating and collecting regular and final fees for using the DVM.
- Roles:
- owner: GovernorV2
- withdrawer: EOA 3
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
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
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.
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.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
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.
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.
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.
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.
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.
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.
Adapter for Solana. Uses CCTP v1 AMB to relay root bundles to the Solana spokepool.
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.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
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.
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.
Modular, chain-specific contract that abstracts the communication logic for settlement between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
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.
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.
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.
OP Mainnet
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: EOA 2
- crossDomainAdmin: HubPool; ultimately Across Multisig, OptimisticGovernor