Ledger Explorer
Every accepted telemetry record is hashed and committed to an append-only, hash-chained block. This page reads the live ledger. Anchor state is shown per block exactly as recorded, with no claim beyond it.
- Committed count
- 8,243
- Batches received
- 8,243
- Difference
- 0
- Signature verified
- yes (ML-DSA-65)
- Received at
- 2026-08-21 23:10:03 UTC
- Chain head
- bd78112f9c0a266997e7d25eeea247d8f83a1fb454f36b5260641e0f56926c2e
- Committed count
- 8,470
- Batches received
- 8,470
- Difference
- 0
- Signature verified
- yes (ML-DSA-65)
- Received at
- 2026-08-21 23:10:03 UTC
- Chain head
- 41aa4b32db287847adbd1c51f8d43e5fcb2e3f6dc9c8e7e03a1ed83784a980f2
Last reconciliation applied 2026-08-22 04:25:00 UTC. Reconciliation runs daily and compares each node’s own signed submission count against the number of distinct telemetry batches this service received from it, deduplicated on the batch payload digest. Known non-ingest chain entries, such as a node self-test, and submissions predating batch-level accounting are carried as a fixed per-node offset.
What this shows, and what it does not
A block commits a fixed set of telemetry records through a SHA-256 Merkle root, so any later edit to a committed record changes the root and breaks the block hash. Each block also carries the previous block hash, so removing or reordering a record invalidates every block after it. A confirmed Bitcoin anchor adds evidence the operator would have to break a third party to forge: that the block hash existed at a given time, checkable against the public timechain rather than against us. Anchors that are still pending show nothing yet, and are labelled as pending.
This is tamper-evidence over what was published. It says nothing about whether the data submitted before sealing was accurate, whether a node was compromised, whether something was never submitted, or how events and methodology are decided. Verify a record yourself.