What is 0Pools?

0Pools is 0Bit's shared liquidity network: the pool ledger and partner API that connect fiat balances, stablecoin inventory, quote locks, execution state, settlement records, and reconciliation into one reusable infrastructure layer.

For most developers, 0Pools is not the first product to integrate. If you want a hosted on-ramp/off-ramp/swap user experience, use 0Gate. If you are an approved headless partner that must own the customer UX and backend ledger, 0Pools gives your server direct access to entitled pool discovery, quotes, execution, status, balance, and reconciliation.

The problem before 0Pools

Without a shared liquidity network, every product team has to rebuild the same fragile stack:

0Pools exists to turn that into a shared network: one entitlement model, one quote lifecycle, one trade lifecycle, one partner-visible balance story, and one reconciliation vocabulary.

What changes with 0Pools

0Pools does not promise that markets stop moving. It changes where market movement is handled. A user-facing product receives partner-visible quote terms; 0Bit's infrastructure manages the private inventory, route, spread, risk, and settlement machinery behind that contract.

The 0Pools network

For integrations, the developer contract stops at the 0Pools network boundary. You should understand that a shared liquidity spine exists, but your product should not build user experiences around venue names, treasury wallets, rebalancing thresholds, or route decisions.

Social and product intention

0Pools is meant to make cross-border value movement less bespoke. Many useful products need fiat-to-stablecoin liquidity: remittance apps, payroll platforms, wallets, contractor marketplaces, card programs, treasury desks, and marketplaces serving users across countries. Without infrastructure, each one has to become a mini exchange, treasury team, compliance operation, and reconciliation shop.

The product intention is to let approved builders focus on the application layer while 0Bit provides a reusable liquidity foundation:

• Better capital reuse across products instead of isolated balances.
• Bounded quote acceptance windows instead of open-ended price promises.
• Server-side execution instead of browser-owned money movement.
• Partner-scoped records instead of hidden manual reconciliation.
• Explicit account approval instead of public endpoint exposure.

What a partner actually builds

The browser displays state. The partner server owns quote creation, quote execution, polling, webhook handling, and ledger mutation.

Product boundary

Evaluation model for serious integrators

A partner evaluating 0Pools should be able to answer four questions before writing production code.

Example society-scale outcome

Before 0Pools, a remittance app, payroll platform, and neobank might each build separate liquidity relationships, retry logic, quote screens, support dashboards, and finance ledgers. With 0Pools, those products can share the same pool primitives while keeping their own user experience and customer records.

{
  "partner_product": "cross_border_wallet",
  "pool_id": "EUR-USDT",
  "user_intent": "buy_stablecoin",
  "quote_contract": "firm_until_expiry",
  "execution_contract": "server_side_idempotent",
  "reconciliation_contract": "ledger_join_by_quote_and_trade"
}

Product boundary that should be obvious

0Pools is not a generic exchange UI, a promise of unlimited liquidity, or a way for a partner to bypass compliance controls. It is a gated liquidity network with records a developer can build around: entitlement, availability, quote, trade, status, webhook, balance, and ledger.

Implementation depth

This page is about understanding 0Pools as a shared liquidity network. For developers, the durable boundary is simple: your product should depend on a reusable pool, quote, trade, balance, and reconciliation contract; it should not depend on how 0Bit sources, hedges, stores, and rebalances liquidity. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.

Product scenario

A remittance app, a wallet, and a checkout product all need fiat-to-stablecoin conversion. Instead of each product maintaining separate liquidity logic, they draw from the same 0Pools network and receive a consistent partner-facing record model.

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": "index",
  "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.

Read next