{
"description": "Intent-based centralized EOA bridge optimised for speed, multichain and multiasset support.",
"detailedDescription": "# Architecture\nRelay is an intent-based, non-minting bridge. A user requests a route from the [Relay API](https://docs.relay.link/references/api/api_guides/bridging-integration-guide) and deposits their funds to simple smart contract or EOA on the source chain, and a solver fronts liquidity on the destination chain before settling back against the user's source-side payment. The destination transaction is a regular transfer, swap, or contract call made by the solver from their own pre-positioned liquidity.\n\nAfter a solver fills the user on the destination chain, the solver asks the centralized Relay Oracle to verify the source payment and destination fill. The Oracle reads chain data offchain and returns an attestation. The solver submits that attestation to the `RelayOracle` on the Relay Chain, which updates the `RelayHub`: the deposit is represented as Hub balance and that balance is transferred to the solver. Solvers then withdraw accumulated Hub balances through the `Allocator`, which produces a signed withdrawal payload accepted by the target-chain `Depository.execute(CallRequest, signature)`.\n\n# Crosschain oracle and validation\nThe destination-chain user outcome depends on the solver filling correctly and quickly, while settlement depends on Relay's centralized Oracle. Incorrect attestations can misattribute balances on the Hub and steal funds. The 'Allocator', which is the signing part of the relay oracle, uses the MPC signing framework on the NEAR blockchain.\n\n# Refunds\nThere are no onchain mechanisms for refunds, making them fully depend on the good will of solvers and the relay admins.\n\n# Monitoring\nRelay provides an [explorer](https://relay.link/transactions) and an [API](https://docs.relay.link/references/api/overview) to monitor transactions. There is a sovereign rollup on Celestia called 'relay chain' that acts as a ledger for the protocol's crosschain accounting.",
"contracts": {
"addresses": {
"base": [
{
"name": "RelayDepository",
"isVerified": true,
"address": "base:0x4cD00E387622C35bDDB9b4c962C136462338BC31",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "base",
"description": "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).\n* Roles:\n * **allocator**: EOA 2\n * **owner**: EOA 3",
"discoveryDrivenData": true
},
{
"name": "RelayReceiver",
"isVerified": true,
"address": "base:0xa5F565650890fBA1824Ee0F21EbBbF660a179934",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "base",
"description": "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.\n* Roles:\n * **solver**: EOA 4",
"discoveryDrivenData": true
},
{
"name": "RelayRouterV3",
"isVerified": true,
"address": "base:0xb92fe925DC43a0ECdE6c8b1a2709c170Ec4fFf4f",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "base",
"description": "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.\n",
"discoveryDrivenData": true
},
{
"name": "RelayApprovalProxyV3",
"isVerified": true,
"address": "base:0xCcC88a9d1B4ED6b0EABA998850414b24f1c315bE",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "base",
"description": "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.\n* Roles:\n * **owner**: EOA 1",
"discoveryDrivenData": true
}
]
},
"risks": []
},
"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.",
"detailedDescription": "# Architecture\n\nRelay 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.\n\nThere 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.\n\n# Crosschain validation and settlement\n\nAfter 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.\n\nFrom 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.\n\n# Solvers\n\nFilling 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.\n\n# User recovery\n\nThere 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.\n\n# Upgradeability and governance\n\nNone 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.\n\n# Monitoring\n\nDeposits 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.",
"intent": {
"color": "#14B8A6",
"intentModel": {
"value": "Intent framework",
"description": "Routes transfers through a relay-style execution network."
"description": "Users pay against a quote from the centralized Relay API and Relay solvers fill on the destination chain from their own liquidity."
},
"userRecovery": {
"value": "Request refund",
"sentiment": "bad",
"description": "There is no onchain refund option. Failed transfers depend on Relay-operated recovery."
},
"solverAccess": {
"value": "Internal",
"sentiment": "bad",
"description": "Transfers are filled by Relay-operated infrastructure."
},
"settlement": {
"value": "Internal",
"sentiment": "bad",
"description": "Settlement depends on Relay's centralized oracle and allocator flow."
"description": "Settlement depends on Relay's centralized oracle and allocator flow: escrowed deposits are released by a single allocator signature, and the escrow owner can replace the allocator without delay."
}
},
"permissions": {
"base": {
"roles": [],
"actors": [
{
"id": "EOA-1",
"name": "EOA 1",
"accounts": [
{
"address": "base:0x463cB782c8dd0a1887b77336DfF74D60F006F56E",
"type": "EOA",
"isVerified": true,
"name": "0x463c…F56E",
"url": "https://basescan.org/address/0x463cB782c8dd0a1887b77336DfF74D60F006F56E",
"displayName": "EOA 1"
}
],
"chain": "base",
"description": "* Can interact with RelayApprovalProxyV3\n * withdraw funds stuck in the RelayApprovalProxyV3 (not user approvals) ",
"discoveryDrivenData": true
},
{
"id": "EOA-2",
"name": "EOA 2",
"accounts": [
{
"address": "base:0x63C1d3E9C646184529C5694630a01C00dF171b56",
"type": "EOA",
"isVerified": true,
"name": "0x63C1…1b56",
"url": "https://basescan.org/address/0x63C1d3E9C646184529C5694630a01C00dF171b56",
"displayName": "EOA 2"
}
],
"chain": "base",
"description": "* Can interact with RelayDepository\n * sign arbitrary CallRequests that the RelayDepository executes, which moves any funds escrowed in it ",
"discoveryDrivenData": true
},
{
"id": "EOA-3",
"name": "EOA 3",
"accounts": [
{
"address": "base:0xF61A305199fa1135d76FFaB3752D42F55cBd775A",
"type": "EOA",
"isVerified": true,
"name": "0xF61A…775A",
"url": "https://basescan.org/address/0xF61A305199fa1135d76FFaB3752D42F55cBd775A",
"displayName": "EOA 3"
}
],
"chain": "base",
"description": "* Can interact with RelayDepository\n * replace the allocator of the RelayDepository at any time and without delay, taking control of all funds escrowed in it ",
"discoveryDrivenData": true
},
{
"id": "EOA-4",
"name": "EOA 4",
"accounts": [
{
"address": "base:0xf70da97812CB96acDF810712Aa562db8dfA3dbEF",
"type": "EOA",
"isVerified": true,
"name": "0xf70d…dbEF",
"url": "https://basescan.org/address/0xf70da97812CB96acDF810712Aa562db8dfA3dbEF",
"displayName": "EOA 4"
}
],
"chain": "base",
"description": "* Can interact with RelayReceiver\n * receive all user funds deposited through the RelayReceiver, with no onchain obligation to fill the associated orders ",
"discoveryDrivenData": true
}
]
}
},
"plugins": [
{
"plugin": "relay",
"bridgeType": "nonMinting"
}
],
"type": "intent"
}