Contract Interface

The Market contract is the single execution entry point. Integrators do not call pools directly.

Pool architecture and discovery

There is one C1 Pool per token, not one pool per token and quote-asset pair. Each pool can accept multiple approved quote assets, and the quote asset is selected for each trade. Integrators can index the Market’s pool-creation events to discover pools. The same deposited inventory can be quoted and purchased through different approved quote assets without being divided among separate pair-specific pools.

Quoting

function quoteBuyFromPool(
    address pool,
    address asset,
    uint256 amount
) external view returns (Quote memory);

struct Quote {
    bool available;
    uint256 fillableAmount;
    uint256 quoteAmount;
    uint256 feeAmount;
    uint16 feeBps;
    address quoteAsset;
}

asset is the approved quote asset intended for settlement. The same pool can be quoted independently against different approved quote assets. Two properties are deliberate and useful to integrators: The quoter is designed not to revert for normal unavailability. An unavailable pool, paused market, unapproved quote asset or empty pool returns available: false instead of turning the quoting pass into a revert. If a live oracle read fails but the pool has a seeded protected anchor, the pool can continue quoting conservatively from that anchor with its staleness adjustment. Anyone can simulate it. The function is a permissionless view, so an indexer, router backend, solver or filler can call it with eth_call without privileges, allowances or state changes. A C1 quote does not reserve inventory or guarantee later execution. Quote and execution use the same pricing logic, but available inventory and oracle state can change before settlement. A quote and execution evaluated against the same block pricing state use the same unit-rate path.

Execution

function buyFromPool(
    address pool,
    address asset,
    uint256 amount,
    string calldata resellerCode,
    address buyer
) external returns (uint256 tokensFilled, uint256 quotePaid);

function buyFromPoolExactQuote(
    address pool,
    address asset,
    uint256 quoteIn,
    string calldata resellerCode,
    address buyer
) external returns (uint256 tokensFilled, uint256 quotePaid);

function buyFromPoolExactOut(
    address pool,
    address asset,
    uint256 tokenAmountOut,
    string calldata resellerCode,
    address buyer
) external returns (uint256 tokensFilled, uint256 quotePaid);

Every execution path names the quote asset for the trade. The asset must be approved by the Market for the relevant chain.

buyFromPool is exact-output in token terms: the caller names the token amount to receive and the Market computes the quote-asset cost.
buyFromPoolExactQuote is exact-input in quote-asset terms: the caller names the maximum quote amount to spend. If available C1 inventory is smaller than the amount that input could otherwise buy, execution can fill the available inventory and pull only the cost of the tokens delivered.
buyFromPoolExactOut is exact-output and supports the funding-callback settlement pattern used by integrations that source the quote asset during the call.

Exact-output execution remains all-or-nothing. Exact-input execution is inventory-bounded and can spend less than the amount offered when the pool cannot serve the full input. Integrators relying on callbacks or routed partial-fill behaviour should confirm settlement compatibility against the current deployment and integration reference.

Settlement

Settlement uses the approved ERC-20 quote asset selected for the trade. The buyer leg is an ERC-20 transferFrom with msg.value == 0; the C1 Market does not accept native ETH directly. Technical examples therefore use WETH where wrapped native-asset settlement is intended. Integrators approve the Market as spender. The Market pulls the computed quote-asset amount and forwards settlement through the relevant pool.

Attribution

resellerCode is an optional attribution identifier used to associate settled volume with a commercial or integration partner. Pass an empty string when it is not used. It does not encode a fixed public commercial share.

Depositor operations

Depositors contribute token inventory to the per-token pool, can withdraw unsold inventory and can claim proceeds accrued in the quote assets used for fills. Because a pool supports multiple approved quote assets, proceeds may accrue in more than one ERC-20.

Summary for integrators

One pool per token, with multiple approved quote assets selected per trade.
A non-reverting view quoter for normal route unavailability that anyone can simulate with eth_call.
Every quote and buy entry point names both pool and asset.
Quotes do not reserve inventory; quote and execution use the same pricing path against the same block state.
Exact-input execution can fill available inventory and charge only for what is delivered; exact-output remains all-or-nothing.

Whitepaper

Partner Guides

Integration

User Manual

Token & Protocol

Company

Resources

Contract Interface

Pool architecture and discovery

Quoting

Execution

Settlement

Attribution

Depositor operations

Summary for integrators

​Pool architecture and discovery

​Quoting

​Execution

​Settlement

​Attribution

​Depositor operations

​Summary for integrators

Pool architecture and discovery

Quoting

Execution

Settlement

Attribution

Depositor operations

Summary for integrators