Intent 106: Deadlines, withdrawals and the time buffer
Every order carries two deadlines and the Hub adds a third clock. Here is what each one protects, and the attack the time buffer was built to stop.
/Education. · 05.
Intent 105: RFQ, how quotes reach you
Before the order there is a request. How iLayer broadcasts your RFQ to every solver over Waku, and how each answer comes back to you alone.
Every order starts as a question: who will give me the best 9,900 DAI on Polygon for 10,000 USDC on Ethereum? On iLayer that question is a Request For Quote, and it does not go to a server. It goes to a topic on Waku, a censorship-resistant messaging protocol, where every solver in the network is listening. Nobody registers, nobody passes KYC, nobody can be silenced.
/01 · Chapter.
Composing the request
The interface builds an RFQ message with the same information the final Order will carry:
- a request deadline and an incremental nonce;
- user and recipient as bytes32, so non-EVM accounts fit;
- an optional filler, blank if any solver may answer;
- inputs with amounts, outputs with amounts or relative weights;
- source and destination chain ids;
- whether the order is sponsored (gasless: gas is subtracted from the quote);
- the primary deadline and the final deadline;
- any calldata settings: target, data, value.
{
"deadline": 1750000, "nonce": 3,
"user": "0x00…", "recipient": "0x00…", "filler": "",
"inputs": [{ "tokenAddress": "USDC", "amount": 10000000, "type": "FUNGIBLE_TOKEN", "tokenId": 0 }],
"outputs": [{ "tokenAddress": "DAI", "amount": 9900000000000000000, "type": "FUNGIBLE_TOKEN", "tokenId": 0 }],
"sourceChainId": 1, "destinationChainId": 137, "sponsored": false,
"primaryFillerDeadline": …, "callRecipient": "", "callData": "", "callValue": 0
}/02 · Chapter.
Publishing on the rfq topic
The message is published on a dedicated rfq topic. Waku is publish/subscribe: every solver subscribes to that topic once and receives every request from then on. There is no queue to join and no operator deciding who sees what.
iLayer runs its own Waku nodes alongside the public network, so message propagation does not depend on third parties, while anyone else can run a node too.
/03 · Chapter.
Answers come back one to one
Each solver evaluates the request with its own logic and market view, then publishes its quote on a topic named after your public address. Two consequences:
- only you receive the answers meant for you;
- solver quotes are not broadcast to competitors or to the whole network, which keeps traffic low and pricing private.
The interface aggregates the replies. You see prices and execution terms side by side and pick one.
/04 · Chapter.
From quote to order
Choosing a quote fixes two fields of the Order: the outputs (the exact amounts the solver committed to) and the filler (that solver’s address). From here there are three ways to proceed:
- submit the order yourself on the OrderHub, paying gas on the source chain;
- sign the order and hand it to the solver, who submits it for you: gasless execution;
- use iLayer’s own gas sponsoring, not implemented yet at the time of writing.
Either way the solver is now bound: if it does not fill inside its primary window, any other solver can, at the same amounts. The quote is a commitment, not a suggestion.
/05 · Chapter.
Why this matters
Decentralised, scalable, private, interoperable: those are Waku’s properties, and they become the RFQ’s properties. A central quote server would be simpler to build and would give one party the power to censor requests, front-run them, or go offline. The rfq topic gives that power to nobody. We wrote a separate piece on the choice: Why Waku for the RFQ.
/Read next.
Deadlines, withdrawals and the time buffer.
Next: the three clocks inside every order and the small delay that keeps solvers safe.