Relay

Architecture

Relay is an intent-based, non-minting 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. and crosschain payments networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. with a deliberately minimal onchain footprint. Users request a quote from the centralized Relay API 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 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. 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 rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign 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 CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. 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 permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants.: 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.

UpgradeabilityThe ability for rollup smart contracts and parameters used in a rollup to be updated by holders of an admin key. Upgradeability represents a vector of risk for users, and should be decentralized and combined with time delays for greater security guarantees. 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 and an API for order tracking, and the Relay Chain acts as the protocol’s crosschain accounting ledger.