LogoLogo
  • Introduction
    • What We Do
  • The DeFi Problem
  • How iLayer solves it
  • Use Cases
  • Architecture
    • RFQ
  • Hub & Spoke
    • OrderHub
    • OrderSpoke
  • Router
    • LayerZero Router
    • Axelar Router
    • NullRouter
    • AxLzRouter
  • Solvers
  • Integration
    • Industries
    • EVM Smart contracts
      • Example: cross-chain LPing on Aave
      • Example: cross-chain contract call
  • Audit
Powered by GitBook
On this page
Export as PDF

Hub & Spoke

iLayer smart contracts form the backbone of the iLayer network, enabling secure and trustless interactions between users and solver bots. They allow value exchange without counterparty risk through a locking mechanism similar to an atomic swap, mediated by the Router cross-chain messaging adapter.

At the core, the system is split into two main parts deployed on every supported chain:

  • OrderHub: Responsible for order creation and withdrawal, input token custody and order settlement.

  • OrderSpoke: Handles order filling and output token disbursement.

Each chain supported by iLayer features both a Hub contract and a Spoke contract, deployed under deterministic and consistent addresses using Create3 (on EVM-compatible chains).

The intent flow

1. Creating an Order on the OrderHub:

  • A user creates an order specifying:

    • Input tokens (ERC20, ERC721, ERC1155) they're willing to trade.

    • Desired output tokens on the destination chain.

    • Deadlines, destination chain ID, optional sponsored fees, and an optional execution hook (callRecipientand callData).

  • The user signs the order off-chain.

  • The OrderHub contract verifies the user's signature and nonce to prevent replay attacks.

  • Input tokens are transferred from the user to the OrderHub for secure custody.

  • Order state is marked as ACTIVE.

  • A cross-chain call is sent using the designated Router adapter (users can choose LayerZero or Axelar, support for other bridges is coming) to the OrderSpoke contract to register the order ID as pending.

Key function: createOrder()


2. Filling an Order on the OrderSpoke:

  • When a solver (executor bot or other service) fills an order, they trigger the fillOrder() function in the OrderSpoke contract on the destination chain.

  • The OrderSpoke verifies that:

    • The order was previously registered, is valid and hasn't expired.

    • The order hasn’t already been filled already.

    • The solver is allowed to fill it by checking if the msg.sender is the designated primary filler or the primary deadline has expired and anyone can fill it.

  • The solver provides output tokens to the OrderSpoke, ensuring the balance matches the amounts defined in the Order. Any positive slippage / excess is kept by the Spoke contract.

  • If specified in the Order intent, the Spoke also executes an external hook via an Executor contract safely isolated to prevent malicious behavior or reentrancy.

  • The OrderSpoke sends a message back to the originating chain endpoint (OrderHub) using the Router, signaling successful execution and settlement details.

  • Upon receiving a cross-chain fill message:

    • OrderHub marks the order status as FILLED.

    • Input tokens held in custody are released to the solver’s funding wallet.

This completes the settlement: the user gets desired assets on the destination chain, and the solver receives input tokens on the source chain.

Key function: fillOrder()

PreviousRFQNextOrderHub

Last updated 24 days ago