Search

Search for projects by name or address

SummaryUpdatesPermissionsSmart contracts

Relay logo
Relay

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...

    Last 24h volume
    —
    Last 24h transfer count
    0
    Last 24h top path
    —
    Last 24h avg. transfer time
    No data
    Last 24h avg. transfer value
    —
    Tokens by volume
    Transfer size
    Under $100
    $100-$1K
    $1K-$10K
    $10K-$100K
    Over $100K
    Transfer type distribution

    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...

    Top token

    —
    Volume
    —
    Transaction count
    —
    Updates
    2026 August 14, 13:46 UTC
    4changes

    Discovery rerun on the same block number with only config-related changes.

    Discovery rerun on the same block number with only config-related changes.

    Initial discovery

    + Status: CREATED
    contract RelayDepository (base:0x4cD00E387622C35bDDB9b4c962C136462338BC31) [relay/RelayDepository]
    +++ 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).
    + Status: CREATED
    contract RelayReceiver (base:0xa5F565650890fBA1824Ee0F21EbBbF660a179934) [relay/RelayReceiver]
    +++ 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.
    + Status: CREATED
    contract RelayRouterV3 (base:0xb92fe925DC43a0ECdE6c8b1a2709c170Ec4fFf4f) [relay/RelayRouterV3]
    +++ 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.
    + Status: CREATED
    contract RelayApprovalProxyV3 (base:0xCcC88a9d1B4ED6b0EABA998850414b24f1c315bE) [relay/RelayApprovalProxyV3]
    +++ 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.
    Permissions

    Base Chain

    Actors:

    EOA 10x463c…F56E
    • Can interact with RelayApprovalProxyV3
      • withdraw funds stuck in the RelayApprovalProxyV3 (not user approvals)
    EOA 20x63C1…1b56
    • Can interact with RelayDepository
      • sign arbitrary CallRequests that the RelayDepository executes, which moves any funds escrowed in it
    EOA 30xF61A…775A
    • 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 40xf70d…dbEF
    • 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

    RelayDepository0x4cD0…BC31

    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
    RelayReceiver0xa5F5…9934

    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
    RelayRouterV30xb92f…Ff4f

    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.

    RelayApprovalProxyV30xCcC8…15bE

    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