Liquidity source model

0Pools is a liquidity abstraction layer. It lets a partner interact with an approved pool lane without building directly against every bank rail, venue, market maker, reserve account, and reconciliation worker behind that lane.

Before 0Pools

Teams that need fiat/stablecoin conversion usually have to assemble a stack like this:

That creates duplicated capital, duplicated risk controls, and duplicated support logic.

With 0Pools

0Pools compresses that into a partner-visible contract:

The partner sees quote/trade/balance records. 0Bit handles private sourcing decisions behind the contract.

What sourcing means

Liquidity sourcing answers: where can 0Bit safely get or deliver the fiat/stablecoin required for this accepted quote?

0Pools intentionally does not expose specific source selection. The stable partner-visible model is:

Why not expose every source?

Do not show liquidity source or provider names in your customer experience. Build the flow around stable 0Pools records instead: pool, quote, trade, status, and ledger. That keeps your integration stable when 0Pools changes how liquidity is sourced behind the scenes.

Developer rule

Design source-agnostic user states. Build product states around:

• available/unavailable
• quoted/expired
• reserved/pending
• settled
• failed
• released
• returned

Do not build product states around provider names, route names, reserve levels, or operational worker names.

Source abstraction layers

The partner-visible records are intentionally narrow. They are enough for your product to serve users, operate support, and reconcile finance. The private layers can change as 0Bit improves sourcing, adds capacity, or changes internal risk controls.

Before and after for society-scale infrastructure

This is the larger intention of 0Pools: make liquidity infrastructure reusable without making every partner become a liquidity operator.

Example source investigation

{
  "pool_id": "EUR-USDT",
  "quote_id": "pool_quote_123",
  "trade_id": "pool_trade_456",
  "status": "reserved",
  "unavailable_reason": null,
  "request_id": "req_abc",
  "partner_visible_summary": "0Pools trade is processing"
}

If an incident needs deeper source review, escalate with ids. Your integration does not need raw source routing details in the normal flow.

Safe source language

Developer checklist

• Keep source identifiers out of user-facing logs and analytics.
• Do not create provider-specific UI branches.
• Map unavailable reasons to product-safe copy.
• Preserve request ids for support escalation.
• Use partner-visible status and ledger records for reconciliation.

Source-safe support workflow

When support asks "where did this price or status come from," the answer should start with partner-visible records.

Escalation packet

{
  "partner_order_id": "order_7841",
  "pool_id": "EUR-USDT",
  "quote_id": "pq_live_01J4",
  "transact_id": "pt_live_9A2",
  "request_id": "req_01J4SOURCE",
  "current_status": "reserved",
  "user_safe_summary": "The trade is processing under the 0Pools lifecycle."
}

Copy rules

Use "pool," "quote," "trade," "status," and "ledger" in public product copy. Avoid provider names, source names, reserve levels, and route labels in user-facing screens, analytics labels, and support macros.

Implementation depth

This page is about abstracting private liquidity sources into partner-safe product records. For developers, the durable boundary is simple: your product should depend on pool, quote, trade, availability, and status outcomes; it should not depend on source names, account balances, commercial terms, and route logic. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.

Product scenario

A support case asks where a price came from. The partner can inspect quote economics and request ids, but the product should not expose private source selection in the customer experience.

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": "liquidity-source-review",
  "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, source names, reserve balances, or treasury assumptions.