Settlement Patterns

The underlying C1 inventory is common across integrations. What changes is how a route reaches that inventory, which approved quote asset is used and how the surrounding integration settles the order.

​

Pattern 1: Smart order router calling the Market

C1 can sit in the routing graph alongside AMMs, RFQ sources and other liquidity venues. A router discovers the per-token pool, calls quoteBuyFromPool(pool, asset, amount) for the intended quote asset and can select C1 when available inventory provides better net execution. The quoter is a permissionless view designed to report normal route unavailability without reverting the quoting pass. An unavailable pool, paused market, unapproved quote asset or empty inventory returns available: false. If a live oracle read is unavailable but the pool has a seeded protected anchor, the quote can remain available with conservative stale-oracle treatment.

​

Pattern 2: Routing through Uniswap V4

The FlowState V4 hook exposes the same underlying C1 inventory through a V4 pair-shaped routing surface. The V4 representation is a distribution path, not a second source of token depth. For exact-input buys above available C1 inventory, the hook can consume only the inventory C1 can deliver and leave the unused quote input unspent. Exact-output remains all-or-nothing. A routed partial fill requires the surrounding V4 router to settle the actual live debt created by the swap rather than assuming the original maximum input was fully spent. Routers that do not support that settlement pattern revert rather than overpaying. Partner-specific compatibility should be confirmed against the current deployment before enabling routed partial fills.

​

Pattern 3: Intent-based settlement

For intent-based execution, C1 can act as an inventory source where the token being purchased is available in a C1 Pool. A solver, filler or resolver can source that output during settlement rather than holding the token in advance. The direction constraint is important: C1 supplies the token the swapper is buying. The default C1 configuration does not absorb the thin token when the swapper is selling it unless optional quote-side liquidity has been explicitly enabled for that pool. Every execution entry point names the approved quote asset. A filler must have, acquire or otherwise make that ERC-20 available under the current integration contract before settlement completes. Native ETH is not accepted directly; use WETH where wrapped native-asset settlement is intended.

​

Pattern 4: Direct integration

Market-maker bots and other professional execution systems can call the Market directly. They use the same quote-asset-aware quoter and buy entry points, approve the Market for the selected ERC-20 quote asset and handle unavailable or rejected fills as part of their normal strategy logic.

​

Quote versus execution

A C1 quote does not reserve inventory or guarantee later execution. Available inventory can change before settlement and oracle-derived pricing can move between blocks. Quote and execution use the same pricing path. When both are evaluated against the same block pricing state, the unit rate is consistent rather than being recalculated through a separate quote-only model. Integrators should still simulate close to execution and maintain an appropriate fallback because availability can change even when the pricing path is consistent.

​

Choosing an entry point

​

Attribution

resellerCode is an optional attribution identifier used to associate settled volume with a commercial or integration partner. Commercial participation is agreed separately and is not fixed by the public interface.