Remittance liquidity

Remittance products need local funding, conversion, delivery, support, and reconciliation. 0Pools can support approved remittance-style flows when the partner owns the customer journey and 0Bit has approved the corridor and liquidity model.

Remittance problem

Without a pool network, a remittance app often has to coordinate:

• local fiat collection
• FX quote logic
• stablecoin acquisition
• wallet delivery or payout
• failed/returned payment handling
• customer support evidence
• finance reconciliation

0Pools does not replace the partner's compliance obligations. It gives the backend a quote/trade/status layer for approved liquidity.

Flow

Design pattern

Before and after

Caution

Do not present remittance coverage by country or payout method unless that exact corridor is approved. 0Pools describes infrastructure, not legal availability.

Corridor architecture

0Pools should be treated as the conversion and liquidity layer inside a larger remittance product. The partner remains responsible for the customer journey, sender/recipient model, disclosures, fraud handling, and any local payout workflow.

Example corridor records

Why this matters socially

Remittance users often care less about the underlying crypto mechanics than about clear value, predictable status, and support when something is delayed. 0Pools helps by making the conversion layer more explicit:

• Users do not wait on a hidden manual quote.
• The quote has a timer, so stale terms do not silently persist.
• The partner can show pending, settled, failed, or returned states instead of vague "processing" forever.
• Support teams can trace one joined record chain instead of searching fiat, stablecoin, and provider systems separately.

This improves the practical reliability of cross-border value movement, but product experiences should still avoid promising instant delivery, universal corridors, or guaranteed payout methods.

Example user messaging

Never expose internal route, treasury, or provider language to end users.

Remittance product timeline

A remittance-style product needs a user-readable timeline and a finance-readable record chain.

Remittance support record

{
  "sender_reference": "sender_991",
  "recipient_reference": "recipient_332",
  "partner_order_id": "remit_2026_0001",
  "pool_id": "EUR-USDT",
  "quote_id": "pq_live_01J4",
  "transact_id": "pt_live_9A2",
  "status": "settled",
  "receipt_available": true
}

Remittance guardrails

• Do not show exact settlement completion until terminal status is known.
• Do not promise a corridor that discovery does not return.
• Do not reuse expired quotes for a delayed sender confirmation.
• Keep recipient-facing copy based on status, not source/provider details.

Implementation depth

This page is about designing remittance-style liquidity around quote locks and reconciliation. For developers, the durable boundary is simple: your product should depend on conversion terms, user-facing pending states, and partner ledger references; it should not depend on local payout networks, liquidity sources, and settlement rails. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.

Product scenario

A user sends value to family in another country. 0Pools handles the conversion leg; the partner tracks local recipient delivery separately and reconciles both legs by reference.

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