RFQ
Last updated
Last updated
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 , 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.
The 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.
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 .
Message Composition: The user interface constructs an RFQ message that includes:
The configuration details (e.g., input tokens, output tokens, respective chains).
The user’s public address.
Publishing on the rfq
Topic:
This RFQ message is 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.
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.
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.
Decentralized Communication: The pub/sub model ensures robust, decentralized messaging without reliance on a central server, thereby enhancing system resilience.
Scalable Architecture: 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.
Improved Privacy and Security: 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.
Dedicated iLayer Waku Nodes: 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.
Interoperability: As an open and blockchain agnostic protocol, Waku easily integrates with decentralized applications, ensuring seamless communication across heterogeneous environments.
Message Structure Compliance: Ensure that all RFQ messages include the necessary fields and conform to a standardized format for seamless processing by solvers.
Subscription Management: Both the user interface and solver nodes must effectively manage their topic subscriptions to ensure messages are published and received on the correct channels.
Security Measures: Incorporate encryption and digital signature verification to authenticate messages and protect against tampering.
Finalizing the Order: Once a solver is selected, the user proceeds to submit an order on the , thereby initiating the trade based on the chosen quotation.