What an observer is
An observer is read-only: it doesn't produce blocks, vote, or relay transactions. It has no effect on the chain, and it's fine for it to go offline. It keeps answering one question: has this chain's history been changed?
| Validator | Observer | |
|---|---|---|
| Role | Votes in QBFT and produces blocks | Syncs every block, checks and publishes the data |
| Effect on the chain | Too many offline and the chain stops | None on block production |
| Trust needed | You must trust the operator | None |
| How to join | On-chain vote by existing validators | Download the kit |
| Network | Fixed public IP, online 24/7 | Outbound connections only; catches up after reconnecting |
| Recommended | 2–4 cores / 8 GB / 100 GB NVMe | 2 cores / 4 GB / 50 GB SSD |
| Keys | A block-signing key that must be guarded | Only a network identity key; leaking it carries no financial risk |
| Who runs it | Long-term partners | Anyone |
What it detects
The watch dashboard records every block the node has and runs these checks continuously. Critical incidents turn the dashboard red, and records are append-only.
| Check | How | On failure |
|---|---|---|
| Rewrite detection | Re-reads the latest 1,000 blocks every minute plus a rotating sweep over all history; if a hash changes, both headers are kept | Critical rewritten |
| Continuity | Block N's parent hash must equal the recorded hash of block N−1 | Critical chain_break |
| Reference comparison | Compares every block with each reference RPC at the same height, and notices if a reference changes its answer later | Critical mismatch |
| Health | Node unreachable, head not advancing, too far behind, no peers, reference unreachable. A stall says whether it's this observer's own sync or the chain itself that stopped | Warning resolves itself |
All three critical checks and the main warnings have been triggered in drills. You can export the block hash list for any range and compare it with other observers offline: diff <(sort mine.csv) <(sort theirs.csv).
Live dashboard
An observer set up the same way on a separate server, with its dashboard public and read-only:
WarmUp Observer
Green "All consistent", yellow for warnings, red "Anomalies detected". Browse the block ledger and incidents, and export evidence.
http://192.227.167.144:18080Run an observer
What you need
- 2 CPU cores, 4 GB RAM; an SSD with 50 GB+ for
fullmode or 20 GB+ forrecent - Outbound connections only; no public IP
- Docker 24+ with
docker compose
Two sync modes
| full (default) | recent | |
|---|---|---|
| Starts at | Genesis | A checkpoint you choose |
| First sync | Slower, grows with the chain; re-executes every block locally | Fast; still downloads every block header |
| Verification | Strongest | Strongest after the checkpoint; before it, hash-chain continuity only |
In recent mode, take the checkpoint from a source you trust: another independent observer, or your own earlier full sync.
Start
cp .env.example .env
# set BOOTNODES, choose SYNC_MODE=full or recent
mkdir -p data watch-data control
docker compose up -d
# open http://127.0.0.1:8080 for the watch dashboardThe node's JSON-RPC listens on localhost only and exposes read-only APIs. Images are pinned by digest; the dashboard runs on a read-only filesystem with zero npm dependencies.
Other ways to verify
Explorer
Every block, transaction, address and contract is public.
Recompute a round
Work out any round's result from on-chain events alone.
Ask the RPC
Read any block from the public RPC and compare it with the explorer and an observer.
Contract registry
Address, version, status and ABI of every platform contract, retired versions included.
What it can't do
- Detect, not prevent: an observer can sound a public alarm about tampering but can't stop the validator producing blocks. Making history impossible for any one party to rewrite needs validators spread across different operators, which is on the roadmap before mainnet.
- An entry node can withhold, not forge: a node relaying blocks to you can't forge them (QBFT seals are re-verified); at most it can stop relaying, which shows as lag behind the references.
- Clock-drift monitoring is in progress: comparing when new blocks arrive with their timestamps, alerting above 5 s of drift.