> For the complete documentation index, see [llms.txt](https://docs.useicaria.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.useicaria.xyz/protocol/routing.md).

# Routing

The single contract that folds vaults and RFQ into one price.

`SwapRouter` is the only contract a trader ever touches. Four jobs sit on it: deciding eligibility, picking the venue, assembling multi-leg trades, and holding every fill to the limits it has to respect.

## Venue selection

Given a size, the router sets the anchor vault (assuming the size fits the clip and the regime permits quoting) against whatever valid maker quotes came in with the call, then settles whichever produces more output for the trader. That comparison runs on-chain and leaves no room for doubt: the vault quote is rebuilt from oracle and vault state inside the same transaction rather than taken on faith from a front-end, and the maker quote is validated by signature. Misrouting a trade to a worse price is therefore not something a front-end is able to do, because the router will not settle a supplied path the vault has beaten.

## Two-leg swaps

Token-to-token means two legs through USDG, and they happen together:

1. Leg one sells `tokenIn` into its vault or to a maker, receiving USDG.
2. Leg two spends that USDG on `tokenOut`, again from a vault or a maker.

Each leg picks its own venue, so one can go to a vault while the other goes to a maker. Each leg answers to its own market's band and regime, and a failure on either unwinds both. Both legs appear in the fill event with pricing itemised, and the slippage bound the trader signed applies to the rate from end to end.

## What every fill has to satisfy

| Check                                      | Failure mode prevented                             |
| ------------------------------------------ | -------------------------------------------------- |
| A `TRADER` attestation on the caller       | Ineligible parties trading                         |
| The oracle band, per leg                   | Any fill drifting from the guarded reference price |
| A regime that permits quoting              | Trading through a halt                             |
| Clip and daily volume caps                 | Flow larger than the guarded launch allows         |
| The trader's slippage bound and deadline   | Filling against state that has since moved         |
| A Permit2 pull matching the signed amounts | Allowances being used for something else           |

## Ordering and MEV

The sequencer on Robinhood Chain runs first-come-first-served with preconfirmations around 100 ms, which removes the public-mempool sandwich in the form it takes on Ethereum today. None of the design leans on that staying true. Fills are already hemmed in by the signed slippage limit and the oracle band, so the most that any ordering advantage can reach is width the trader agreed to in advance. Should the chain switch on Timeboost or revise ordering in some other way, the resulting review goes into the governance log. See [Sequencer and chain risk](/risk/sequencer-and-chain.md).

## Integration surface

Anyone may call the router. It is a public contract with a stable interface, and eligibility attaches to the caller rather than to whichever front-end sent them. Wallets, portfolio tools and agents take pricing from the [quote API and SDK](/architecture/api.md) and submit straight to the contract. Nothing privileged runs behind the reference front-end at [useicaria.xyz/platform](https://useicaria.xyz/platform).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.useicaria.xyz/protocol/routing.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.