/Ecosystem. · 01.

How solvers fill orders and make money

The bots behind every fill: what they watch, how they quote, why they keep a single numeraire balance, and how they rebalance across chains.

iLayer.io~6 min5 chapters
solversnumerairerebalancing
/Solver loop./Numeraire./01.WatchRFQ topic, Hubs, Spokes./02.QuoteReply on the user topic./03.FillMulticall: swap + fillOrder./04.ConsolidateInputs swapped back to USDC.USDC or USDT balancerebalance cross-chainbest price winsno KYC
/Solver loop./01.WatchRFQ topic, Hubs, Spokes./02.QuoteReply on the user topic./03.FillMulticall: swap+ fillOrder./04.ConsolidateInputs swappedback to USDC.USDC or USDT balancerebalance cross-chainbest price winsno KYC

The backbone of iLayer is its network of solver bots. They pick up orders and fill them cross-chain, competing with each other so the user gets the best price. Anyone can run one: the RFQ runs on Waku, so there is no registration and no KYC.

/01 · Chapter.

What a solver watches

A bot keeps an internal order list built from three streams: orders created on the various OrderHubs, orders filled on the OrderSpokes, and requests arriving on the RFQ channel. From these it derives the orders it can fill:

  • RFQs it answered, accepted by the user and sent back signed;
  • orders on a Hub whose primary filler deadline has expired and that have not been filled on the corresponding Spoke.

The second category is the safety net of the network: a solver that wins a quote and does not deliver hands its order, at the same amounts, to whoever is faster.

/02 · Chapter.

Quoting

Each RFQ arrives on the rfq topic. The solver prices it with its own logic and market view, including gas on both chains and, for sponsored orders, the cost of submitting the creation itself. It answers on the user’s private topic. If chosen, its address becomes the order’s filler and it gets an exclusive window to execute.

/03 · Chapter.

One balance to rule them all

Solvers maintain only a numeraire token as their balance, ideally a stablecoin like USDC or USDT. Every order is consolidated into it. A multi-token order that wants WETH and WBTC and gives SHIB is executed as:

  1. one multicall on the destination chain: swap numeraire into WETH and WBTC in the required amounts, then fillOrder() on the Spoke;
  2. on the Hub side, once the inputs are released, swap the incoming SHIB into the numeraire.

No inventory of a hundred tokens, no exposure to what users happen to send.

/04 · Chapter.

Rebalancing

Volumes are not symmetric: more orders flow into a hot new chain than out of it. Bots rebalance their numeraire across chains to keep the right ratios for the volumes they see. Because the balance is a stablecoin, rebalancing is a plain transfer, not a portfolio problem.

/05 · Chapter.

Where the money is

A solver earns the spread between the quote it gives and its own execution cost, plus the gas premium on sponsored orders. It is paid on delivery: the Hub releases inputs only after the Spoke confirms the fill. Competition on the rfq topic keeps spreads honest, and the open-after-deadline rule keeps service honest. Protocol fee on top: 0.03%.

/Read next.

Why Waku for the RFQ.

Next: the messaging layer solvers listen on, and why it is not a server.

/Ecosystem.

Why Waku for the RFQ

A central quote server would have been easier. It would also have been a single point of failure, censorship and front-running. What Waku gives us instead.

4 chapters~5 minWaku

All posts