Entitled pool network

The entitled pool network is the partner-specific view of 0Pools. It is not a global order book and it is not a public list of all possible liquidity. Each partner sees the pools 0Bit has approved for that organization, environment, tier, and product use case.

Network model

What entitlement includes

Why not show every pool?

Showing every theoretical pool would create bad user experiences and compliance risk. A pool can be technically possible but not approved for a partner, country, product, side, asset, network, limit, or funding model.

0Pools deliberately makes discovery partner-scoped:

• A partner sees only allowed pools.
• A cross-tenant object should not reveal another partner's resource.
• Runtime availability is separate from entitlement.
• A pool can be entitled but temporarily unavailable.

Before and after

Implementation pattern

1. Call discovery when the user starts a flow.
2. Cache briefly, but revalidate before quote.
3. Hide absent pools.
4. Disable unavailable pools with a clear message.
5. Store the pool id used for every quote and trade.

Example UI copy

Use account-safe wording:

• "This route is not enabled for your account."
• "This pool is temporarily unavailable."
• "Refresh to check current liquidity."

Avoid:

• "0Bit has no inventory."
• "Provider X is down."
• "Treasury rebalance pending."

Those statements expose internal operations and may be wrong by the time the user reads them.

Network slice example

The network can support multiple products and partners, but each integration sees only its approved slice. That is what makes 0Pools infrastructure instead of a public liquidity marketplace.

Example discovery result shape

{
  "environment": "live",
  "partner_id": "partner_123",
  "pools": [
    {
      "pool_id": "EUR-USDT",
      "status": "enabled",
      "capabilities_url": "/v1/pools/EUR-USDT/capabilities"
    },
    {
      "pool_id": "EUR-USDC",
      "status": "enabled",
      "capabilities_url": "/v1/pools/EUR-USDC/capabilities"
    }
  ]
}

Use the API reference for exact field names. The important product rule is that discovery is partner-scoped and environment-scoped.

Why entitlement is social infrastructure

Open-ended access to liquidity can create bad outcomes: unsupported corridors, unclear compliance responsibilities, stale rates, and users receiving confusing errors. Entitlement gives 0Bit a way to expose shared liquidity responsibly:

• Partners see only reviewed lanes.
• Product teams can launch a corridor deliberately.
• Support knows whether a problem is access, capability, or runtime availability.
• Finance can reconcile each movement against the pool that was actually used.
• 0Bit can expand the network without making every lane visible to every account.

Developer checklist

• Never hard-code a pool just because it exists in documentation.
• Store the environment with every quote and trade.
• Re-run discovery when switching between sandbox and live.
• Treat missing pools as configuration state, not user error.
• Escalate unexpected pool visibility immediately.

Entitlement implementation contract

Entitlement is not just a UI filter. It is an authorization boundary that decides which pools the partner can discover, quote, execute, monitor, and reconcile.

Entitlement snapshot example

{
  "partner_id": "partner_01H",
  "environment": "live",
  "pool_id": "EUR-USDT",
  "status": "active",
  "sides": ["buy"],
  "networks": ["ethereum", "polygon"],
  "limits": {
    "min_source_amount": "50.00",
    "max_source_amount": "25000.00"
  },
  "funding_required": true,
  "webhook_required": true
}

Entitlement tests

Implementation depth

This page is about using entitlements as the shape of the liquidity network. For developers, the durable boundary is simple: your product should depend on only the pools, sides, limits, and networks approved for the account; it should not depend on the full universe of available liquidity and how it is sourced. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.

Product scenario

Two partners log in on the same day. One sees EUR-USDT buy only, another sees EUR-USDT and EUR-USDC with different limits. Both products render from discovery instead of assuming a global catalog.

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": "entitled-pool-network",
  "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.