Supported assets and pool types

Supported assets are not a static website list. They are a function of partner entitlement, pool capabilities, environment, product approval, and runtime liquidity.

Decision flow

Pool pair

A pool id expresses the pair. The quote request must match it.

If poolId is EUR-USDT, do not send fiatCurrency: "GBP" or cryptoCurrency: "USDC".

Sides

Networks

cryptoNetwork is the network selected for the quote. The canonical vocabulary includes tron, ethereum, bsc, polygon, and solana. The server default is tron when omitted, but a production UI should make the selected network explicit.

Delivery networks can be narrower. For a buy, the destination address and delivery network are locked on the quote. Always display them back to the user.

Limits and economics

Capabilities and quote responses expose:

• Minimum order in USDT-equivalent.
• Maximum order when configured.
• Draw fee bps.
• Spread cap bps.
• Supported sides.
• Supported networks.

Use these to validate before quote and explain quote terms after quote.

UI examples

API details

Use List entitled pools and Read pool capabilities for exact fields.

What "supported" means

An asset can be conceptually supported by the platform but unavailable for a specific partner, environment, side, network, amount, or runtime condition. Product UI should always follow the account's discovery and capability data.

Pool types

UI rendering pattern

{
  "pool_id": "EUR-USDT",
  "display": "EUR to USDT",
  "side": "on_ramp",
  "network_options": ["tron", "ethereum"],
  "amount_min": "10.00",
  "amount_max": "5000.00",
  "can_quote_now": true
}

Use this kind of normalized view inside your own product. It lets frontend code render choices without learning private pool internals.

Before and after

Common mistakes

• Showing all networks for a stablecoin because the stablecoin exists.
• Showing off_ramp because on_ramp is available.
• Treating sandbox support as live support.
• Treating examples as entitlement.
• Allowing destination address entry after quote lock.
• Rounding decimal strings before reconciliation.

Asset support matrix

Supported does not only mean "listed in a dropdown." It means the asset, network, side, limits, precision, settlement behavior, and disclosure language are approved for the partner account.

Rendering rule

function canRenderPoolAction(pool: PoolCapability, action: 'buy' | 'sell') {
  return pool.status === 'active'
    && pool.sides.includes(action)
    && pool.networks.some((network) => network.status === 'active');
}

Versioning and deprecation

Implementation depth

This page is about presenting assets, pairs, sides, networks, and pool types accurately. For developers, the durable boundary is simple: your product should depend on the account-specific supported set returned by discovery and capabilities; it should not depend on unlisted assets, future pairs, source depth, and route preference. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.

Product scenario

A developer builds an asset selector. Instead of shipping a hard-coded list, the selector reads pools, sides, networks, and limits at runtime and caches only for short UX windows.

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": "supported-assets-pool-types",
  "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.