0Pools Scan
0Bit protocol activity explorer for swaps, pool activity, mint and burn events, 0Asset activity, transaction status, settlement flows, protocol analytics, and indexed activity.
0Pools Scan is the explorer surface for 0Bit protocol activity. It is designed for developers, operations teams, support teams, and users who need to inspect transactions, swaps, pool activity, mint and burn events, asset activity, status transitions, analytics, and indexed records. It should be described as a 0Bit protocol activity explorer, not as a generic blockchain explorer or as a public smart-contract reference.
The source package identifies internal settlement and indexing material that is not a public partner contract interface. Public 0Pools Scan docs should therefore focus on the normalized activity view: what users can search, which product surfaces feed activity, which statuses can appear, and how explorer data supports reconciliation, support, analytics, and audit trails.
0Pools Scan is public but gated. The explorer surfaces are kill-switched and default off, enabled by 0Bit per surface, so availability can vary while the product approaches general availability. The pool table in particular returns placeholder data (isPlaceholder) before general availability. Treat Scan as a visibility surface that 0Bit turns on, not a guaranteed-on or self-serve API.
What this page covers
- The role of 0Pools Scan in the docs and product architecture.
- Transaction, swap, pool, asset, mint/burn, status, analytics, and indexer views.
- How 0Gate, 0Pools, 0Base, 0Link, and assets can produce explorer-visible activity.
- Status and event tables for operational interpretation.
- What 0Pools Scan is not responsible for.
Scan views
| View | What it shows | Operational use |
|---|---|---|
| Transactions | Protocol transaction records, references, status, related product activity. | Support lookup, user status pages, audit trails. |
| Swaps | Swap-like activity such as 0EUR -> USDT, 0BRL -> USDT, or USDT -> 0NGN where configured. | Route and status visibility for liquidity workflows. |
| Pool transactions | Pool-level quote, transact, and settle activity records, with trade status and fees where available. | Trade lifecycle visibility and partner reconciliation. |
| Mint and burn | Supply-impacting configured 0Asset events, such as 0COP mint or 0MXN burn examples. | Asset lifecycle visibility and operational review. |
| Assets | Activity grouped by configured asset such as 0EUR, 0BRL, 0NGN, 0COP, 0MXN, and USDT examples. | Asset-level support, volume, and reconciliation context. |
| Transaction status | Quoted, reserved, settled, released, failed, or returned status concepts. | UI state, support scripts, incident review. |
| Analytics | Aggregated activity, volume, liquidity, status, and protocol usage views. | Monitoring trends without replacing reconciliation reports. |
| Indexer | The indexing pipeline and data freshness model. | Engineering and operations debugging. |
Status interpretation
A 0Pools trade moves through the quote, transact, and settle lifecycle. The status reflects where a record sits in that lifecycle. See Transaction status for the full reference.
| Status | Meaning | Typical next step |
|---|---|---|
quoted | A firm quote is locked and awaiting execution. | Execute against the quote before it expires, or let it lapse. |
reserved | The quote was executed and the trade is in progress. | Poll the trade to advance settlement and 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 event detail. |
returned | A settled trade was reversed downstream and auto-refunded to the partner balance. | Surfaced via the status poll only; re-check the trade and reconcile the refund. |
What feeds 0Pools Scan
0Pools Scan can receive or display activity from several surfaces:
- 0Gate sessions, transactions, payment links, and settlement-aware events.
- 0Pools quotes, trades, settlement status, and fees.
- 0Base transaction, ledger, report, refund, and payment-object records where reviewed.
- Configured 0Asset mint, burn, redemption, transfer, and reconciliation events where available.
- 0Link context when a connected app produces a product event.
The explorer should make relationships visible without becoming the source of authority for the underlying product action. For example, a scan detail page can help support inspect a 0Pools trade as it moves through the quote, transact, and settle lifecycle, but your order system should still rely on verified events and product-specific server reads for durable state.
Not a generic chain explorer
The source package includes internal onchain, settlement, and indexing prototypes, but those are not public partner smart-contract references. 0Pools Scan should be framed as a 0Bit protocol activity explorer.
This matters because a generic chain explorer usually centers raw chain accounts, contracts, and transactions. 0Pools Scan centers product-level activity: payment sessions, swaps, pool activity, configured assets, mint/burn events, settlement-aware status, and operational context.
Search and detail pages
A useful explorer needs both list views and detail views. List views help users find activity by time, status, product area, asset, or reference. Detail views explain what happened and how the record relates to other records.
| Search dimension | Example | Why it helps |
|---|---|---|
| Product area | 0Gate, 0Pools, 0Base, 0Link | Helps support route the issue to the right team and docs page. |
| Asset | 0EUR, 0BRL, 0NGN, 0COP, 0MXN, USDT | Helps operators inspect asset-specific activity without implying all assets are live everywhere. |
| Status | quoted, reserved, settled, released, failed, returned | Helps UI and support explain what should happen next. |
| Reference | partner order id, transaction id, quote id, session id | Helps join 0Bit activity to partner records. |
| Event type | swap, pool transaction, mint, burn, payment, settlement | Helps filter the activity stream to the workflow being investigated. |
Detail pages should expose relationship context: the originating product, related ids, asset pair, amount fields, timestamps, status changes, event history, and links to related records. They should not expose secret values, provider payloads, private routing decisions, bank details, or raw internal settlement-service state.
Data freshness and reconciliation
Indexer data can lag the originating product event. The UI should make activity searchable and understandable, but production systems should still reconcile through:
| Source | Use |
|---|---|
| Signed webhooks | Durable product event intake. |
| Server-side API reads | Trusted current object status. |
| 0Pools Scan | Human-readable and searchable visibility. |
| Settlement reports | Accounting and operational reconciliation. |
| Audit trails | Investigation and incident review. |