RFQ

When a new intent is generated, it needs to be broadcasted to our network of solver bots. We don't rely on a centralised server but instead we use Waku, a censorship-resistant communication protocol that anyone can access. By doing so, we allow participation to the iLayer network to anyone without the need to KYC or register anywhere.

Waku

The Waku protocol is a decentralized messaging solution designed to facilitate secure, scalable, and privacy-focused communication for distributed applications. Originally derived from the Whisper protocol, Waku has been enhanced to overcome issues of scalability and performance. It operates on a publish/subscribe model, making it an ideal choice for applications requiring real-time, decentralized message exchange without the need for a central server. Key benefits include:

• Decentralization: Eliminates single points of failure by distributing message relaying across a network of nodes.

• Scalability: Supports high volumes of messages, making it suitable for systems with many simultaneous users and solvers.

• Enhanced Privacy: Provides mechanisms to direct responses to specific users, reducing unnecessary network noise and preserving user privacy.

Overview of the RFQ

In the RFQ (Request For Quote) process, the system allows users to:

• Configure Tokens: Define the input tokens on chain A and the output tokens on chain B via the user interface.

• Request Quotations: Submit an RFQ that is broadcast to the network of solvers. Each solver processes the request and returns its own quote.

• Select a Solver: Review the received quotations, choose the most favorable offer, and then proceed to place an order on the hub contract.

Highlighted in red is the complete flow of an individual request.

Order Request Submission

Message Composition

The user interface constructs an RFQ message that includes:

• request deadline

• nonce

• The user public address encoded as a bytes32 field

• The recipient public address encoded as a bytes32 field

• an eventual filler, left blank if any solver can respond to the RFQ

• inputs tokens and their amounts

• outputs tokens and their relative weight (if > 1)

• source chain ID

• destination chain ID

• whether the order is sponsored/gasless or not (gas cost will be subtracted from the final quote)

• a primary deadline for the responder that will have them as the main solver, after this deadline any bot on the iLayer network can fill the order preserving the original input and output quotes

• a secondary deadline, after which the order is marked as expired and cannot be filled anymore

• any eventual calldata-related settings (target, data and value)

Chain IDs can be obtained by visiting the chainlist website.

Example

{
  "deadline": 1750000, // timestamp
  "nonce": 3, // an incremental nonce to avoid replay attacks
  "user": "0x00123", // in bytes32 notation to support non-EVM chains
  "recipient": "0x00123", // same as above
  "filler": "", // empty unless we are sending the order to a specific solver
  "inputs": [
    { "tokenAddress": "USDC address", "amount": 10000000, "type": "FUNGIBLE_TOKEN", "tokenId": 0 },
  ],
  "outputs": [
    { "tokenAddress": "DAI address", "amount": 9900000000000000000, "type": "FUNGIBLE_TOKEN", "tokenId": 0 },
  ]
  "sourceChainId": 1, // Ethereum mainnet
  "destinationChainId": 137, // Polygon
  "sponsored": false, //
  "primaryFillerDeadline": 123..., // timestamp
  "deadline": 123..., // timestamp
  "callRecipient": "",
  "callData": "",
  "callValue": 0,
}

Multitoken output

To expand on the multi-token, let's imagine that we have WBTC, WETH and DAI as output, the array would look like this. 20% of the final value will be BTC, 20% will be WETH and 50% will be DAI. The order request output tokens part is as follows:

{
...
 "outputs": [
  { "tokenAddress": "WBTC address", "amount": 20, "type": "FUNGIBLE_TOKEN", "tokenId": 0 },
  { "tokenAddress": "WETH address", "amount": 30, "type": "FUNGIBLE_TOKEN", "tokenId": 0 },
  { "tokenAddress": "DAI address", "amount": 50, "type": "FUNGIBLE_TOKEN", "tokenId": 0 },
 ]
}

| Note: if the total weights sum is different than 100, the order will be rejected.

Publishing on the rfq topic

This order request message is then published to a dedicated rfq topic via the Waku protocol. All network solvers are subscribed to this topic, ensuring that every solver receives the request.

Solver Response Mechanism

• Listening to the rfq topic: All solvers in the network continuously monitor the rfq topic for incoming RFQ messages. Upon receiving a message, each solver evaluates the request based on its own logic and market parameters.

• Replying via User-specific topics: In the RFQ message, the user’s public address is included to allow solvers to target their responses. Each solver publishes its quotation to a unique topic associated with the user’s public address (e.g., <user_public_address>). This ensures that:

  • Only the intended recipient receives the response.

  • Network traffic is efficiently segregated, minimizing exposure of solver responses to unintended parties.

Order Execution

• Quote Selection: The user interface aggregates the responses from various solvers. The user reviews the quotes and selects one based on factors such as pricing and execution terms.

• Finalizing the Order: Once a solver is selected, the user proceeds to:

  • submit an order on the hub contract, thereby initiating the trade based on the chosen quotation.

  • submit the signed order directly to the bot for gasless execution.

  • (not implemented yet) use iLayer gas sponsoring function directly.

Advantages of using Waku in RFQ

• Decentralized: The pub/sub model ensures robust, decentralized messaging without reliance on a central server, thereby enhancing system resilience.

• Scalable: The protocol's design allows it to handle a high volume of messages, making it suitable for environments where multiple RFQs and solver responses are processed concurrently.

• Private: By directing solver responses to user-specific topics, the protocol limits message exposure to only the intended recipient, thus enhancing confidentiality and reducing risks of data leakage.

• Trusted: iLayer contributes to the security and decentralization of the protocol by offering its own Waku nodes. These dedicated nodes enhance the robustness of the messaging infrastructure, reducing dependency on third-party networks and ensuring reliable message propagation throughout the system.

• Interoperable: As an open and blockchain agnostic protocol, Waku easily integrates with decentralized applications, ensuring seamless communication across heterogeneous environments.