Settlement Patterns

The interface is the same for everyone. What differs is where in your flow the call sits and what you are holding when you make it. Four patterns cover the integrations we see.

​

Pattern 1: Smart order router

The router treats C1 as one more venue in its routing graph. Discovery comes from the PoolCreated event, pair resolution from poolByPair, the quote from quoteBuyFromPool in the router’s normal quoting pass, and execution goes through the Market in the same transaction as the rest of the route. The quoting property matters most here. Because quoteBuyFromPool is a plain non-reverting view with no caller requirement, adding C1 to a quoting pass cannot fail the pass. An unavailable pool, a paused market, an empty pool or a failed oracle read all return available: false. This is the reason integration risk on the quote path is structurally zero.

​

Pattern 2: Intent-based settlement

For UniswapX, 1inch Fusion, CoW Protocol and equivalents. The counterparty is the solver, filler or resolver, not the intent protocol itself. Direction. C1 serves intents where the thin token is the output the swapper receives. The filler acquires that token from the C1 pool at oracle price and delivers it. C1 cannot serve the opposite direction, where a swapper is selling a thin token and the filler needs to offload it, because the sell side ships disabled. This is the first thing to know before committing integration time. Where the call sits. Inside the filler’s settlement callback, after the filler has received the swapper’s input asset and before it returns the output asset to the reactor or settlement contract. C1 is an inventory source, not a settlement venue. The filler is the buyer of record. Which entry point. An intent order specifies an exact output amount the filler must deliver, so the exact-output entry points are the right ones. buyFromPool where the filler already holds the quote asset. buyFromPoolExactOut where it does not. The funding callback. A filler frequently does not hold the pool’s quote asset at the moment of the call. It holds whatever the swapper handed over. It also cannot know the exact quote-asset cost until the oracle read happens inside the transaction. buyFromPoolExactOut resolves both through IFlowstateBuyFunder.fundBuy(quoteAsset, cost):

• The callback fires only when the caller is a contract and its balance or allowance is short of the computed cost.
• It receives the quote asset and the exact cost, computed inside the transaction after the oracle read.
• The caller must make that amount available to the Market before returning from the callback.
• A pre-funded caller never sees the callback and does not need to implement the interface.

A reference filler implementation is available to integrating teams on request, through contact. Fill certainty, stated honestly. Two constraints a filler must model. The exact-quote entry points are all-or-nothing. A filler that needs a deterministic fill should use those rather than the partial-capable base entry point. The anchor band can reject a fill. If the oracle rate at execution falls outside the pool’s band relative to its reference, the call reverts. Because the band is enforced identically in the quote path and the execution path, a same-block simulation is authoritative. Across blocks, between an auction close and a settlement block, the rate can move enough to bite. A filler should simulate against quoteBuyFromPool as close to settlement as its architecture allows, and should have a fallback route for the reverting case, in the same way it would for any venue that can fail. Attribution. Pass a resellerCode to attribute settled volume to the integration. Empty string if unused. Approvals. Approve the Market, not the pool. Settlement is quote-asset ERC-20 only with msg.value == 0. There is no native-ETH path, so a filler holding native ETH must wrap first.

​

Pattern 3: Direct integration

Market maker bots, OTC desks and protocols settling through C1 without an intermediary. Same interface, the caller is simply also the end buyer. The strategy layer is covered in Market Makers.

​

Pattern 4: Liquidation venue

Collateral disposal bundled atomically with a liquidation call. The risk-model layer is covered in Lending Protocols. One case a liquidation flow must handle: a large oracle dislocation is exactly when a liquidator arrives, and exactly when the anchor band is most likely to reject the fill. The flow needs an AMM fallback for that case, the same way it needs one for an empty pool.

​

Choosing an entry point