Technical Architecture

FlowState is built around one core primitive: one shared C1 Pool for each inventory token. Sellers contribute inventory once, and that same inventory can be reached through multiple approved settlement assets and multiple execution surfaces without creating separate liquidity silos. FlowState remains pre-launch. Current deployment and security-review status are maintained on Deployments and Audits & Security.

​

1. One shared inventory layer

One C1 Pool exists per inventory token. A pool can accept multiple approved ERC-20 quote assets selected per trade, so the underlying token inventory does not need to be split into separate quote-specific pools. The same principle applies across distribution. Direct Market execution, routing integrations, intent systems, RFQ paths, Uniswap V4 and other supported execution surfaces can all reach the same underlying C1 inventory. A TOKEN/WETH route and a TOKEN/USDC route therefore do not represent independently backed token depth. They are different settlement and distribution paths into the same TOKEN inventory.

​

2. Protected oracle-derived pricing

C1 does not derive its execution price from the ratio of assets held inside the pool. It uses an on-chain oracle-derived market rate together with a protected anchor maintained for each supported quote asset. For a buy, execution uses the more conservative side of the live oracle reading and the anchor. In practice, that means the buyer cannot receive inventory at a unit rate below the protected anchor simply because the live oracle reading moves lower. The anchor band governs how the anchor is allowed to move. It is not a hard band that every fill must remain inside, and an out-of-band live reading does not by itself reject execution. Sustained market moves can propagate into the anchor subject to bounded update rules. If a live oracle reading cannot be obtained, a seeded anchor can continue to support conservative quoting with a staleness adjustment rather than turning an unreadable oracle into a favourable buyer price. Because price comes from this protected external reference rather than a C1 bonding curve, fill size does not move the unit rate through C1 pool balances.

​

3. Quote and fill semantics

A C1 quote describes current executable state. It does not reserve inventory. Inventory can change before settlement as other buyers execute or contributors withdraw unfilled inventory. Oracle state can also change between blocks. Integrators should therefore treat the final on-chain execution as authoritative. A quote and execution evaluated against the same block pricing state use the same pricing path. C1 does not maintain a separate quote-only pricing model that can produce a different unit rate from execution against identical state.

​

Inventory-bounded exact-input execution

For exact-input buys, the amount offered is an upper bound on what may be spent. If the order is larger than the C1 inventory currently available, supported execution paths can fill the inventory that is available and charge only for the tokens actually delivered. Exact-output execution remains all-or-nothing. If the requested token output cannot be delivered in full, the order does not settle as a smaller output. This distinction also matters for measurement. Realised FlowState volume is the value actually settled for inventory delivered by C1, not the nominal size of an external order when only part of that order executes through C1.

​

4. Atomic fills, progressive positions

Each successful buyer fill settles atomically on-chain. The buyer receives the inventory delivered by that fill and contributor accounting updates in the same transaction. A seller’s overall deposited position does not need to execute as one immediate market order. Inventory can be consumed progressively as external buyer demand arrives, while inventory that has not filled remains available for withdrawal. This is the core trade-off of the C1 model: sellers avoid forcing an entire position through the market depth available at one moment, but full-position completion depends on future buyer demand and is not guaranteed at deposit time.

​

5. Contributor accounting

C1 tracks inventory by contributor and consumes seller-side inventory in FIFO order. When a fill consumes a contributor’s inventory, the corresponding net settlement proceeds accrue to that contributor. C1 does not issue a pooled LP share token and contributor balances do not rebase. Later deposits therefore do not dilute an earlier contributor’s recorded entitlement. Because the same inventory can settle through multiple approved quote assets, a contributor can accrue proceeds in more than one settlement asset from the same C1 Pool. Accrued proceeds remain attributable and claimable by settlement asset.

​

6. Distribution without liquidity fragmentation

FlowState’s execution surfaces are ways for demand to reach C1, not independent custody venues.

• direct Market contract execution
• machine-facing API and RFQ paths
• intent and filler integrations
• Uniswap V4 distribution through the FlowState hook
• router, aggregator and platform integrations

A V4 route, for example, can expose C1 as a conventional pair-shaped routing surface while the underlying liquidity remains in the shared C1 Pool. The V4 representation does not create a second pool of tradeable C1 inventory. Execution surfaces can differ in how an order is transported and settled, but they ultimately draw from the same C1 inventory and settle against the protocol’s on-chain execution rules.

​

On-chain settlement is authoritative

FlowState can index on-chain activity and expose derived state to user interfaces, analytics and partner services. Those read surfaces improve discovery and usability, but they do not replace on-chain settlement as the source of execution truth. Unsold inventory remains withdrawable and accrued proceeds remain claimable under the protocol’s documented controls. See How C1 Pools Work for contract-level mechanics and Audits & Security for the current security model.

​

Integration reference