Fiat and stablecoin pools

0Pools is designed around fiat-to-stablecoin liquidity. A partner does not integrate with a raw venue; it integrates with an approved pool lane such as fiat in, stablecoin out, with quote, trade, status, and reconciliation records around that lane.

Pool lane model

Why fiat and stablecoin need a pool layer

Fiat and stablecoins live in different systems. Fiat has bank rails, references, settlement windows, returns, and compliance checks. Stablecoins have networks, addresses, confirmations, and delivery risk. 0Pools puts a product contract over that complexity.

Example lanes

Examples are illustrative. Your account can only use pools returned by discovery.

Stablecoin delivery

For on-ramp flows, the destination address is locked at firm quote time. That prevents a later request from redirecting funds. Your app should validate and display the destination address before the user accepts the quote.

What not to claim

Do not claim every fiat currency, every stablecoin, every network, instant settlement, or zero-cost conversion. The accurate product claim is: approved partners can discover entitled pools and request bounded quotes against those pools.

The lane is the product primitive

A lane is more than a currency pair. It is the approved relationship between a fiat currency, a stablecoin, allowed sides, supported networks, limits, quote behavior, and settlement-facing records. Partners should render lanes from discovery and capability responses, not from a static asset table.

Example lane records

{
  "pool_id": "EUR-USDT",
  "fiat_currency": "EUR",
  "crypto_currency": "USDT",
  "supported_sides": ["on_ramp"],
  "supported_networks": ["tron", "ethereum"],
  "min_order": "10.00",
  "max_order": "5000.00",
  "availability": "entitled"
}

The exact field names belong in the API reference. The product concept is what matters here: a partner should only build UI from pools and capabilities that the account can actually use.

Before and after pool lanes

Use-case map

Developer rules

• Always render the pool id, asset, side, network, amount, and quote expiry back to the user before acceptance.
• Do not assume that support for one network implies support for another network.
• Do not infer off-ramp support from on-ramp support; sell requires explicit enablement and a crypto-receipt gate before fiat payout.
• Treat unavailable quotes as a normal operating state, not an exceptional crash.
• Preserve decimal strings exactly for ledger and reconciliation.

Lane specification

Every fiat/stablecoin pool lane should be treated as a product primitive with explicit capabilities.

Lane payload example

{
  "pool_id": "EUR-USDT",
  "fiat_asset": "EUR",
  "stablecoin_asset": "USDT",
  "enabled_sides": ["buy"],
  "networks": [
    { "name": "ethereum", "address_format": "evm", "confirmations_policy": "shown_by_status" },
    { "name": "polygon", "address_format": "evm", "confirmations_policy": "shown_by_status" }
  ],
  "limits": {
    "min_source_amount": "50.00",
    "max_source_amount": "25000.00"
  }
}

Lane test cases

Implementation depth

This page is about treating fiat-to-stablecoin lanes as reusable product primitives. For developers, the durable boundary is simple: your product should depend on pair, side, network, amount bounds, quote terms, and delivery fields; it should not depend on how fiat and stablecoin inventory is sourced or rebalanced. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.

Product scenario

A product supports EUR to USDT today and adds EUR to USDC later. The UI does not change its money logic; it renders lanes from pool discovery and uses the same quote/trade lifecycle.

Before and after in practice

System flow

Records to keep

A useful implementation stores these records before adding optional analytics. Analytics can be rebuilt from durable state; missing ids usually cannot be reconstructed after a customer-impacting failure.

Example product record

{
  "product_area": "fiat-stablecoin-pools",
  "partner_reference": "partner_order_123",
  "pool_id": "EUR-USDT",
  "quote_id": "pq_test_123",
  "transact_id": "pt_test_456",
  "status": "reserved",
  "request_id": "req_01HZY0POOLS",
  "reconciliation_state": "open"
}

This record is intentionally partner-facing. It references 0Pools objects and your own product ids, but it does not include private liquidity routes, treasury balances, raw provider payloads, or customer secrets.

Failure modes and recovery

Use-case patterns

Developer checklist

• Read runtime discovery and capabilities before rendering enabled actions.
• Create firm quotes only when the user is ready to accept the terms.
• Execute from your server with an idempotency key.
• Treat webhooks and status reads as the source of truth for settlement state.
• Reconcile by durable ids first, then by amount and timestamp.
• Do not branch product behavior on provider names, route names, reserve balances, or treasury assumptions.