Transaction status
Understand quoted, reserved, settled, released, failed, and returned protocol transactions.
Understand quoted, reserved, settled, released, failed, and returned protocol transactions.
0Pools Scan is an explorer-style view over indexed 0bit protocol activity: transactions, swaps, pool movements, asset activity, mint and burn events, status transitions, and analytics. It is not a legal attestation, proof-of-reserves product, or source of private provider data.
What this page covers
- Status taxonomy
- Failure and retry interpretation
- Product record joins
How it fits
0Pools Scan is an explorer-style view over indexed 0bit protocol activity: transactions, swaps, pool movements, asset activity, mint and burn events, status transitions, and analytics. It is not a legal attestation, proof-of-reserves product, or source of private provider data.
Status interpretation
A 0Pools trade moves through the quote, transact, and settle lifecycle. The status field reflects where a record sits in that lifecycle, not an undocumented worker state.
| Status | Meaning | Typical next step |
|---|---|---|
quoted | A firm quote is locked and awaiting execution. | Execute against the quoteId before it expires, or let the quote lapse. |
reserved | The quote was executed and the trade is in progress. | Poll the trade by quoteId to advance settlement; avoid duplicate writes. |
settled | The trade reached a successful terminal state and delivery or payout completed. | Reconcile against your records and the signed settlement event. |
released | The reservation was released as a terminal outcome without completing the trade. | Review the trade detail and event history; re-quote if you still intend to execute. |
failed | The trade did not complete. | Preserve ids and request ids, show recoverable UX, and review the trade detail. |
returned | A settled trade was reversed downstream (for example a returned bank payout or a failed crypto delivery), with the balance auto-refunded. | Surfaced via the status poll only — re-check the trade and reconcile the refund. There is no event for this transition. |
Workflow
- Observe product activity from payment, pool, asset, link, and protocol sources.
- Normalize activity into searchable records with ids, timestamps, assets, amounts, status, and related links.
- Expose filters and detail pages that answer what happened and which product object owns it.
- Join scan records to operations reports when reconciliation needs settlement-aware review.
- Preserve source ids so support can trace from explorer view back to product call.
Status and data signals
| Signal | Use it for | Do not use it for |
|---|---|---|
| Transaction or activity id | Search key for protocol activity. | Private provider reference. |
| Asset and amount | Visible movement or quantity. | Reserve balance claim. |
| Status | Quoted, reserved, settled, released, failed, returned, or product-specific state. | Undocumented worker state. |
| Related records | Links to product, asset, pool, or report pages. | Cross-partner records. |
Implementation notes
- Start in sandbox or test mode with fake data.
- Keep server-only credentials, webhook secrets, PII, provider payloads, and internal runbooks out of public docs and browser code.
- Use documented ids, request ids, event ids, timestamps, status fields, asset symbols, and environment names for support and reconciliation.
- Treat browser callbacks as user-experience signals; use signed webhooks, API reads, scan records, or settlement reports for durable backend state.
- Confirm product access, entitlement, regional availability, and review status before presenting the workflow as live.
Example trace
A typical 0Pools Scan trace starts with a product object id or activity id. The record page should show the product owner, asset, amount, timestamp, status, and related records. A support user can move from transaction to swap, pool activity, mint/burn event, asset page, or settlement record depending on the workflow. Scan visibility is evidence for navigation and support, but final operational decisions still depend on signed events, API reads, and reconciliation outputs.