Spread and fee claims
How to explain 0Pools quote economics without overstating spreads, fees, or route guarantees.
0Pools quote economics are visible through rate, spreadBps, and feeBps. These fields are enough to explain a partner-visible quote. They do not expose internal liquidity economics.
Quote economics diagram
What each field means
| Field | Explain as |
|---|---|
rate | The all-in quote rate returned for this side. |
spreadBps | Pool FX spread included in the rate. |
feeBps | Partner tier draw fee included in the quote economics. |
totalBps when available | Derived spread plus fee for display/reconciliation. |
Safe claims
- "The quote shows partner-visible spread and fee fields."
- "The accepted quote is time-limited."
- "Fees depend on your partner tier or agreement."
- "Final execution state is confirmed by status/webhook."
Unsafe claims
- "Zero spread."
- "No slippage ever."
- "Best price in every market."
- "Guaranteed route."
- "All fees are the same for every partner."
Better before/after language
| Instead of | Say |
|---|---|
| "0Pools removes slippage." | "0Pools gives approved partners short-lived firm quotes that reduce exposed acceptance-window slippage." |
| "0Pools is always cheapest." | "0Pools centralizes liquidity access and exposes partner-visible economics." |
| "Fixed spread for everyone." | "Quote fields show the terms returned for this partner and request." |
Product page example
"This is a time-limited quote. The rate, spread, and fee shown are the terms for this request. Refresh for a new quote if the timer expires."
Claims review flow
Any public pricing claim should be traceable to the quote fields that the partner actually receives. If a claim needs knowledge of route priority, market-maker terms, reserve source, or treasury balance, it is not partner-safe by default.
Practical examples
| Context | Good wording | Why |
|---|---|---|
| Checkout review screen | "Rate valid until the quote expires." | Ties the displayed economics to the firm quote window. |
| Partner dashboard | "Spread and fee are shown on each quote where returned." | Describes fields without promising a fixed commercial model. |
| Sales deck | "Shared pool access can reduce the need for each partner to source liquidity separately." | Explains the product value without claiming universal best price. |
| Support article | "If the quote expires, request a new quote before executing." | Prevents stale-price execution assumptions. |
What 0Pools improves
Before 0Pools, a partner might add wide buffers because the user, product server, liquidity source, and settlement system were not aligned around one quote lifecycle. That could make final user pricing opaque and support harder.
0Pools improves the model by returning a quote object with explicit fields, an expiry, and a single-use execution path. The quote does not need to promise "zero spread" or "no slippage ever" to be valuable. The value is that the user sees the terms for this request, the partner records those terms, and execution/reconciliation can point back to the accepted quote.
Reviewer checklist
- Does the statement describe the returned quote fields, or does it imply hidden economics?
- Does the statement mention expiry when discussing a firm quote?
- Does the statement avoid "best", "zero", "guaranteed", and "always" unless contractually approved?
- Does the statement distinguish partner-visible fees from internal liquidity economics?
- Does the statement avoid provider, market-maker, route, or reserve details?
Claims-to-field mapping
Every public pricing claim should map to a returned field or approved product statement.
| Public claim | Required backing | Safer wording |
|---|---|---|
| "Fixed final amount." | Firm quote with expires_at and target amount. | "Final amount is fixed until the quote expires." |
| "Fee included." | Returned fee field or approved all-in quote. | "The quote shows the amount you pay and receive." |
| "No hidden spread." | Approved economics disclosure. | "The quote is shown before you accept." |
| "Best available rate." | Avoid unless contractually supported. | "0Pools returns an executable quote for your account." |
Receipt example
{
"quote_id": "pq_live_01J4",
"source_amount": "100.00",
"source_asset": "EUR",
"target_amount": "107.42",
"target_asset": "USDT",
"fee_disclosure": "Included in quoted amount",
"accepted_at": "2026-06-28T20:13:10Z"
}Review workflow
- Identify the exact claim in UI, marketing copy, receipt, or support macro.
- Link it to a 0Pools field or approved wording.
- Remove route/provider/commercial-term language.
- Test the copy against expired, failed, returned, and unavailable outcomes.
Implementation depth
This page is about making accurate product claims about spread, fees, and quote economics. For developers, the durable boundary is simple: your product should depend on returned quote fields and approved explanatory copy; it should not depend on internal spread policy, source economics, and route-level profitability. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.
Product scenario
A product page draft might say 0Pools has zero slippage. The safer product claim is that accepted firm quotes bound the execution terms for a short window; exact economics come from the quote response.
Before and after in practice
| Before 0Pools | With 0Pools |
|---|---|
| Generic claims create expectations that no market system can always satisfy. | Claims are tied to actual fields: all-in rate, spread bps, fee bps, expiry, and execution status. |
| 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 |
|---|---|---|
claim | Text shown in product. | Firm quote locks terms until expiry. |
field_basis | Which API fields support it. | quoteId, expiresAt, rate |
audience | Where the claim appears. | checkout |
last_reviewed_at | Keeps claims current. | 2026-06-28 |
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": "spread-claims-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 |
|---|---|
| Zero slippage promise | Say firm quotes bound accepted terms, not that markets never move. |
| Hidden fee wording | Explain fees from returned fields. |
| Route guarantee | Avoid claims about private route behavior. |
| Permanent rate promise | Tie every price to quote expiry. |
Use-case patterns
| Pattern | How 0Pools helps |
|---|---|
| Checkout copy | Explain final price clearly. |
| Sales enablement | Avoid unsupported economics claims. |
| Support FAQ | Describe quote movement honestly. |
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.