Partner-visible utilization
How partners should think about usage, volume, limits, availability, and utilization without seeing private pool inventory.
Partner-visible utilization is about your account's activity and limits, not 0Bit's total inventory. It helps you understand how much of your approved program you are using and where product UX may need to adapt.
Utilization signals
| Signal | Use |
|---|---|
| Quote count | Demand and user interest. |
| Quote availability | Whether users can receive prices. |
| Accepted quote rate | Whether pricing/UX works. |
| Reserved notional | Pending execution volume. |
| Settled notional | Completed program volume. |
| Failed/released notional | Operational quality. |
| Balance available | Prefunded capacity where enabled. |
| Limit errors | Need for account review or UX gating. |
Conceptual view
What utilization is not
It is not:
- total 0Bit treasury balance
- total exchange inventory
- market maker capacity
- future guarantee of availability
- an SLA by itself
Product uses
Use utilization to decide:
- when to prompt top-up
- when to pause large orders
- when to request higher limits
- when to show alternate pools
- when to escalate repeated unavailable quotes
Example dashboard row
{
"pool_id": "EUR-USDT",
"quotes_1h": 142,
"accepted_1h": 37,
"reserved_notional": "4250.00",
"settled_notional_24h": "39120.00",
"unavailable_rate": "3.2%",
"balance_available": "12800.00"
}Utilization graph
This kind of graph helps the partner understand product demand without exposing total 0Bit inventory. The values should describe the partner's own activity: quote demand, accepted volume, reserved notional, settled notional, and unavailable rate.
Before and after
| Before 0Pools | With partner-visible utilization |
|---|---|
| Product teams asked operations for raw pool balances. | Product teams track their own quote, reserve, settlement, and balance signals. |
| A sudden spike looked like a liquidity problem, a UX problem, or a support problem at the same time. | Utilization separates demand, acceptance, execution, and settlement quality. |
| Finance waited for manual exports to know what happened. | Finance can start with ledger rows, trade ids, and terminal statuses. |
| Growth teams could not tell whether limits or UX were blocking users. | Limit errors, expiry rates, and unavailable reasons point to the next review. |
How to use it
Use utilization as a product-control input:
- If quote demand is high but acceptance is low, review pricing display, expiry UX, and network selection.
- If acceptance is high but reserved notional grows, monitor settlement progress before increasing volume.
- If balance available is low, prompt the partner admin to top up before users see failures.
- If unavailable rate is localized to one pool, show alternate entitled pools where approved.
- If limit errors rise, request an account review instead of hard-coding higher limits.
What to store
{
"window": "1h",
"pool_id": "EUR-USDT",
"quote_requests": 142,
"firm_quotes": 96,
"accepted_quotes": 37,
"reserved_notional": "4250.00",
"settled_notional": "39120.00",
"expired_quotes": 18,
"unavailable_reasons": {
"pool_dry": 2,
"rate_unavailable": 1
}
}This record is partner-scoped. It should not be merged with private pool-wide inventory metrics or shown as a promise of future liquidity.
Utilization formula discipline
Utilization should help partners understand usage and capacity without exposing private inventory.
| Signal | Example formula | Use |
|---|---|---|
| Quote utilization | quoted volume / approved daily band. | Product demand monitoring. |
| Execution utilization | settled volume / approved daily band. | Finance and capacity planning. |
| Reserved utilization | reserved amount / partner-visible available balance. | Operational alerting. |
| Failure utilization | failed quote attempts / total quote attempts. | UX and availability review. |
Utilization row
{
"pool_id": "EUR-USDT",
"period": "2026-06-28",
"quoted_volume": "184000.00",
"settled_volume": "172500.00",
"reserved_amount": "12000.00",
"quote_success_rate": "0.982",
"ledger_exception_count": 2
}Interpretation rules
High utilization is not automatically bad, and low utilization is not automatically safe. Always read utilization together with quote success, reserved age, available balance, and support tickets.
Implementation depth
This page is about using utilization signals without seeing private pool inventory. For developers, the durable boundary is simple: your product should depend on usage, volume, limit consumption, availability history, and quote/trade counts; it should not depend on reserve ratios, venue balances, and internal capacity targets. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.
Product scenario
A partner wants to understand whether its product is approaching configured limits. The dashboard shows usage and availability trends, not private 0Bit inventory.
Before and after in practice
| Before 0Pools | With 0Pools |
|---|---|
| Teams ask for raw liquidity balances and build decisions around data they cannot safely rely on. | Teams use partner-visible utilization signals to plan product behavior and support capacity. |
| 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 |
|---|---|---|
volume_24h | Partner-visible executed volume. | 12500.00 |
quote_count | Quote attempts in period. | 421 |
limit_usage | Percent of configured limit used. | 64% |
availability_minutes | Minutes lane was available. | 1435 |
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-visible-utilization",
"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 |
|---|---|
| Private inventory requested | Use utilization and limits instead. |
| Volume mistaken for capacity | Capacity is governed by approval and availability. |
| No time window | Always attach utilization to a period. |
| Dashboard drives execution | Use runtime quote response for actual execution. |
Use-case patterns
| Pattern | How 0Pools helps |
|---|---|
| Growth planning | Estimate launch capacity. |
| Limit tuning | Review usage against approved bounds. |
| Product analytics | See where users encounter unavailable lanes. |
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.