Partner liquidity programs

How to design an approved partner liquidity program around 0Pools access, funding, limits, monitoring, and support.

A partner liquidity program is bigger than an API key. It is the commercial, compliance, funding, limits, monitoring, and support wrapper around 0Pools access.

Program decisions

Decision	Examples
Product surface	Hosted 0Gate, headless 0Pools, merchant 0Base, or internal 0Link dependency.
Customer responsibility	Who owns onboarding, KYC/KYB/KYC package, disclosures, and user support.
Pools	Which pairs, sides, networks, and limits are enabled.
Funding	Prefunded balance, settlement cycle, top-up instructions.
Pricing	Partner tier, `feeBps`, spread disclosures, launch limits.
Events	Polling, webhook URL, signing secret, retry behavior.
Support	Evidence packet, escalation path, severity definitions.

Example program types

Program	Typical 0Pools role
Wallet funding	Quote and execute stablecoin delivery to user wallet.
Treasury movement	Convert business balances between fiat and stablecoin.
Card top-up	Liquidity leg before card balance credit.
Remittance support	Approved corridor quote and settlement state.
Platform payout	Backend liquidity layer behind partner ledger.

Go-live readiness

Before going live, prove:

Entitlements are correct.
Limits prevent oversized orders.
Webhooks verify signatures.
Duplicate accepts collapse idempotently.
Balance ledger reconciles.
Returned/failed cases have a runbook.
User messaging is approved.

Product language

Partners should describe the user-facing product outcome, not the liquidity program mechanics. "Your top-up is pending" is better than "treasury refill is waiting."

A liquidity program should scale only when the operational evidence supports it. That evidence is not private 0Bit inventory; it is partner-visible behavior: quote success, accepted quote rate, settlement outcomes, webhook health, balance movement, and reconciliation quality.

Example launch plan

Phase	Goal	Evidence
Design	Confirm that 0Pools is the right product rather than 0Gate.	Use-case review, compliance responsibilities, headless UX requirement.
Sandbox	Prove quote, transact, status, webhook, and ledger behavior.	Sandbox test records and replayable support packet.
Production pilot	Run limited real traffic.	First-day reconciliation, terminal state review, alert review.
Expansion	Increase pools, networks, limits, or volume.	Low failure rate, healthy balance process, support readiness.
Ongoing review	Keep the program aligned with risk and product needs.	Utilization reports, unresolved incident count, reconciliation exceptions.

Partner responsibilities

Area	Partner owns	0Pools provides
Customer UX	Screens, disclosures, confirmation, support language.	Quote fields, expiry, status, ids.
Compliance	Customer eligibility and product-specific obligations.	Account entitlement and product boundary signals.
Ledger	User balance state and finance records.	Trade status, partner balance ledger, reconciliation joins.
Funding	Prefunded balance process where required.	Funding instructions and balance records where enabled.
Support	First-line user investigation.	Request, quote, trade, event, and status evidence.

Anti-patterns

Launching a headless 0Pools flow when the partner actually needs the hosted 0Gate compliance and UX layer.
Using a live key before entitlements, funding, and webhooks are reviewed.
Increasing limits because demand exists, without checking settlement and reconciliation health.
Reusing sandbox copy that promises live corridors or assets.
Treating partner-visible utilization as proof of total 0Bit capacity.

Program operating agreement

A partner liquidity program should define who owns product UX, funding, support, monitoring, compliance evidence, and launch approval.

Area	Partner owns	0Pools provides
Product UX	User journey, receipts, support copy.	Pool/quote/trade/status primitives.
Funding	Prefunding plan and finance monitoring.	Partner-visible balance and ledger records.
Compliance	User onboarding and allowed use case evidence.	Product boundary and integration records.
Operations	Alerts, support packets, escalation process.	Status, request ids, events, and ledger references.
Launch	Sandbox evidence and production checklist.	Approved entitlements and production access.

Launch readiness record

{
  "program_id": "lp_partner_01",
  "product": "neobank_stablecoin_buy",
  "approved_pools": ["EUR-USDT"],
  "funding_ready": true,
  "webhooks_ready": true,
  "monitoring_ready": true,
  "support_ready": true,
  "first_order_limit": "500.00"
}

Program review cadence

Review limits, availability, failed trades, reserved-age alerts, support escalations, ledger exceptions, and user complaints on a regular cadence. A program is not "set and forget" once production access is granted.

Implementation depth

This page is about designing partner liquidity programs around access, funding, limits, and support. For developers, the durable boundary is simple: your product should depend on program type, enabled pools, limits, funding model, monitoring, and support workflow; it should not depend on commercial terms, treasury policy, and internal risk controls. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.

Product scenario

A platform launches 0Pools for several product lines. Each program defines which lanes are enabled, how balances are funded, what limits apply, and what evidence is needed for support.

Before and after in practice

Before 0Pools	With 0Pools
Every department invents its own launch process, producing inconsistent limits and support expectations.	The program has a repeatable operating model that maps access, usage, monitoring, and reconciliation to 0Pools records.
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
`program_id`	Your product program reference.	`lp_prog_123`
`enabled_lanes`	Pools in scope.	`EUR-USDT`
`funding_model`	How draws are backed.	`prefunded`
`support_sla_label`	Your support policy label.	`standard`

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": "partner-liquidity-programs",
  "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
No program boundary	Define use cases and limits before launch.
Shared keys across programs	Separate environments and products.
Unclear support path	Document which ids support needs.
Volume before monitoring	Start with dashboards and alerts.

Use-case patterns

Pattern	How 0Pools helps
Fintech launch	Enable controlled native crypto flows.
Treasury partner	Run repeatable conversion program.
Platform marketplace	Offer liquidity to several internal products.

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.