> ## Documentation Index
> Fetch the complete documentation index at: https://whitepaper.flowstate.exchange/llms.txt
> Use this file to discover all available pages before exploring further.
# Settlement Patterns
> Where the C1 call sits in a router, an intent settlement, a bot or a liquidation flow
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](/resources/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](/onboarding/for-market-makers).
## Pattern 4: Liquidation venue
Collateral disposal bundled atomically with a liquidation call. The risk-model layer is covered in [Lending Protocols](/onboarding/for-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
| Pattern | Entry point | Who holds the quote asset | If the fill is rejected |
| ------------- | ----------------------------------------------------- | --------------------------------------------------- | ---------------------------------------------------------------------------------- |
| Router | `buyFromPool` or `buyFromPoolExactQuote` | The route, at settlement | Route around C1. The quote path already returned `available: false` where knowable |
| Intent filler | `buyFromPoolExactOut`, or `buyFromPool` if pre-funded | The filler, or sourced in `fundBuy` during the call | Re-simulate near settlement, fall back to the next inventory source |
| Direct | `buyFromPool` | The caller | Retry next block or route elsewhere |
| Liquidation | `buyFromPool`, bundled with the liquidation call | The liquidator contract | AMM fallback path |