Explorer Product Guide

Use the Talero Explorer to browse chain activity, inspect public network signals, and verify artifacts locally

Talero Explorer is the public web surface for indexed Talero chain data. It brings together block and transaction browsing, address and contract inspection, validator and node visibility, network health summaries, checkpoints, and browser-side verification tools. The published experience is intentionally public-safe: sensitive infrastructure details, private operator controls, and secret-bearing configuration are not shown here.

Web explorer Public-safe Indexer-backed Monitoring Offline verify

Live entry point

https://explorer.talero.info
The explorer is the main public UI for browsing Talero blocks, transactions, addresses, tokens, contracts, and network context.

How to read the explorer

Use the global search bar and section navigation to move from high-level summaries into detail pages, then switch to checkpoint and verification pages when you need stronger confidence or bundle validation.

Scope rule: this guide documents the public explorer surface only. Private admin APIs, hidden node endpoints, raw infrastructure topology, signer material, and other sensitive operator details are deliberately left out.

Start here

Most explorer sessions follow the same flow: open the overview page, search for a known hash or address if you already have one, jump into a detail page for exact context, then use the monitoring or verification pages when you need more confidence than a basic list view can provide.

Step	What happens in the explorer	Best use
Open the overview	The home surface shows a network snapshot, recent previews, and shortcuts into the main explorer sections.	Use it as the fastest orientation point when you first land on the site.
Search directly	The global search can resolve common indexed entities such as block heights, transaction hashes, and addresses.	Use it when you already know the object you need to inspect.
Open a detail page	Block, transaction, address, token, and contract pages expose the exact fields available for that indexed entity.	Use detail pages for canonical context instead of relying only on overview previews.
Check integrity pages	Network Health, Forks/Reorgs, Checkpoints, and the verification pages add higher-confidence chain and artifact signals.	Use them when you need more than a simple list or transaction detail lookup.

Fastest path: if you have a tx hash, block number, or address already, start with search and move directly into the matching detail page.

Interpretation rule: the overview is a launch surface. For exact values and surrounding context, prefer the dedicated list pages, detail pages, checkpoint view, and offline verification surfaces.

Main sections

The explorer is organized around chain entities and public operational signals. The top navigation keeps the most common views one click away so users can move quickly from browsing into inspection.

Section family	Main pages	When to use it
Overview	Home, quick links, shell widgets, and recent previews.	Start here when you want a quick orientation before drilling into a specific entity.
Chain activity	Blocks, Transactions, Search, Block detail, Transaction detail, and Address detail.	Use these pages to inspect concrete chain events and relationships between actors.
Assets and contracts	Tokens, Token detail, Contracts, and Contract detail.	Use these views when you need contract metadata, token standards, creation context, or activity counts.
Network status	Validators, Nodes, Metrics, Forks/Reorgs, and Network Health.	Use these pages for public operational visibility rather than for private incident-response work.
Integrity tools	Checkpoints, Verify, Verify PoR, and Verify Finality Receipt.	Use these surfaces when you need higher-confidence chain context or local verification of bundles and receipts.

If you are integrating programmatically rather than browsing manually, use the dedicated RPC and HTTP guides instead of treating UI routes as a stable backend contract.

Search and detail pages

The lookup flow is designed to start broad and become exact. Users can begin with the global search bar or the dedicated search page, then open a block, transaction, or address detail page to inspect the indexed fields for that entity.

Surface	What it exposes	Typical use
Global search bar	Quick entry into indexed entities without leaving the current shell.	Paste a known block height, transaction hash, or address and jump directly to the relevant page.
Advanced search	Aggregated search results grouped by transactions, blocks, and addresses.	Use it when a query can match more than one indexed object type.
Block detail	Height, hash, parent linkage, transaction list, miner/validator field, gas usage, and reward context.	Inspect the exact contents and position of a specific block.
Transaction detail	Status, block inclusion, age, method, value, and linked source or destination addresses.	Confirm whether a transfer is included, pending, failed, or tied to a specific block.
Address detail	Role summary, notes, labels, transaction history, and balance presentation according to the active privacy policy.	Inspect activity around a wallet, contract, or validator-linked address without exposing private wallet controls.

