Stablecoin conversion
How 0Pools supports approved fiat-to-stablecoin conversion with quote locks, networks, destination addresses, and reconciliation.
Stablecoins are the primary crypto asset class 0Pools is designed around. The goal is not to expose raw exchange operations; it is to let approved partners quote and execute stablecoin conversion with clear state.
Conversion types
| Flow | Meaning | Current posture |
|---|---|---|
on_ramp | Fiat in, stablecoin out. | Primary supported path. |
off_ramp | Stablecoin in, fiat out. | Gated; show only if enabled. |
| Treasury conversion | Business inventory movement. | Requires approved partner program. |
Stablecoin flow
Address and network handling
For an on-ramp:
- User provides destination wallet.
- Partner validates address format and network selection.
- Backend creates firm quote with
destAddressand optionaldestNetwork. - 0Pools locks the destination on the quote.
- Execution uses the quote-bound destination, not a transact-body field.
This protects users from late delivery redirection.
Stablecoin UX checklist
- Show asset and network.
- Show destination address.
- Show quote expiry.
- Show fee and spread fields.
- Show pending until terminal status.
- Provide support with quote/trade/request ids.
Before and after
| Before 0Pools | With 0Pools |
|---|---|
| Partner manually sources stablecoin and calculates spread. | Partner receives quote fields. |
| Address can be handled late in the flow. | Address is locked with the quote. |
| Network support is hard-coded. | Network support comes from capabilities. |
| Ledger joins are manual. | Quote/trade/balance ids join the flow. |
Network and destination model
The destination should be fixed at quote time. That reduces the chance of a user accepting terms for one route while delivery is attempted to a different address or network later.
Use cases
| Use case | Product shape | 0Pools role |
|---|---|---|
| Wallet funding | User buys stablecoin into a wallet. | Quote, destination-bound execution, status, and reconciliation. |
| Neobank stablecoin balance | User converts fiat balance to a stablecoin balance. | Liquidity record behind the neobank ledger update. |
| Marketplace treasury payout | Approved business converts fiat settlement into stablecoin. | Headless quote/trade record for a server-side workflow. |
| Cross-border liquidity | Partner uses stablecoin as a bridge asset in an approved corridor. | Common conversion primitive without exposing route internals. |
Quote-lock and slippage framing
Stablecoin conversion still interacts with live markets. 0Pools should not be described as eliminating all slippage in every circumstance. The accurate claim is that a firm quote gives the partner a short acceptance window with explicit expiry. During that window, the partner can show a concrete rate and terms. If the user waits too long, the quote expires and a fresh quote is required.
{
"pool_id": "EUR-USDT",
"side": "on_ramp",
"quote_id": "pool_quote_123",
"expires_at": "2026-06-28T12:00:15Z",
"dest_network": "tron",
"dest_address_locked": true,
"user_action": "accept_before_expiry"
}Failure handling
| Failure | Product response |
|---|---|
| Unsupported network | Hide the network or block quote creation before user confirmation. |
| Invalid address | Ask the user to correct the destination before quote lock. |
| Quote expired | Refresh the quote; do not execute the old id. |
| Trade failed | Keep the partner order in a support-ready failed state and preserve ids. |
| Returned | Do not auto-credit; follow approved return/review policy. |
Network and address handling
Stablecoin conversion is only safe when asset, network, and destination are treated as separate fields.
| Field | Example | Failure to prevent |
|---|---|---|
| Asset | USDT | Sending the wrong asset. |
| Network | polygon | Sending on the wrong chain. |
| Destination address | 0x... | Invalid address format. |
| Destination tag/memo | Optional by network. | Lost funds where required. |
| Quote id | pq_live_01J4 | Executing unaccepted terms. |
Conversion request record
{
"conversion_id": "conv_7841",
"pool_id": "EUR-USDT",
"target_asset": "USDT",
"target_network": "polygon",
"destination_ref": "dest_43",
"quote_id": "pq_live_01J4",
"status": "reserved"
}Failure handling rules
| Failure | User-safe response |
|---|---|
| Invalid destination. | Ask user to correct address/network before quote execution. |
| Network unavailable. | Disable that network and offer available alternatives. |
| Trade reserved but not settled. | Keep processing until terminal status. |
| Delivery returned. | Show returned state and reconcile ledger. |
Implementation depth
This page is about handling stablecoin conversion with network, address, quote, and reconciliation discipline. For developers, the durable boundary is simple: your product should depend on asset, network, destination, rate, quote id, trade id, and terminal state; it should not depend on custody wallet operations and delivery source mechanics. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.
Product scenario
A user buys USDT on a specific network. The destination address and network are validated before the firm quote, locked into the quote, and copied through execution records.
Before and after in practice
| Before 0Pools | With 0Pools |
|---|---|
| The product lets users change address or network after accepting a price, causing delivery ambiguity. | The quote is the contract for amount, asset, network, and destination, and execution cannot redirect it. |
| 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 |
|---|---|---|
crypto_currency | Stablecoin being delivered. | USDT |
crypto_network | Network for the quote. | tron |
dest_address | Delivery address. | T... |
delivery_status | Partner-visible delivery result. | settled |
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": "stablecoin-conversion",
"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 |
|---|---|
| Address edited after quote | Invalidate and re-quote. |
| Wrong network label | Use capability network ids consistently. |
| Unsupported asset | Hide unless entitled. |
| No destination audit | Store address hash/reference with quote id. |
Use-case patterns
| Pattern | How 0Pools helps |
|---|---|
| Wallet top-up | Deliver stablecoin to user wallet. |
| Treasury conversion | Move fiat balance into stablecoin. |
| Marketplace payout prep | Prepare stablecoin inventory for sellers. |
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.