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.
Give SHIB, receive WBTC, WETH and DAI in the proportions you choose. How weighted outputs are encoded, validated and filled.
An Order’s outputs is an array, not a single token. That lets a user express a portfolio in one intent: “turn this into 20% BTC, 30% ETH, 50% DAI.” In the RFQ the amounts become relative weights; the solver network turns them into exact quotes.
"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 }
]
When more than one output is present, amount is a weight. The weights must sum to 100 or the request is rejected. The solvers reply with the concrete amounts of each token their quote delivers, and those amounts are what ends up in the signed Order.
Solvers keep a single numeraire balance, usually USDC or USDT. For an order that gives SHIB and wants WETH and WBTC, the solver runs one multicall transaction on the destination chain: swap numeraire into WETH and WBTC in the required amounts, then fillOrder(). On the source chain the incoming SHIB is swapped back into the numeraire. The user gets three tokens; the solver’s books stay in one.
The Spoke checks that every output balance matches the Order before releasing anything. Excess or positive slippage stays in the Spoke.
The ecosystem track opens on the other side of the order book.
The bots behind every fill: what they watch, how they quote, why they keep a single numeraire balance, and how they rebalance across chains.