Cross-border liquidity

Cross-border products need liquidity at the border between local money and internet-native money. 0Pools gives approved partners a way to quote and execute that conversion without building a full liquidity desk inside their product.

Before and after

Example flow

Good use cases

Guardrails

• Do not claim global coverage.
• Do not show unsupported countries or currencies.
• Do not promise settlement timing unless approved.
• Do not expose provider or bank route details.
• Do not update user balance until terminal state.

Records to keep

Store source currency, destination asset, network, destination address, quote id, trade id, status, request id, and user order id.

Cross-border operating model

0Pools is not a country-coverage claim by itself. It is an infrastructure layer that can support approved corridors by giving the partner a consistent conversion and status lifecycle.

Example product patterns

User experience before and after

Corridor review checklist

• Is the partner approved to own the customer journey?
• Is the pool entitled for this partner and environment?
• Are the side, network, amount limits, and destination rules enabled?
• Is user-facing corridor copy reviewed by product/compliance?
• Does finance know which ids close the reconciliation loop?
• Is the failure/return state mapped before launch?

Do not launch a new cross-border corridor by editing copy alone. It needs entitlement, liquidity, compliance, monitoring, support, and reconciliation review.

Corridor implementation model

A corridor is a product promise only when the partner is approved for the relevant pool, side, country/user profile, asset, network, limits, and settlement model.

Corridor scenario

{
  "corridor": "EUR-to-USDT",
  "sender_country": "FR",
  "product": "contractor_payout_wallet",
  "pool_id": "EUR-USDT",
  "network": "polygon",
  "quote_id": "pq_live_01J4",
  "status": "reserved"
}

Social infrastructure claim discipline

It is safe to say 0Pools helps approved products reuse liquidity infrastructure. Do not claim universal country coverage, guaranteed settlement time, or unlimited volume unless that exact promise is approved for the partner surface.

Implementation depth

This page is about using 0Pools in cross-border products without overclaiming corridor coverage. For developers, the durable boundary is simple: your product should depend on approved corridor-like pool lanes, quote terms, status, and ledger outcomes; it should not depend on settlement partners, source depth, and route mechanics per corridor. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.

Product scenario

A remittance app lets a sender fund EUR and deliver stablecoin value to a recipient-side wallet or balance. The product uses 0Pools for bounded conversion and keeps local payout logic separate.

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": "cross-border-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.