Reserves and settlement

Understand how 0Pools exposes settlement-facing records while keeping reserve, treasury, and routing internals out of the integration contract.

0Pools is built on shared liquidity, but shared liquidity is not the same thing as a public reserve dashboard. Developers need enough settlement context to reconcile quotes, trades, balances, reports, and scan-visible activity. They do not need raw treasury balances, provider paths, reserve allocation, venue accounts, or rebalancing thresholds.

This page explains the 0Pools reserve and settlement boundary: which records are available to your integration, which details are outside the partner contract, and how to build finance-safe reconciliation without treating operational status as an attestation, redemption promise, or payout SLA.

What this page covers

Which reserve and settlement concepts are exposed to partner integrations.
Which records help reconcile asset activity.
How settlement context relates to 0Gate, 0Pools, 0Base, 0Pools Scan, and operations records.
Which reserve, treasury, provider, and route details stay outside the partner contract.

0Pools settlement boundary

The public contract is record-centric. A partner can store quote_id, trade_id, pool_id, side, amount strings, status, timestamps, request ids, and webhook event ids. 0Bit can improve the reserve, treasury, and route layer privately as long as those partner-visible records remain stable.

Partner-facing model

Concept	Partner-facing treatment	Outside the integration contract
Reserve boundary	Explain that records can reference asset activity and settlement-aware reports.	Bank balances, wallet balances, reserve allocation, counterparties, signer operations, or proof language.
Settlement record	Show how a product event can map to a report, ledger row, status, or transaction reference.	Fixed payout timing, legal finality, or rail-specific promises unless they are part of the approved product contract.
Report	Describe the fields and joins needed for reconciliation.	Finance-only reports, private ledger details, raw provider payloads, or partner-crossing data.
Scan view	Use 0Pools Scan for searchable visibility and support investigation.	Treating scan as the sole accounting or legal truth source.
Asset support	Describe configured examples and capability checks.	Universal production support, live corridor promises, or every-market claims.

Before and after 0Pools

Before 0Pools	With 0Pools
Each product had to explain its own liquidity source, settlement record, and support trail.	Products can reference a common quote/trade/balance/status model.
Operations teams had to join fiat records, crypto records, provider exports, and support tickets manually.	Partner-facing ids are designed to join across API reads, webhooks, reports, and scan views.
A partner often asked for reserve or provider information because there was no clean product record to reconcile.	The integration contract gives them the record set they need without exposing treasury internals.
Price movement was often handled through broad buffers or manual support review.	Short-lived firm quotes bound the acceptance window and make expiry explicit.

Reconciliation flow

The flow deliberately uses multiple records. A browser callback can update UX, but durable settlement-facing state should come from verified events, server-side reads, reports, and approved operational records.

Example record joins

Partner object	0Pools object	Reconciliation use
Internal order id	`quote_id`	Proves which rate, pair, side, network, and expiry the user accepted.
Internal transfer id	`trade_id`	Tracks execution and terminal trade state.
User account ledger row	Partner-visible balance ledger entry	Shows prefunding, reserved amount, released amount, or settled amount.
Webhook delivery id	Event id and request id	Dedupes async updates and supports replay investigation.
Support case id	Quote/trade/request ids	Lets support inspect the same record chain without private route details.

Fields to preserve

Field	Why it matters
Asset symbol	Joins activity across payments, pools, scan views, and reports.
Amount string	Avoids floating-point rounding and preserves API-compatible formatting.
Product area	Routes support to 0Gate, 0Pools, 0Base, 0Link, 0Pools Scan, or Operations.
Product object id	Joins a session, quote, trade, transaction, link, payment intent, ledger row, or report row.
Partner reference	Joins 0Bit records to your order, invoice, account, user, or workflow.
Event id	Lets webhook handlers dedupe and replay safely.
Request id	Helps support debug failed reads, writes, and retries.
Status and timestamps	Shows lifecycle order and whether a record is terminal.

Settlement context by product

Product	Settlement-facing context
0Gate	Sessions, transactions, payment links, webhooks, and settlement tracking pages can connect user-facing payment flow to backend records.
0Pools	Quotes, trades, partner-visible balances, fees, rewards, and pool activity can support liquidity reconciliation for approved partners.
0Base	Payment objects, ledgers, reports, refunds, and webhook deliveries can describe normalized settlement records where reviewed.
0Pools Scan	Search and detail pages can show transaction, asset, swap, mint/burn, and pool activity for investigation.
Operations	Reconciliation, settlement reports, audit trails, incident handling, and status monitoring explain how records are compared.

Implementation pattern

Store settlement-facing data in your own system as immutable event facts plus a mutable summary row. The event facts let finance and support reconstruct what happened. The summary row lets product screens show the current state.

