Liquidity safeguards

0Pools is headless, so safeguards matter more than they do in a hosted widget. The API assumes the partner owns the UI and uses server-side controls to keep quote, execution, balance, and settlement behavior bounded.

Safeguard map

Main safeguards

Slippage and quote risk

0Pools reduces exposed slippage by making the acceptance window explicit: a firm quote is time-limited and single-use. That does not mean markets have no risk; it means the partner UX should not accept an expired or unavailable price.

Developer checklist

• Never execute from the browser.
• Disable accept when the firm quote expires.
• Send a stable Idempotency-Key.
• Treat unavailable quotes as normal.
• Persist the exact quote and trade ids.
• Update customer ledger only from terminal status.
• Alert on stuck reserved trades.

Anti-patterns

Safeguard lifecycle

Each step has a distinct safety job. Discovery prevents unauthorized pool use. Quote expiry limits stale-price acceptance. Idempotency prevents duplicate execution. Terminal status prevents premature final ledger updates.

Threat model for headless liquidity

Before and after safeguards

Production readiness questions

• Can a user accept after quote expiry?
• Can the browser see a secret key?
• Can two clicks create two trades?
• Can a pending trade credit final balance?
• Can support trace an order without private route information?
• Can finance match partner order, quote, trade, ledger, and webhook event?

Any "yes" to the first four or "no" to the last two should block launch.

Threat model and controls

Institutional integrations need explicit controls for money movement failure modes.

Webhook processing guard

async function processPoolEvent(event: PoolEvent) {
  await verifySignature(event);
  const inserted = await db.events.insertOnce(event.id, event);
  if (!inserted) return;

  const trade = await db.trades.findById(event.data.transactId);
  await db.trades.updateStatus(trade.id, event.data.status);

  if (event.data.status === 'settled') {
    await ledger.postSettlement(trade.id, event.data.ledgerRef);
  }
}

Production readiness evidence

A partner should be able to show logs for idempotency retries, webhook signature verification, expired quote rejection, ledger posting, and support escalation using only partner-visible ids.

Implementation depth

This page is about understanding safeguards that bound headless liquidity flows. For developers, the durable boundary is simple: your product should depend on account gates, amount limits, quote expiry, idempotency, status, and reconciliation; it should not depend on risk thresholds, monitoring internals, and treasury controls. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.

Product scenario

A high-traffic app adds a buy button. Safeguards ensure the button cannot execute without entitlement, cannot reuse stale terms, cannot double-submit, and cannot mark final balance before terminal state.

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-safeguards",
  "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.