Market-maker terms
How to discuss market-maker and liquidity-provider concepts without exposing private 0Pools commercial terms.
0Pools may use private liquidity relationships, internal inventory, routing, and hedging to support partner-visible quotes. Those commercial terms are not part of the public developer API. The partner contract is the quote, not the private market-maker agreement behind it.
Public vs private economics
| Public to partner | Private to 0Bit |
|---|---|
rate | Source venue, maker/taker details, hedge route. |
spreadBps | Internal spread policy and inventory skew. |
feeBps | Contractual partner tier or negotiated fee. |
| Quote expiry | Internal market risk window. |
| Availability | Source depth and operational readiness. |
What developers can say
Use product-safe wording:
- "The quote includes the partner-visible rate and fees."
- "Firm quotes are short-lived and single-use."
- "Availability can change based on liquidity and account configuration."
- "Your account terms are confirmed during onboarding."
Avoid:
- Naming a market maker or venue.
- Promising a fixed spread for every account.
- Claiming zero cost or zero market risk.
- Exposing private rebate, fee, route, or inventory terms.
Why this boundary matters
If the partner UI exposes private terms, then every commercial or routing change becomes a product incident. Keep the UI anchored to approved quote fields.
Suggested disclosure shape
For user-facing products:
"You are seeing a time-limited quote. The final amount is locked only after you accept before expiry. Fees and spreads shown here are the partner-visible terms for this transaction."
For internal operator tooling:
"Investigate with pool id, quote id, trade id, request id, and timestamp. Do not infer private market-maker terms from public quote fields."
Commercial boundary diagram
The quote response is the bridge between internal liquidity economics and partner product behavior. Developers should build product copy, ledger records, and support workflows from the quote response, not from assumptions about the commercial arrangement behind it.
Before and after
| Before 0Pools | With 0Pools |
|---|---|
| Each partner negotiated and integrated directly with a liquidity source. | Approved partners integrate to one quote/trade surface. |
| Product copy described provider-specific pricing rules. | Product copy describes quote-specific fields and expiry. |
| Commercial changes required partner UI changes. | Internal economics can change without changing the partner contract. |
| Support tickets asked which market maker filled a trade. | Support tickets use pool id, quote id, trade id, request id, and timestamps. |
Example claims by audience
| Audience | Safe focus | Unsafe focus |
|---|---|---|
| End user | Time-limited rate, final amount, fee/spread fields where shown. | Provider identity or internal route. |
| Partner developer | Quote object, expiry, status, idempotency, ledger joins. | Market-maker agreements or treasury source. |
| Partner finance | Settlement-facing rows, reports, quote/trade ids. | 0Bit's private reserve allocation. |
| Sales/commercial | Access model and approved program terms. | Universal spread, best-price, or zero-risk promises. |
Reviewer questions
- Is the statement based on returned fields or private economics?
- Does it imply a fixed market-maker relationship?
- Does it imply every partner receives the same fee or spread?
- Does it imply that quote availability is guaranteed?
- Does it expose anything that would require a liquidity, finance, or legal review?
If any answer is yes, keep that wording out of the product experience unless it is explicitly covered by your approved program terms.
Quote economics boundary
Partners need enough economics to explain the user price, but not private commercial terms.
| Field type | Safe to expose when returned? | Example use |
|---|---|---|
| Source amount | Yes. | "You pay 100.00 EUR." |
| Target amount | Yes. | "You receive 107.42 USDT." |
| Fee shown to partner | Yes, if returned in the approved quote surface. | Receipt and ledger explanation. |
| Spread/price component | Yes only as returned and approved. | Pricing disclosure. |
| Provider margin | No. | Do not show or infer. |
| Route-specific commercial term | No. | Do not store in partner product logic. |
Economics example
{
"quote_id": "pq_live_01J4",
"source_asset": "EUR",
"source_amount": "100.00",
"target_asset": "USDT",
"target_amount": "107.42",
"fee_amount": "1.00",
"expires_at": "2026-06-28T20:14:30Z",
"disclosure": "Final amount is fixed until quote expiry."
}Review checklist for public claims
| Claim | Required evidence |
|---|---|
| "No slippage after acceptance." | Firm quote TTL and accepted quote record. |
| "Transparent fee." | Fee field returned for the partner surface. |
| "Best route." | Avoid unless contractually approved; say "0Pools returned an executable quote." |
| "Guaranteed rate." | Only within the firm quote expiry window. |
Implementation depth
This page is about keeping market-maker economics separate from developer-facing quote fields. For developers, the durable boundary is simple: your product should depend on all-in rate, spread bps, fee bps, quote expiry, and pool availability; it should not depend on market-maker agreements, inventory commitments, rebates, and hedging behavior. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.
Product scenario
A partner wants to tell users why the quote differs from a public market price. The product can explain all-in pricing, spread, and fees without naming counterparties or promising a private term.
Before and after in practice
| Before 0Pools | With 0Pools |
|---|---|
| Sales or product copy borrows internal commercial language and creates expectations the API does not guarantee. | The user sees clear all-in quote terms, and the partner keeps private economics out of product claims. |
| 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 |
|---|---|---|
rate | All-in quote rate. | 1.0731 |
total_bps | Spread plus fee where surfaced. | 55 |
expires_at | When the firm quote becomes stale. | 2026-06-28T... |
claim_basis | Which field supports product copy. | quote response |
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": "market-maker-terms-review",
"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 |
|---|---|
| Guaranteed spread claim | Use bounded quote terms, not universal promises. |
| Counterparty named | Keep counterparties outside product UI. |
| Fee hidden from ledger | Store fee fields returned by the API. |
| Market comparison overpromised | Compare only where your product has approved methodology. |
Use-case patterns
| Pattern | How 0Pools helps |
|---|---|
| Pricing FAQ | Explain why quotes can move. |
| Enterprise review | Show quote fields without private contracts. |
| Support ticket | Trace the displayed rate to quote id. |
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.