The address page is intentionally descriptive, not administrative. It is for public inspection of indexed activity, not for modifying wallet state.

Tokens and contracts

Asset and contract pages separate token-oriented browsing from generic contract inspection. These views are useful when you want to understand what contract was indexed, which standard it appears to follow, and how much chain activity has been associated with it.

Surface	What it shows	Best use
Tokens	Indexed token contracts with standard, symbol, name, activity count, and last seen block.	Scan the token surface observed by the explorer and move into token detail pages.
Token detail	Focused metadata for one indexed token contract.	Confirm identity and recent visibility of a single token.
Contracts	Indexed contracts with kind, standard, creator, creation transaction, and observed activity.	Use it for a broader contract inventory view that is not limited to token standards.
Contract detail	Address, creator, creation tx, kind, standard, last seen block, and a link back into the address view.	Inspect one contract deeply enough to correlate it with deployment and activity context.

Asset pages depend on what the indexer has already observed. A missing token or contract page does not necessarily mean the chain object is invalid; it can also mean it has not been indexed yet.

Validators, nodes, and metrics

The explorer includes public operational views for validators, nodes, and chain metrics. These pages are meant for visibility, not for private node administration.

Page	What you see	Best use
Validators	Validator list, staking overview, uptime, commission, status, and wallet balance context when available.	Review public validator posture and compare active versus inactive or jailed entries.
Nodes	Node status, height, last seen information, and bootnode rows with masking applied to sensitive addresses.	Observe public node availability without disclosing hidden infrastructure details.
Network Metrics	High-level chain counters such as block height, average block time, transaction volume, mempool size, and online nodes.	Get a compact operational readout from indexer-fed metrics.
Forks/Reorg Insurance	Public chain stability summary based on finality lag and confidence inputs.	Check whether chain conditions look normal or whether extra caution is warranted.

Masking rule: the nodes page sanitizes configured sensitive endpoints and does not publish raw private infrastructure details.

Operational rule: use these pages for public visibility. Use private operator tooling for deeper diagnostics and response work.

Privacy and masking

The public explorer is designed to reduce exposure of address-sensitive and infrastructure-sensitive data. Some fields are intentionally masked, omitted, or aggregated even when a private internal deployment may have access to richer information.

Surface	Public behavior	Why it matters
Address balances	Balance-oriented fields can appear as masked in public mode instead of showing exact amounts.	Prevents the public explorer from becoming an unrestricted balance lookup surface.
Search results	Address-related search rows follow the same masking policy as address detail pages.	Keeps privacy behavior consistent across lookup paths.
Nodes and bootnodes	Sensitive endpoint strings can be replaced with a masked placeholder instead of publishing raw IP addresses.	Public status visibility should not reveal private routing or infrastructure coordinates.
Network telemetry	Pages such as Network Health publish aggregated or anonymized signals rather than raw peer-level details.	Operators and users still get a usable health summary without disclosing sensitive peer information.

Do not interpret a masked field as a chain error. In public mode it usually means the explorer is working as intended and applying a safer disclosure policy.

Network health and checkpoints

Talero Explorer exposes a set of public-safe confidence surfaces so users can reason about chain health, checkpoint publication, and finality context without needing privileged node access.

Surface	What it covers	How to use it
Network Health	Aggregated and anonymized telemetry such as RTT buckets, peer quality, bans, and regions.	Use it for a broad public health snapshot rather than for peer-by-peer diagnostics.
Forks/Reorg Insurance	Risk-oriented summary based on live finality lag and confidence inputs.	Use it to judge whether chain conditions look routine or need a more cautious interpretation.
Checkpoints	Latest checkpoint, checkpoint history when available, and the latest finality estimate.	Use it when you need stronger context around finalized progress and signed checkpoint publication.
Shell widgets	Compact confidence and checkpoint summaries shown in the main explorer layout.	Use them as a quick read before deciding whether to inspect the full checkpoint or reorg pages.

