How C1 Pools Work

A C1 pool is single-sided, ask-only, on-chain liquidity that fills swaps at an oracle-derived price rather than from a bonding curve. Token holders deposit inventory into a pool. Buyers purchase from that inventory and pay the live oracle rate. Because the price comes from an external rate rather than from the pool’s own reserve ratio, the size of a fill does not move the price it is filled at.

​

Three consequences

Each follows directly from the design, and together they are the reason it exists. No price impact. A buyer who takes the entire pool pays the same unit rate as a buyer who takes one percent of it. There is no curve for the trade to move. No slippage between quote and fill. The quote and the execution read the same rate, in the same block, through the same code path. There is no gap for the price to drift into. No impermanent loss for the depositor. A depositor is not an AMM liquidity provider. They deposit one asset, that asset is sold at the oracle rate, and they claim the proceeds. There is no rebalancing against a second asset and therefore no divergence loss. The trade-off, stated plainly: a C1 pool is one-directional. It sells inventory for the quote asset. It is not a two-sided market maker, and it does not attempt to be.

​

Where it fits

For a router, filler or other integration partner, a C1 pool is a venue that can beat an AMM on thin books, because the AMM’s price impact grows with trade size while the C1 price does not. The advantage is largest exactly where AMM depth is weakest. For a large holder, it is an exit that does not pay impact. Selling a large position into an AMM moves the price against the seller for the whole trade. Depositing into a C1 pool means the position is sold at the oracle rate as buyers arrive, with no impact cost, at the cost of not being filled instantly.

​

Pricing

Pricing comes from an on-chain spot oracle that derives a rate from external venues, in the style of the 1inch OffchainOracle. The oracle is read inside the transaction, so the rate is current as at the block being executed. Two protections sit around the raw rate. Anchor band. Every pool carries a reference rate seeded at creation and an anchorBandBps tolerance. A fill whose oracle rate falls outside that band is rejected rather than executed. This bounds the damage from an oracle that is stale, manipulated or reading a broken source, and it is enforced identically in the quote path and in the execution path. Same-block rate cache. The first fill in a block pays for the oracle read and caches the resulting rate. Later fills in the same block reuse it. This is a gas optimisation, and it also guarantees that multiple fills in a block price consistently.

​

Fill order: contributor FIFO

Inventory is filled from a contributor FIFO. The earliest deposit is consumed first, and each depositor’s position and proceeds are tracked individually. There is no pooled share token and no rebasing balance. A depositor’s entitlement is exactly the inventory they deposited and the proceeds it has earned, and it is not diluted by later deposits. A large deposit arriving after yours changes your queue position for future fills, never the value of what you have already earned.

​

Fill semantics

Fills are all-or-nothing on the exact-quote entry points and partial-capable on the base entry point. A quote that cannot be filled returns unavailable rather than reverting.

​

The fee

The fee is charged to the seller, not the buyer. A buyer pays the oracle cost and nothing above it. The fee is carved out of the depositor’s proceeds when their inventory is sold. This matters for an integrator: routing to a C1 pool does not impose a fee on your user relative to the oracle rate. Any comparison against an AMM route is a comparison of oracle price versus curve price plus that venue’s fee. The default fee is 1 percent, with a per-asset override in the range 0 to 100 bps. How the fee is used is described in The Fee Model.

​

The sell side

A sell path exists in the contracts (priceSell and settleSell, with window-cap accounting) and ships disabled behind a per-pool buyBackEnabled flag. Where enabled, it lets a pool buy inventory back at the oracle rate less a spread, funded by the pool’s cash side. Integrators should treat C1 as buy-only unless a specific pool is documented otherwise.