# Relay

Markdown version of https://l2beat.com/interop/protocols/relay

## Summary

- Last 24h volume: $139.90 M
- Last 24h transfer count: 440.97 K
- Last 24h top path: Robinhood Chain ↔ Solana ($22.91 M)
- Last 24h avg. transfer time: 5s
- Last 24h avg. transfer value: $568.35
- Last 24h tokens by volume: [USDC](https://l2beat.com/interop/tokens/9HN5PN/circle/usdc) ($73.99 M), [ETH](https://l2beat.com/interop/tokens/C0Hmkq/ethereum/eth) ($21.72 M), [USDT](https://l2beat.com/interop/tokens/xxeNQv/tether/usdt) ($15.68 M), and 2085 more
- Last 24h top token: [USDC](https://l2beat.com/interop/tokens/9HN5PN/circle/usdc) ($73.99 M volume, 61.99 K transfers)
- Last 24h transfer size: Under $100: 176.65 K transfers, $100-$1K: 54.22 K transfers, $1K-$10K: 13.44 K transfers, $10K-$100K: 1.73 K transfers, Over $100K: 92 transfers (min under $0.01, average $568.35, max $3.74 M)
- Last 24h transfer type distribution: Non-minting: $139.90 M

### About

Intent-based centralized bridge optimised for speed, multichain and multiasset support. A centralized API quotes orders and Relay-operated solvers fill them from their own liquidity; the onchain footprint is minimal and settlement depends on a single allocator key per chain.

## Volume and flows

### Top chains by volume (last 24h)

A transfer counts toward the volume of both its source and its destination chain, so the chain volumes add up to more than the total volume.

- Ethereum: $63.16 M (77.76 K transfers)
- Solana: $52.05 M (342.62 K transfers)
- Robinhood Chain: $41.51 M (164.90 K transfers)
- and 23 more

### Top routes by volume (last 24h)

- Robinhood Chain → Solana: $12.89 M
- Ethereum → Polygon PoS: $11.29 M
- Solana → Robinhood Chain: $10.02 M
- Ethereum → Solana: $7.08 M
- Lighter → Ethereum: $6.19 M
- Solana → Ethereum: $5.09 M
- Polygon PoS → Ethereum: $4.88 M
- Base → Solana: $4.24 M
- Lighter → Arbitrum One: $4.19 M
- BNB Smart Chain → Solana: $4.18 M

The flows between chains are an interactive graph on [the HTML page](https://l2beat.com/interop/protocols/relay#interop-volume).

## Description

Intent-based centralized bridge optimised for speed, multichain and multiasset support. A centralized API quotes orders and Relay-operated solvers fill them from their own liquidity; the onchain footprint is minimal and settlement depends on a single allocator key per chain.

### Architecture

Relay is an intent-based, non-minting bridge and crosschain payments network with a deliberately minimal onchain footprint. Users request a quote from the centralized [Relay API](https://docs.relay.link/references/api/api_guides/bridging-integration-guide) and pay on the origin chain; a Relay solver then fills them on the destination chain from its own pre-positioned liquidity with a plain transfer, swap, or contract call. All order matching, pricing, and balance accounting happen offchain and on Relay-operated infrastructure — no contract on the origin or destination chain verifies any relationship between the user's payment and the solver's fill.

There are three origin-side payment paths. In the legacy flow, native tokens are sent to the `RelayReceiver`, which immediately forwards them to a solver address hardcoded at deployment and merely emits the order commitment as an event (ERC20s in this flow are transferred to the solver directly). In the router flow, the `RelayApprovalProxyV3` pulls user ERC20s (approvals, EIP-2612/ERC-3009 permits, or Permit2) into the stateless `RelayRouterV3`, which atomically executes the calls of the quote. In the settlement flow, funds are escrowed in the `RelayDepository` tagged with an order id — the contract keeps no balance accounting and only emits a deposit event.

### Crosschain validation and settlement

After filling, the solver asks the Relay Oracle — an offchain service run by Relay — to attest the origin deposit and destination fill. The attestation is submitted to an Oracle contract on the 'Relay Chain' (a Relay-operated sovereign EVM rollup posting data to Celestia), where a `Hub` contract credits the deposit to the solver's balance. Solvers replenish their capital by requesting a withdrawal from the `Allocator`, a contract on Aurora that uses NEAR's MPC 'chain signatures' network to produce a signed payload accepted by the `RelayDepository` on the target chain.

From the perspective of each deposit chain, this entire settlement stack reduces to a 1-of-1 trust assumption: `RelayDepository.execute()` performs arbitrary external calls authorized by a single signature from the registered `allocator` address — on Base a plain address without contract code — protected only by a nonce and an expiration. The claims that this key is threshold-MPC-managed, that withdrawals are bounded by solver balances on the Hub, and that a Security Council multisig on Aurora can suspend withdrawers, all live offchain or on other chains and are not verifiable or enforced by the Depository. Moreover, the Depository's `owner` — currently an EOA on Base — can replace the allocator at any time and without delay, taking direct control of all escrowed funds.

### Solvers

Filling is not permissionless: orders are filled by Relay-operated solver infrastructure, and withdrawal rights from the settlement protocol are granted by an `APPROVED_WITHDRAWER_ROLE` on the Aurora allocator. There is no onchain solver collateral or slashing; the user's destination outcome depends entirely on the solver filling correctly and quickly.

### User recovery

There is no onchain refund path in any of the three flows. Funds sent through the `RelayReceiver` or the router flow are with the solver in the same transaction, and funds escrowed in the `RelayDepository` can only leave via an allocator-signed call. Failed or unfillable orders depend on Relay's discretionary, oracle-attested refund process.

### Upgradeability and governance

None of the onchain contracts are proxies — the `RelayDepository`, `RelayReceiver`, `RelayRouterV3`, and `RelayApprovalProxyV3` are all immutable. This offers limited protection because the critical powers are held by keys rather than code: the Depository owner can swap the allocator (full control of the escrow), and the allocator key alone moves escrowed funds. The `RelayApprovalProxyV3` owner can only sweep funds stuck in that contract; user token approvals to it cannot be spent by the owner.

### Monitoring

Deposits emit events onchain (`RelayNativeDeposit`/`RelayErc20Deposit` in the Depository, `FundsForwardedWithData` in the RelayReceiver, `FundsMovement` in the router flow), but fills on the destination chain are ordinary transfers from solver liquidity and are not marked as protocol activity. Relay provides an [explorer](https://relay.link/transactions) and an [API](https://docs.relay.link/references/api/overview) for order tracking, and the Relay Chain acts as the protocol's crosschain accounting ledger.

## Top tokens by volume

The interactive tokens table is shown on [the HTML page](https://l2beat.com/interop/protocols/relay#interop-tokens).

## Transfers

The interactive transfers table is shown on [the HTML page](https://l2beat.com/interop/protocols/relay#interop-transfers).

## Updates

Each date links the update on the HTML page, which also shows its contract diffs.

### [2026-08-14 13:46 UTC](https://l2beat.com/interop/protocols/relay?update=6da1cba5) (4 changes)

Initial discovery of the Relay settlement protocol contracts.

## Permissions

### Base Chain

#### Actors

##### EOA 1

Addresses: [0x463cB782c8dd0a1887b77336DfF74D60F006F56E](https://basescan.org/address/0x463cB782c8dd0a1887b77336DfF74D60F006F56E)

- Can interact with RelayApprovalProxyV3
  - withdraw funds stuck in the RelayApprovalProxyV3 (not user approvals)

##### EOA 2

Addresses: [0x63C1d3E9C646184529C5694630a01C00dF171b56](https://basescan.org/address/0x63C1d3E9C646184529C5694630a01C00dF171b56)

- Can interact with RelayDepository
  - sign arbitrary CallRequests that the RelayDepository executes, which moves any funds escrowed in it

##### EOA 3

Addresses: [0xF61A305199fa1135d76FFaB3752D42F55cBd775A](https://basescan.org/address/0xF61A305199fa1135d76FFaB3752D42F55cBd775A)

- Can interact with RelayDepository
  - replace the allocator of the RelayDepository at any time and without delay, taking control of all funds escrowed in it

##### EOA 4

Addresses: [0xf70da97812CB96acDF810712Aa562db8dfA3dbEF](https://basescan.org/address/0xf70da97812CB96acDF810712Aa562db8dfA3dbEF)

- Can interact with RelayReceiver
  - receive all user funds deposited through the RelayReceiver, with no onchain obligation to fill the associated orders

## Smart contracts

### Base Chain

#### RelayDepository

Addresses: [0x4cD00E387622C35bDDB9b4c962C136462338BC31](https://etherscan.io/address/0x4cD00E387622C35bDDB9b4c962C136462338BC31#code)

Escrow entry point of the Relay settlement protocol: user deposits for crosschain intents are parked here, tagged only by an event that attributes them to an order id. The contract keeps no balance accounting and does not verify orders or fills - all accounting happens offchain and on the Hub contract on the Relay Chain. Funds leave the contract exclusively through execute(), which performs arbitrary external calls authorized by a single signature of the current allocator (replay-protected by nonce and expiration).
- Roles:
  - **allocator**: EOA 2
  - **owner**: EOA 3

#### RelayReceiver

Addresses: [0xa5F565650890fBA1824Ee0F21EbBbF660a179934](https://etherscan.io/address/0xa5F565650890fBA1824Ee0F21EbBbF660a179934#code)

Passthrough deposit contract of the legacy Relay flow: any native tokens sent to it are immediately forwarded to a solver address hardcoded at deployment, and the attached calldata is only emitted as an event that commits the payment to a Relay order id. The contract holds no funds and enforces nothing about the order - after the forward, the user's outcome depends entirely on the solver. ERC20 payments in this flow do not even touch this contract and are transferred to the solver directly.
- Roles:
  - **solver**: EOA 4

#### RelayRouterV3

Addresses: [0xb92fe925DC43a0ECdE6c8b1a2709c170Ec4fFf4f](https://etherscan.io/address/0xb92fe925DC43a0ECdE6c8b1a2709c170Ec4fFf4f#code)

Stateless multicall router used to atomically execute the calls of a Relay quote (swaps, bridge deposits, transfers to the solver). It has no owner and no privileged roles, and it is not supposed to hold funds between transactions: anyone can sweep balances left in it via the public cleanup functions.

#### RelayApprovalProxyV3

Addresses: [0xCcC88a9d1B4ED6b0EABA998850414b24f1c315bE](https://etherscan.io/address/0xCcC88a9d1B4ED6b0EABA998850414b24f1c315bE#code)

ERC20 entry point of the Relay v3 flow: it pulls user tokens (via direct approvals or EIP-2612 / ERC-3009 / Permit2 signatures) and forwards them to the RelayRouterV3, where the calls of the Relay quote are executed atomically. Token pulls are only possible from msg.sender or with the token owner's signature, so user approvals to this contract cannot be spent by its owner.
- Roles:
  - **owner**: EOA 1