{
  "partner_order_id": "order_9182",
  "pool_id": "EUR-USDT",
  "quote_id": "pool_quote_123",
  "trade_id": "pool_trade_456",
  "side": "on_ramp",
  "fiat_amount": "100.00",
  "crypto_amount": "108.20",
  "network": "tron",
  "status": "settled",
  "last_event_id": "evt_pool_transaction_settled_789",
  "request_id": "req_abc"
}

This does not prove reserves by itself. It gives your product, finance, and support teams the durable join keys needed to reconcile partner-visible activity against approved records.

Integration guardrails

Avoid product copy or integration behavior that turns asset status into financial guarantees, universal availability claims, payout timing promises, bank-balance disclosures, treasury-allocation disclosures, or provider-path disclosures.

Use wording such as:

"configured asset"
"settlement-aware record"
"where enabled"
"where indexed"
"reviewed report"
"availability varies by entitlement and environment"
"reconcile against signed events, API reads, reports, and scan visibility"

Claims checklist

Before relying on a stronger reserve or settlement claim in your product experience, confirm that it is included in your approved 0Pools contract:

Claim type	Treat as approved only when
Asset is live for an account, country, or rail	It appears in capability/discovery responses for the correct environment.
Reserve, backing, or redemption language	The wording is explicitly part of your agreement and product surface.
Settlement cadence or payout timing	The timing is returned by the product or agreed in launch documentation.
Provider, bank, venue, or treasury detail	The detail is explicitly exposed through an approved partner record.
API contract for reports or ledgers	The endpoint or export is documented in the API reference or enabled for your account.

Ledger-grade settlement model

A reserve or settlement page is institutional only if finance can close books from it. The partner-facing model should support append-only ledger rows.

Ledger field	Example	Rule
`ledger_entry_id`	`ledger_0pools_772`	Unique and immutable.
`trade_id`	`pt_live_9A2`	Required join key.
`entry_type`	`debit`, `credit`, `release`, `return`	Never infer from sign alone.
`asset`	`EUR`, `USDT`	Store asset separately from amount.
`amount`	`100.00`	Store as string/minor units, not floating point.
`effective_at`	ISO timestamp	Used for close period.
`status_basis`	`settled`	Explains why the row exists.

Double-entry style example

{
  "trade_id": "pt_live_9A2",
  "entries": [
    { "account": "partner_prefunded_eur", "type": "debit", "asset": "EUR", "amount": "100.00" },
    { "account": "partner_user_usdt", "type": "credit", "asset": "USDT", "amount": "107.42" }
  ],
  "status_basis": "settled"
}

Close control

Exception	Close action
Trade settled but no ledger row.	Hold close and regenerate ledger from trusted status.
Ledger row without known trade.	Escalate with ledger id and request id.
Amount mismatch.	Compare accepted quote terms, terminal status, and ledger entry.

Implementation depth

This page is about explaining settlement-facing records without exposing reserves. For developers, the durable boundary is simple: your product should depend on partner-visible balances, trade status, settlement references, and reconciliation rows; it should not depend on reserve allocation, treasury balances, refill policy, and route details. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.

Product scenario

A finance team asks why a user balance changed. The partner can answer from quote, trade, ledger, and settlement records without needing private reserve data.

Before and after in practice

Before 0Pools	With 0Pools
Support asks operations to inspect treasury systems because the product did not store enough partner-visible context.	The product stores the full partner-facing chain and escalates only when terminal states conflict.
Product teams infer liquidity behavior from provider-specific screens or manual notes.	Product teams branch on 0Pools objects: pool, quote, trade, balance, webhook, and ledger.
Support asks engineering to reconstruct state from logs.	Support starts from request id, quote id, trade id, event id, and ledger id.

System flow

Records to keep

Record	Why it matters	Example
`reserved_amount`	Amount held for execution.	`100.00`
`settled_amount`	Amount confirmed by terminal state.	`99.50`
`ledger_entry_id`	Partner finance record.	`led_123`
`reconciliation_batch`	Daily close reference.	`2026-06-28`

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": "reserves-and-settlement",
  "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

Failure mode	Product response
Reserve assumptions in UI	Only show partner-visible balances and states.
Settlement and ledger mismatch	Pause close and compare trade, webhook, and ledger ids.
Partial context	Store request id and event id with every mutation.
Private balance requested	Use availability/balance endpoints, not treasury concepts.

Use-case patterns

Pattern	How 0Pools helps
Daily close	Reconcile trades to ledger entries.
Audit packet	Show why a balance moved.
Exception review	Investigate failed, released, or returned trades.

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.