Route priority
How to understand 0Pools route priority without depending on private routing internals.
Route priority is the private order in which 0Bit chooses how to satisfy an accepted quote. It is intentionally not a partner API field. Partners should consume the result: quote terms, availability, trade status, and reconciliation records.
Why route priority is private
Private route priority can depend on:
- Pool health.
- Current inventory.
- Settlement readiness.
- Risk controls.
- Venue availability.
- Product-specific compliance constraints.
- Cost and timing.
Those inputs change often. If partners depended on them, every operational change would become a breaking change.
Partner model
What to build instead
| Need | Build on |
|---|---|
| User route choice | Entitled pool and capability data. |
| Price display | Quote response. |
| Execution proof | Trade id and status. |
| Failure handling | Error code, unavailable reason, terminal status. |
| Support investigation | Request id, quote id, trade id. |
Route wording
Safe:
- "0Pools selected an available execution path."
- "This pool cannot quote the request right now."
- "Retry with a fresh quote."
Unsafe:
- "Provider X will fill this."
- "Route Y is always cheapest."
- "0Bit inventory is low."
Before and after
| Before 0Pools | With 0Pools |
|---|---|
| Partner app encodes route preferences. | Partner app requests an approved pool quote. |
| Route details leak into UX and support. | UX sees price, status, and support ids. |
| Changing a route requires partner code changes. | 0Bit can improve routing behind the same API contract. |
Route priority vs product priority
| Priority type | Who controls it | Example |
|---|---|---|
| Product priority | Partner and approved configuration. | Which entitled pool the user can choose, maximum amount, side, network. |
| Quote priority | 0Pools quote layer. | Whether a firm quote can be issued for the request right now. |
| Execution priority | 0Bit internal operations. | How a reserved trade is fulfilled behind the product contract. |
| Support priority | Partner and 0Bit support process. | How incidents are triaged by age, amount, status, and request id. |
Only the first and last categories belong in partner product code. Quote and execution priority should be consumed as outcomes.
Example route-safe data model
{
"pool_id": "EUR-USDT",
"side": "on_ramp",
"network": "tron",
"quote_id": "pool_quote_123",
"trade_id": "pool_trade_456",
"status": "reserved",
"support_priority": "normal",
"route_priority": null
}Leaving route_priority empty is intentional. It prevents downstream dashboards from depending on an internal signal that can change without notice.
Operational examples
| Situation | Partner-safe interpretation |
|---|---|
| Quotes unavailable for a pool. | The pool cannot satisfy this request right now. |
| Quote fields are wider than expected. | The returned quote is the terms for this request; users may refresh or decline. |
| Trade is reserved longer than usual. | Settlement is pending; keep the user's state non-final and escalate with ids. |
| Terminal status is failed/released/returned. | Follow the product's refund, release, or support flow. |
Why this supports infrastructure evolution
0Pools is infrastructure. Its internal route priority may change as pool health, inventory, settlement readiness, risk controls, and product programs evolve. A stable public boundary lets 0Bit improve the network without forcing every partner to rewrite code or retrain support whenever a private route changes.
Priority without dependency
Route priority can improve execution behind the scenes, but partner code should not depend on which route won.
| Partner need | Stable product model | Why not route priority |
|---|---|---|
| Cheapest executable quote | Request quote and show returned terms. | Priority may change with risk, inventory, and settlement state. |
| Faster settlement | Monitor status and terminal outcomes. | Route speed is not a public contract unless separately agreed. |
| Better support | Preserve quote/trade/request ids. | Route labels do not help user-facing support. |
| Resilience | Handle unavailable and retry states. | Hard-coded route fallback breaks when routing changes. |
Route-agnostic record
{
"partner_order_id": "order_7841",
"pool_id": "EUR-USDT",
"quote_id": "pq_live_01J4",
"accepted_terms": {
"source_amount": "100.00",
"target_amount": "107.42",
"expires_at": "2026-06-28T20:14:30Z"
},
"route_priority": null,
"status": "reserved"
}Product rule
If a product requirement says "prefer route X," rewrite it as a user-visible requirement: lower price, faster settlement target, supported network, higher limit, or better availability. Then let 0Pools return the executable quote under the approved product surface.
Implementation depth
This page is about letting 0Pools prioritize routes while partners build stable products. For developers, the durable boundary is simple: your product should depend on accepted quote terms, status, and availability outcome; it should not depend on route ranking, source priority, fallback rules, and execution path. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.
Product scenario
A partner asks to prefer the cheapest route. The product should request a quote and rely on 0Pools to return executable terms rather than encoding private route priority in partner code.
Before and after in practice
| Before 0Pools | With 0Pools |
|---|---|
| Partner code contains provider priority lists that become stale and create routing regressions. | Partner code validates quote terms and lets 0Pools evolve routing without breaking the integration. |
| 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 |
|---|---|---|
quote_id | Represents the selected executable terms. | pq_test_123 |
available | Route outcome as a product signal. | true |
unavailable_reason | Reason when no safe route exists. | rate_unavailable |
terms_accepted_at | When the user accepted the terms. | 2026-06-28T... |
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-priority-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 |
|---|---|
| Route list in code | Remove provider priority from partner systems. |
| Cheapest-only UX | Use all-in executable quote terms. |
| Retry to force route | Retry only on safe transient failures. |
| Route name in support copy | Use pool id and quote id. |
Use-case patterns
| Pattern | How 0Pools helps |
|---|---|
| Backend simplification | Delete routing tables from partner code. |
| Support analysis | Trace terms, not source. |
| Product iteration | Change route policy without client releases. |
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.