These surfaces are intentionally public-safe summaries. They help users build confidence without exposing the trusted-only node controls used by operators behind the scenes.

Offline verification

The explorer includes browser-side verification pages for users who already possess JSON bundles or proofs and want to validate them locally. These pages are designed to work without live RPC calls during verification.

Page	What it verifies	Notes
Verify (offline)	Finality receipt JSON and standalone finality proof JSON using the local SDK.	Useful when you want a quick local validation flow without relying on a live endpoint.
Verify PoR	Proof-of-reserve style attestation bundles with signature and proof checks.	Designed for uploaded or pasted JSON and local-only processing.
Verify Finality Receipt	Receipt bundle signatures, finality proofs, and receipt-oriented proof checks.	Use it when a transaction confirmation flow includes a bundle that should be validated independently.
Checkpoint verifier	Signed checkpoint JSON and related checkpoint consistency checks.	Lives inside the Checkpoints page and follows the same browser-side verification model.

Verification pages validate the material you provide to them. They do not replace good provenance checks for the bundle or receipt source itself.

Data freshness and empty states

Explorer pages do not all behave the same way. Some lists refresh periodically, some pages depend entirely on current indexer coverage, and overview surfaces can be more approximate than the canonical detail pages.

Behavior	What it means	What to do
Periodic refresh	Several list pages update automatically so new indexed data appears without a full reload.	If you are watching the tip of the chain, stay on the list page a little longer before assuming nothing has changed.
Empty tables	An empty state can mean no indexed results for that view, delayed ingestion, or temporary backend unavailability.	Cross-check with search, block height, or a nearby page before drawing a final conclusion.
Warning badges	Tags such as masked, partial, pending, or unavailable are deliberate honesty markers.	Treat them as product guidance about data quality or disclosure level, not as mere decoration.
Overview previews	The landing page is optimized for orientation and may rely on summary or best-effort preview data depending on deployment stage.	For exact values, prefer the dedicated list pages, detail pages, metrics page, and checkpoint surfaces.

The clearest reading order is usually: overview for orientation, list page for position in the dataset, detail page for exact context, then checkpoints or verification for stronger assurance.

Best practices

The explorer is most useful when you treat each page according to its purpose: browsing for orientation, detail pages for specifics, and verification pages for confidence-sensitive workflows.

Use search when you already know the hash, height, or address; use list pages when you want broader context and ordering.
Prefer block, transaction, address, token, and contract detail pages over summary widgets whenever you need exact values.
Do not treat masked or omitted fields as proof that the underlying chain data is missing; public mode can hide them intentionally.
Use Network Health, Forks/Reorgs, and Checkpoints together when you need to judge chain confidence in addition to basic inclusion data.
Use the offline verification pages for bundle validation, but still confirm that the bundle itself came from a trustworthy source.
For integration work, consult the RPC and Node HTTP guides rather than depending on the explorer UI as an API contract.

Good inspection pattern: search or navigate to the entity, read the detail page, then use checkpoints or verification only if the workflow requires stronger assurance.

Good operational pattern: if the explorer shows an availability warning, confirm against the relevant node or RPC guide instead of guessing based on one UI surface.

FAQ

Question	Answer
What can I search for?	The explorer is designed around indexed entities such as blocks, transactions, and addresses. Search works best when you already have a specific identifier.
Why is an address balance shown as masked?	The public explorer can hide balance-sensitive fields on purpose. That behavior reflects the active privacy policy, not necessarily missing chain data.
Why are some node addresses hidden?	The nodes page masks sensitive endpoints so the public status surface does not reveal private or operator-only infrastructure details.
What is the difference between Network Health and Checkpoints?	Network Health summarizes public operational signals, while Checkpoints focuses on signed checkpoint publication and finality-oriented context.
Can I verify artifacts without a live RPC connection?	Yes. The verification pages are built for local JSON-based validation and are documented as offline flows.
Should I treat the explorer as an API?	No. For backend integrations, rely on the documented RPC and HTTP surfaces instead of assuming the UI’s internal routes or behaviors are a stable contract.