Skip to main content
The Rondo Lens is a separate, read-only contract deployed alongside the swapper. It holds no arithmetic of its own: every price it reports comes from the swapper’s own previewFill, so a quote here cannot drift from the fill it predicts.
The swapper sits near the EIP-170 bytecode limit. Keeping convenience reads in the Lens leaves the settlement contract smaller. Lens functions hold no state and never receive approvals or writes.
Address and its binding to the proxy: Deployments.

​
openOrders — the whole read, in one call

This is the function most integrations want, and the reason is correctness rather than convenience. Paging ids and order data as two separate calls is a race: the open set removes by swapping its last element into the freed slot, so an order closed between the two reads slides backwards and the reader ends up pairing one order’s id with another order’s data. In a trading UI that means the ticket can describe an order the button would not fill. Reading both inside one call puts them in the same block by construction. nextOffset stops advancing once the sweep reaches the end of the set, so a caller loops until it does not move.
One call is atomic; a sequence of them is not. Pin blockNumber across pages anyway — otherwise page 2 can come from a later block than page 1 and the set can have moved between them.

​
quoteFill — guard-aware preflight

The swapper’s own previewFill prices only — by design it will happily quote a cancelled or expired order. quoteFill adds the state, access, size, oracle, balance and allowance checks that a read-only helper can evaluate, then returns the first problem instead of reverting. An interface can render that reason rather than decode a revert. The problems are checked in the order fillOrder checks them, so the first one reported is the first one a real call would hit. Pricing is delegated to previewFill and never recomputed here; its maker-floor revert is caught rather than duplicated, because reproducing that comparison would be a second copy of the rule, free to drift from the one that actually gates the fill.
quoteFill is still not an eth_call simulation of the final transaction. It has no maxAmountIn argument, so it cannot report SlippageExceeded, and it does not execute either token transfer. A transfer failure can therefore stop a fill that the lens reports as None. Use it to explain known guards, not as an unconditional settlement promise.

​
config — the settings in one call

Five getters that would otherwise be five round trips.

​
totalEscrowed — the solvency check

The left-hand side of the invariant in Topology: what the contract still owes makers for token, across every open order. Compare it against token.balanceOf(swapper) − accruedFees(token) to audit solvency from outside. It walks the whole open set, so it is for eth_call and ops dashboards — never for on-chain use.

​
When not to use the lens

Reach for the swapper directly when you are sending a transaction. The lens is a read path; the fill itself takes its arguments from previewFill on the swapper, which is the contract that will execute them. For a responsive client, quote locally for display, confirm against previewFill before building a transaction, and use the lens to read the book and explain why a fill would fail.