Architecture
The protocol consists of four core components:| Component | Role | Location |
|---|---|---|
| Depository | Holds user deposits on each origin chain | Every supported chain (80+) |
| Oracle | Verifies deposits and fills, attests to the Hub | Off-chain service |
| Hub | Tracks token ownership and solver balances | Relay Chain |
| Allocator | Generates withdrawal proofs for solvers | Relay Chain / MPC |
Flows
Every crosschain order in Relay passes through three sequential flows: Execution, Settlement, and Withdrawal.Execution Flow
Execution is the user-facing part of the process. The user deposits funds on the origin chain, and a solver fills their order on the destination chain. Step by step:- User requests a quote — The user specifies what they want (e.g., bridge 1 ETH from Optimism to Base). The Relay API returns quotes from available solvers.
- User deposits into Depository — The user sends funds to the Depository contract on the origin chain. The deposit is tagged with an orderId that links it to the solver’s commitment. This costs approximately 21,000 gas — close to a simple transfer.
- Solver fills on destination — The solver detects the deposit and executes the user’s requested action on the destination chain using their own capital. The fill can be a simple transfer, a swap, or any arbitrary onchain action.
Settlement Flow
Settlement is the process of verifying that the solver correctly filled the order, and crediting them on the Hub. Step by step:- Oracle reads origin chain — The Oracle reads the origin chain to verify that the user’s deposit occurred and matches the expected order.
- Oracle reads destination chain — The Oracle reads the destination chain to verify that the solver’s fill matches the user’s intent (correct destination, amount, and action).
-
Oracle attests to the Hub — The Oracle signs an EIP-712 attestation and submits it to the Hub contract on the Relay Chain. This attestation triggers two actions:
- MINT — The user’s deposit is represented as a token balance on the Hub
- TRANSFER — That balance is transferred from the user to the solver
- Solver balance updated — The solver’s balance on the Hub increases, reflecting the payment they are owed for the fill.
Settlement happens in real-time, per-order. There is no batching window. As soon as the Oracle verifies a fill, the solver’s balance is updated on the Hub.
Withdrawal Flow
Withdrawal is how solvers extract funds from the Depository to replenish their capital. Solvers accumulate balances on the Hub and can withdraw from any origin chain at any time. Step by step:- Solver requests withdrawal — The solver specifies which chain and asset they want to withdraw from, and the amount.
- Allocator verifies balance — The Allocator checks the solver’s balance on the Hub to confirm they have sufficient funds.
- Allocator generates proof — The Allocator creates a chain-specific cryptographic proof (EIP-712 signature for EVM chains, Ed25519 for Solana) authorizing the withdrawal from the Depository on the target chain.
- Solver submits proof — The solver submits the signed proof to the Depository contract on the target chain.
- Depository releases funds — The Depository verifies the signature, confirms the nonce hasn’t been used, and transfers the funds to the solver.
- Hub balance reduced — The Hub burns the corresponding token balance (via a BURN action from the Oracle), keeping the ledger in sync.
Revert Flow
If a solver fails to fill an order within the expected timeframe, the user’s funds are protected and can be returned. Step by step:- Order expires — If the solver doesn’t fill within the commitment window, the order is marked as expired.
- Oracle attests revert — The Oracle verifies that the fill did not occur and attests a revert to the Hub.
- User balance restored — The Hub restores the user’s token balance, effectively unlocking their deposit.
- User withdraws — The user (or the protocol on their behalf) can trigger a withdrawal from the Depository to reclaim their funds.