- A dedicated low-cost settlement chain (Relay Chain)
- A custom Oracle that can read data from any chain / VM
- Programmable MPC signatures to write back to any chain / VM
Contracts
The protocol is coordinated through 3 main smart contracts:| Contract | Role | Location |
|---|---|---|
| Depository | Holds user deposits on each origin chain | Every supported chain (80+) |
| Hub | Tracks token ownership and solver balances | Relay Chain |
| Allocator | Generates MPC withdrawal payloads | Aurora (NEAR) |
Flows
Every crosschain order in Relay passes through three sequential flows: Execution, Settlement, and Withdrawal.1. 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.
2. Settlement Flow
Settlement is the process of verifying that the solver correctly filled the order, and crediting them on the Hub. Step by step:- Solver requests attestation — After filling an order, the solver calls the Oracle to request settlement.
- 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 returns attestation — Oracle validators each verify the data and sign an EIP-712 attestation. Once a threshold of signatures is collected, the signed attestation is returned to the solver.
-
Solver submits to Hub — The solver submits the signed attestations to the Oracle contract on the Relay Chain, which verifies the threshold and executes on the Hub. This 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
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.
3. 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 initiates withdrawal — The solver transfers their Hub balance to a deterministic withdrawal address — a virtual address derived from the withdrawal parameters (target chain, depository, currency, recipient, nonce). This transfer on the Hub signals the intent to withdraw.
- Solver requests attestation — The solver calls the Oracle to request a withdrawal attestation.
- Oracle reads Hub — The Oracle reads the Hub to verify the transfer to the withdrawal address and decodes the withdrawal parameters.
- Oracle returns attestation — Oracle validators each verify the data and return a signed attestation to the solver.
- Solver requests proof — The solver calls the Allocator with the attestation to request a withdrawal proof. The Allocator constructs a chain-specific payload via the appropriate Payload Builder.
- Allocator returns proof — The Allocator generates an MPC-signed cryptographic proof (EIP-712 for EVM, Ed25519 for Solana) that authorizes the withdrawal, and returns it to the solver.
- 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.
Refunds
Inevitably, some orders cannot be filled, and the user needs to be refilled. Relay is designed to make this experience as smooth as possible, with multiple supported pathways, depending on the circumstances:Fast Refund
If a solver can’t fill an order on the destination, they can instantly refund the user on the origin chain. The refund mirrors the execution flow — the solver detects the deposit and acts — but instead of filling on the destination, they return funds to the user on the origin. The refund is then settled like any other fill. Step by step:- User deposits into Depository — The user deposits funds into the Depository on the origin chain, tagged with an orderId.
- Solver detects deposit — The solver detects the deposit and evaluates whether it can fill the order.
- Solver simulates fill — The solver simulates the fill on the destination chain and determines it can’t be completed (e.g., insufficient liquidity, contract error).
- Solver refunds on origin — Instead of filling, the solver sends funds directly to the user on the origin chain, returning them immediately.
- Solver requests attestation — The solver calls the Oracle to request a refund attestation.
- Oracle reads origin chain — The Oracle reads the origin chain to verify the refund occurred and matched the order’s requirements.
- Oracle returns attestation — Validators sign and return the attestation to the solver.
- Solver submits to Hub — The solver submits the attestation to the Hub, which mints and transfers the balance to the solver — the same settlement process as a fill.
Slow Refund
If a solver can’t fill but the deposit hasn’t finalized yet on the origin chain, the solver waits for finalization before triggering the refund on the user’s behalf. This is slower than a fast refund but still doesn’t require user action. Step by step:- User deposits into Depository — The user deposits funds into the Depository on the origin chain, tagged with an orderId.
- Solver detects deposit — The solver detects the deposit and determines it can’t fill the order.
- Solver requests refund attestation — After the deposit finalizes on the origin chain, the solver calls the Oracle to request a refund attestation.
- Oracle reads origin chain — The Oracle reads the origin chain to verify the deposit and confirm the order was not filled.
- Oracle returns attestation — Validators sign and return the attestation to the solver.
- Solver submits to Hub — The solver submits the attestation to the Hub, which restores the user’s balance.
- Solver withdraws on user’s behalf — The solver triggers a withdrawal from the Depository, returning the user’s original deposit.
- User receives funds — The funds are returned to the user on the origin chain.
Slow refunds require the solver to wait for the deposit to finalize on the origin chain before initiating the refund. This adds latency but the user doesn’t need to take any action.
Self Refund
If a solver fails to fill and doesn’t refund, the user’s funds are still protected. After the order’s fill window expires, the user can trigger a self refund to reclaim their deposit. Solvers can also abandon an order early, which shortens the expiry window and allows the self refund to happen faster. Step by step:- User requests refund — After the fill window expires (or after the solver abandons), the user calls the Oracle to request a refund attestation. If the solver knows they can’t fill, they can abandon the order early — this signals intent to not fill and shortens the expiry window so the user gets their funds back faster.
- Oracle returns attestation — The Oracle verifies that the fill did not occur and returns a signed attestation to the user.
- User submits to Hub — The user submits the attestation to the Hub, which restores their token balance.
- User withdraws — The user (or the protocol on their behalf) triggers a withdrawal from the Depository to reclaim their funds.