Search
Search for projects by name or address
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 hashA fixed-length fingerprint of variable-size input, produced by a hash function. 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 treeA hash-based data structure in which each leaf node is a hash of a block of data, and each non-leaf node is a hash of its children. The root of the tree is a cryptographic fingerprint of the entire data structure. Merkle trees (Merkle Patricia Tries) are used in Ethereum to efficiently store key-value pairs. 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 bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a 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 settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals.. 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 proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. 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 periodIn optimistic rollups, the window of time wherein network participants can assert that some fraud was included in a prior block. Most optimistic rollups currently specify a challenge window of 7 days. By extending the period, there is more time for participants to guard against fraud (invalid state transitions), but also more time until withdrawals gets enabled. 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 L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. to L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. 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, PlasmaPlasma is an offchain scaling solution that is able to support offchain data availability by allowing users to exit even when the data is unavailable. Usually, though, Plasma projects require users to frequently monitor the chain (e.g. at least once per week) to ensure that they can exit in time if necessary. There are attempts to support general smart contracts, but the exit mechanism is often limited to simpler applications., 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 clientSometimes labelled interchangeably as a “node”, they are tasked with processing transactions and managing the blockchains's state. They run the computations for each transaction according to the rollup's virtual machine and protocol rules. If comparing to Ethereum clients, these would be execution clients such as Geth, as opposed to consensus clients. 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 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Symbol | Last 24h
Volume | Last 24h
transfer count | Last 24h avg.
transfer time | Last 24h avg.
transfer value | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Symbol | Last 24h
Volume | Last 24h
transfer count | Last 24h avg.
transfer time | Last 24h avg.
transfer value | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Timestamp | Tokens | Value | Bridge | Transfer time | Chains | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Timestamp | Tokens | Value | Bridge | Transfer time | Chains | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Timestamp | Tokens | Value | Bridge | Transfer time | Chains | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
2026 September 15, 11:28 UTCHigh severity7changesSome rebalance routes removed (this allowed relayers to get refunded in these token/chain combinations) and 7702 delegation.
Some rebalance routes removed (this allowed relayers to get refunded in these token/chain combinations) and 7702 delegation.
| EOA (eth:0x9A8f92a830A5cB89a3816e3D267CB7791c16b04D) { | |
| +++ description: None | |
| proxyType: | |
| - | "EOA" |
| + | "EIP7702 EOA" |
| sourceHashes: | |
| + | ["0x1f44812af62d28f019e30e8eb2af596fb36c7db9d34576972c0405e110a6ef45"] |
| values: | |
| + | {"$implementation":"eth:0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B","delegationManager":"eth:0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3","DOMAIN_VERSION":"1","eip712Domain":{"fields":"0x0f","name":"EIP7702StatelessDeleGator","version":"1","chainId":1,"verifyingContract":"eth:0x9A8f92a830A5cB89a3816e3D267CB7791c16b04D","salt":"0x0000000000000000000000000000000000000000000000000000000000000000","extensions":[]},"entryPoint":"eth:0x0000000071727De22E5E9d8BAf0edAc6f37da032","getDeposit":0,"getDomainHash":"0x3818b9766109877e09a9c427e7b310cde355550731129529095a7e6b02cf55ab","getNonce":0,"NAME":"EIP7702StatelessDeleGator","PACKED_USER_OP_TYPEHASH":"0xbc37962d8bd1d319c95199bdfda6d3f92baa8903a61b32d5f4ec1f4b36a3bc18","VERSION":"1.3.0"} |
| } | |
| 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.Mode.0.destinationToken: | |
| - | "eth:0x4200000000000000000000000000000000000006" |
| + | "eth:0x0000000000000000000000000000000000000000" |
| values.poolRebalanceRoutes.Mode.1.destinationToken: | |
| - | "eth:0xd988097fb8612cc24eeC14542bC03424c656005f" |
| + | "eth:0x0000000000000000000000000000000000000000" |
| values.poolRebalanceRoutes.Mode.2.destinationToken: | |
| - | "eth:0xf0F161fDA2712DB8b566946122a5af183995e2eD" |
| + | "eth:0x0000000000000000000000000000000000000000" |
| values.poolRebalanceRoutes.Mode.3.destinationToken: | |
| - | "eth:0xcDd475325D6F564d27247D1DddBb0DAc6fA0a5CF" |
| + | "eth:0x0000000000000000000000000000000000000000" |
| } | |
2026 August 25, 08:49 UTCHigh severity3changes7702 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 UTCHigh severity21changesAcross 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 UTC7changesMore 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 UTC4changesMore 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" |
| } | |
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
- OP_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 proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. role with 2d delay Across Multisig 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 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
- OP_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 proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. role
- Can interact with OP_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
A Multisig with 3/5 threshold.
- Can upgrade with no delay
- Gateway
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
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
OP Mainnet
Actors:
A Multisig with 3/5 threshold.
- Can upgrade with no delay
- Gateway
- Can upgrade with no delay
- OP_SpokePool
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
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 bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. transfer. It also receives settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. 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
The central L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. contract (hub) that manages liquidity from LPs and coordinates cross-chain settlements. It receives and secures settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. proposals (root bundles) using the UMA Optimistic Oracle, with a challenge periodIn optimistic rollups, the window of time wherein network participants can assert that some fraud was included in a prior block. Most optimistic rollups currently specify a challenge window of 7 days. By extending the period, there is more time for participants to guard against fraud (invalid state transitions), but also more time until withdrawals gets enabled. 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 bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. messages by allowing proposers to make bonded assertions about crosschain events. It enforces a challenge periodIn optimistic rollups, the window of time wherein network participants can assert that some fraud was included in a prior block. Most optimistic rollups currently specify a challenge window of 7 days. By extending the period, there is more time for participants to guard against fraud (invalid state transitions), but also more time until withdrawals gets enabled. 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 settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. 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 settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. 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 settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. 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 settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. 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 settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. 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 settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
This adapter can be used to send messages / root bundles to PlasmaPlasma is an offchain scaling solution that is able to support offchain data availability by allowing users to exit even when the data is unavailable. Usually, though, Plasma projects require users to frequently monitor the chain (e.g. at least once per week) to ensure that they can exit in time if necessary. There are attempts to support general smart contracts, but the exit mechanism is often limited to simpler applications. 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 settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. 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 settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. between the HubPool and various SpokePools and their Relayers, often via canonical bridges.
Modular, chain-specific contract that abstracts the communication logic for settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. 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 bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. transfer. It also receives settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. 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