Route selection
How 0Pools route selection should be represented in partner integrations.
Route selection is an internal implementation detail. The partner chooses an approved pool, side, amount, network, and destination. 0Pools decides whether it can quote and execute that request.
Partner choice vs 0Bit choice
| Chosen by partner | Chosen by 0Bit internally |
|---|---|
| Pool id from discovery. | Liquidity source. |
| Side and amount. | Reserve or fallback strategy. |
| Network and destination address. | Venue and settlement worker path. |
| Accept/reject firm quote. | Private route execution. |
Route selection flow
What to expose
Expose enough for the partner to operate:
- pool id
- pair
- side
- amount
- network
- quote id
- quote expiry
- trade id
- status
- request id
Do not expose:
- route priority
- provider name
- venue account
- source inventory
- internal reserve path
Why this is better
Before 0Pools, route choice often leaked into product code. Every new provider or fallback required UI and support changes. With 0Pools, route selection can improve privately while the partner contract remains stable.
Developer implementation model
Treat route selection as an outcome, not as an input. Your backend asks for a quote on an entitled pool and records the public outcome. If a quote is available, your product can show the returned rate, fee, spread, expiry, and destination details. If a quote is unavailable, your product can offer retry, a smaller amount, or another entitled pool.
{
"partner_order_id": "order_1942",
"pool_id": "EUR-USDT",
"side": "on_ramp",
"amount": "250.00",
"network": "tron",
"quote_id": "pool_quote_123",
"route_label": "0Pools",
"support_reason": "quote_available"
}route_label should stay generic. It is useful for product analytics, but it must not become a private provider name, venue account, or reserve source.
Before and after in product code
| Old product code | 0Pools product code |
|---|---|
if provider_a_down then try provider_b | if quote unavailable then show retry or alternate entitled pool |
| UI names the route that filled the order. | UI names the product outcome: quoted, pending, settled, failed, released. |
| Support asks which internal rail moved funds. | Support asks for quote id, trade id, request id, and partner order id. |
| Product releases require route wiring changes. | Route changes can happen inside the liquidity layer without partner UI churn. |
Route decision diagram
This is the level of detail support teams should use. Anything beneath "0Pools quote request" belongs to internal operations.
Partner choice versus 0Pools choice
The partner chooses product intent. 0Pools chooses how to satisfy that intent under the approved pool contract.
| Decision | Chosen by partner | Chosen by 0Pools |
|---|---|---|
| User journey | Yes. | No. |
| Pool lane requested | Yes, from entitled discovery. | Controls whether it is available. |
| Asset/network shown | Yes, from capabilities. | Controls runtime support. |
| Quote terms | No, partner requests terms. | Yes, returned as quote. |
| Execution route | No. | Yes. |
| Settlement status | No. | Returned through status/webhook. |
Route-safe backend shape
{
"order_id": "order_7841",
"selected_pool_id": "EUR-USDT",
"selected_network": "polygon",
"quote_id": "pq_live_01J4",
"route_selection": "not_exposed",
"status": "reserved"
}Implementation rule
Expose choices the user can understand and the partner is approved to offer: amount, asset, network, destination, quote acceptance. Do not expose route ranking, provider labels, or fallback order as product choices.
Implementation depth
This page is about representing route selection as an internal 0Pools decision. For developers, the durable boundary is simple: your product should depend on quote availability, accepted terms, and resulting trade state; it should not depend on source selection, split logic, fallback routing, and route scoring. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.
Product scenario
A partner asks for a selector between liquidity sources. The product should expose pool lanes and quote outcomes, not source menus that couple UX to private operations.
Before and after in practice
| Before 0Pools | With 0Pools |
|---|---|
| Users choose a route they do not understand, and the product inherits operational complexity. | Users choose the economic action; 0Pools chooses the execution route behind the API contract. |
| 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 |
|---|---|---|
intent | What the user wanted. | buy 100 EUR of USDT |
pool_id | Partner-visible lane. | EUR-USDT |
quote_terms | Accepted executable terms. | pq_test_123 |
status | Outcome of the trade. | settled |
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": "route-selection-boundaries",
"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 |
|---|---|
| Source picker in UI | Render lane picker instead. |
| Route-specific errors | Map to availability/status states. |
| Partner route override | Use approved product controls only. |
| Fallback route promise | Describe fallback as availability/outcome, not source. |
Use-case patterns
| Pattern | How 0Pools helps |
|---|---|
| Wallet UX | Keep choices simple. |
| Backend architecture | Avoid source adapters in partner code. |
| Support flow | Investigate by quote/trade ids. |
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.