> For the complete documentation index, see [llms.txt](https://docs.ilayer.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ilayer.io/architecture/rfq.md).
# 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](https://waku.org/), 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**](https://waku.org) 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](/hub-and-spoke/orderhub.md).
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 deadlin**e, 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*](https://chainlist.org/)*.*
**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:
```json
{
...
"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., ``). 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.
