Everything the chain can honestly show
Chain
Network activity without an address lookup. Amounts are commitments and recipient addresses are hidden. Transactions are aggregated within a block, but cut-through is not applied: mixing the graph does not erase it.
These figures are reported by the website's node, not independently verified by your browser. Run your own node to check the chain, and read the validation and privacy limits.
Supply invariant
checking…The node checks a balance equation over unspent outputs and transaction kernels. Together with signatures and range proofs, it is a safeguard against invalid issuance. The badge shows the node's reported result; this page does not verify the cryptographic proof itself.
— of the cap has been issued. During subsidy eras, fees are burned rather than paid to the miner, so circulating supply is at most equal to minted supply. After the subsidy ends, fees pay miners without new issuance. See the full emission schedule.
The set the network agrees on
Commitments currently spendable. Not a user count — one wallet holds many.
One per transaction ever made, kept forever. The chain's only transaction counter.
Accumulated difficulty. This, not length, is what decides the winning chain.
Merkle root over the whole set. Two honest nodes at the same height print the same string.
Block time and difficulty
Target is 15 seconds. Difficulty is retargeted every block by an LWMA over a 90-block window, so the line should drift, never jump.
Recent blocks
Inputs, outputs and kernels are counts, not contents. A block with one output and one kernel is an empty block carrying only its coinbase.
| Height | Age | Difficulty | In | Out | Kernels | Reward | Hash |
|---|---|---|---|---|---|---|---|
| Loading… | |||||||
Times are what the miner stamped on the block, checked against the median of the previous eleven. They are not exact clocks.
Skip the first sync
A new node fetches the chain block by block from whichever peers it finds. That works, and on a young network with few peers it is slow. This is the same chain as one file.
Everything after this still arrives from the network, as usual.
Rebuilt weekly. An older copy is not wrong, only further behind.
Not compressed: the file is hashes and proofs, and zstd takes only 8 % off.
Of the unpacked chain file. Check it before you use it.
Stop the wallet first, then check the file and put it in place. Compare the hash against the one above before you move anything.
# Windows (PowerShell)
Get-FileHash nightfall-chain-<height>-<date>.bin -Algorithm SHA256
Move-Item nightfall-chain-*.bin "$env:APPDATA\nightfall\mainnet\n8\blocks.bin" -Force
# macOS
shasum -a 256 nightfall-chain-<height>-<date>.bin
mv nightfall-chain-*.bin ~/Library/Application\ Support/nightfall/mainnet/n8/blocks.bin
# Linux
sha256sum nightfall-chain-<height>-<date>.bin
mv nightfall-chain-*.bin ~/.local/share/nightfall/mainnet/n8/blocks.binReplacing the file on a node that has already synced is safe but pointless: the wallet notices the chain file is not the one it validated and re-checks all of it from the start.
This is not a shortcut around verification. Your node re-derives every block hash and re-checks every proof of work in the file before it accepts a single one — the first start after this will take a while, and that is the check running. The archive replaces the download, not the checking. It deliberately contains the blocks and nothing else: the metadata file that records "this chain was already verified here" is left out, because shipping it would switch that checking off. No archive has been published yet.
What the network is running
Counted from the handshake of every peer this node has met. It is a sample from one vantage point, not a census — but it is the only honest answer to "has everyone upgraded yet".
What you cannot see here, and why
Every explorer for a transparent coin is a surveillance tool that happens to be useful. Ours cannot be one, because the data is not on the chain to publish:
- No balances. There are no reusable addresses. Each payment creates a one-time stealth output that only the receiver can recognise, with their view key.
- No amounts. Values are Pedersen commitments. A range proof shows each one is a sane positive number without revealing it.
- No sender or receiver. Mimblewimble cuts through spent outputs and aggregates what is left into one flat block body. The individual transactions do not survive into the block.
- No transaction search. Deliberately. A kernel lookup would let anyone with a transaction id confirm a payment they were not part of, and hand this server a record of who asked.
Your own history lives in your wallet, where it belongs. If you need to prove a payment to someone else — an auditor, an exchange, a court — use a view key: it discloses exactly what you choose and nothing else.