taker_quote based on the levels you stream. Understanding its selection logic is the difference between “my integration works but I never get requests” and getting meaningful flow. For the end-to-end trade flow, see Overview › How a trade works.
Cross-pair derivation
The router combines your individual pair feeds to derive cross-pairs. If your streams share a token, the router assumes the cross-pair is supported. Examples:- Stream A/USDC and B/USDC → expect A/B requests (routed through USDC).
- Stream A/USDC and A/USDT → expect USDC/USDT requests (routed through A).
Middle-token routing
For complex trades the router may route a single121 request through an intermediate token, producing multiple legs signed under a single MultiOrder. Middle-token routes typically involve multiple makers. Each maker sees only its own legs; the full 121 trade is only visible to the taker.
Example: a taker requests 100 BLAH → 3 WETH. MM1 supports BLAH, MM2 does not. The router can route BLAH → USDC → WETH, split across both:
- MM1: 100 BLAH in, 400 USDC out to the contract, then 150 USDC in from the contract, 1 WETH out to the taker.
- MM2: 250 USDC in from the contract, 2 WETH out to the taker.
MultiOrder with taker_tokens = [BLAH, USDC] and maker_tokens = [USDC, WETH]: two legs across two tokens on each side, one signature.
This is the most common reason a signature that passed tests fails in production. See Signing › Middle-token routing.
Balances and approvals
The router checks your balances and allowances on the settlement contract before pinging. If you don’t have inventory, or approvals are too small, the router skips you regardless of what you stream. Levels are capped bymin(balance, approval).