Testnet — not mainnet
Network status

Network Status

Live telemetry served straight from a gateway node of the network — every figure below is fetched from this node's own chain head and re-verifiable against its state root. No dashboard database, no middle layer. This is a hardened public testnet, not value-bearing mainnet.

initializing…
Chain vitals

The chain, block by block

Read live from the gateway's /v1/head and /_status. Block time is measured from real height/time deltas across polls — no synthetic metrics.

Block height
0000000
latest committed block
Epoch
0000
reward / rotation window
Measured block time
0.0 s
from height deltas · target ~1s
Protocol version
v0
minutiaos-mldsa-v7 (Testnet)
State root — the trustless anchor (any node re-derives it byte-for-byte)
0000000000000000000000000000000000000000000000000000000000000000
Merkle commitment to all balances, stakes, names and deals at this height. Re-derivable from block data by any node.
Poll cadence Measured this session

Each bar is the wall-clock gap between consecutive observed heights — this tab polls roughly every 3s, so one gap usually spans several ~1s blocks. Poll-limited, not per-block; just what this browser tab saw, not an all-time history.

observing… gaps between observed heights · poll ~3s
Epoch progress

Position of the current height within its epoch. Epoch length is derived (height ÷ epoch on this chain, ~600 blocks ≈ 10 min) — the epoch number itself is read live from /v1/head.

Current epoch
Into epoch
Epoch length
Epoch length is a derived approximation for this progress ring, not a consensus-reported field. The epoch number is the real value from the chain head.
Consensus mesh

The vote graph, live

The real validator set from /v1/validators, drawn as the consensus vote-gossip graph. One round animates for each real newly committed block — never faster than blocks actually arrive.

Consensus mesh — the BFT vote graph

Every validator gossips its vote to every other validator — a BFT chain requires all-to-all vote propagation to assemble a quorum certificate (> ⅔ stake). This is the protocol's logical vote graph, NOT a scraped live socket map — we do not claim to know who-connects-to-whom, and no block is attributed to a specific proposer (the head snapshot does not reveal one). The distinct dashed node is this gateway (observer): it follows the chain but does not vote. One round animates per real committed block.

Validator (size ∝ stake) Gateway observer (non-voting) Quorum certificate formed
 · idle
committed height
Honest by construction. The all-to-all edges are the protocol's logical requirement (a > ⅔ stake quorum certificate needs every vote to reach every validator), not a measured network map. Node size is proportional to total stake reported by this node's head; the quorum ring reflects the same > ⅔ stake threshold used elsewhere on this page.
Consensus & validators

Who is producing blocks

Post-quantum BFT consensus. Every validator signs with ML-DSA; the chain stays safe and live while strictly less than one-third of staked voting power is faulty.

Active validator set

Loading the live validator set…

#
Validator
Self / total stake
Status
Comm.
Loading validators…
Byzantine fault tolerance. The chain stays safe and live as long as strictly less than 1/3 of total staked voting power is faulty or adversarial; finality is the classic 2/3+1 quorum. Slashing makes dishonesty the losing move. Validator addresses are ML-DSA public-key identities; stake is as reported by this node's head.
Stake summary

Aggregated from the live validator set.

Active validators
Total stakedNUANCE
Total self-bondedNUANCE
Min self-bondNUANCE
Largest share of stake
Stake distribution

Each validator's share of total_stake, read live. Larger shares carry more voting power toward the > ⅔ finality quorum.

loading…
BFT safety & decentralization

Derived from live stakes. Finalizing needs > ⅔ of voting power; halting or censoring needs only ≥ ⅓ — that ⅓ is the fault-tolerance boundary.

Validators to reach ⅓ stake
Validators to reach > ⅔ stake
Effective operators1
Read this honestly. The numbers above are stake-weighted — how the math would behave if each validator were an independent party. On this testnet all validators are run by a single operator, so effective operator-decentralization is 1 regardless of how stake is split. That is exactly the gap the "real independent operators" launch gate closes; the gauge shows the protocol's tolerance, not decentralization this network has yet.
Validator liveness

Who's signing, right now

Per-validator participation over the last commit certificates this gateway has applied, plus the gateway's own peer connectivity. Read live from /v1/liveness.

Recent signing participation

Share of the last committed blocks whose commit certificate carried each validator's vote.

Loading liveness…
This gateway

First-person view from the node serving this page.

Connected peers
Participation window
Read this honestly. Participation is this node's view of the commit certificates it applied — a certificate only needs a > ⅔-stake quorum, so a healthy validator can be left out of some blocks and read below 100%. Only sustained absence means a validator is actually down (or partitioned from this gateway). Each validator is scored only over blocks it was eligible to sign, so a newly-added validator is never shown as absent for blocks before it joined. "Connected peers" is this one gateway's libp2p count, not a whole-network census.
Storage provider fleet

The nodes hosting content — earning, not voting

The storage providers from /v1/providers: nodes that physically hold committed content and answer a proof-of-storage challenge every epoch to earn. These are distinct from the validators in the consensus mesh above — a provider hosts and proves data but does not vote (a single machine can do both). Read live, node-view.

Providers proving storage

Each row is one on-chain provider: content it holds, its locked bond, and whether it passed its latest proof. Bar width is bytes held relative to the largest provider.

Loading providers…
Fleet at a glance

First-person census from this gateway's committed state.

Providers on-chain
Currently proving
Total content held
Total bonded
Validators vs providers. A machine can be both: a validator secures consensus (drawn in the mesh above), a provider hosts + proves data (listed here) — so a node that does both appears in both places, and a provider-only node appears here but not in the vote graph. Proving means the provider passed its most recent on-chain proof-of-storage challenge; a brand-new commitment reads pending until its first proof lands. Bond is real NUANCE locked as slash-at-risk collateral.
Economics

Supply & on-chain parameters

Live monetary parameters from the chain head. NUANCE has 9 decimals (atomic ÷ 1e9). On this testnet, NUANCE carries no monetary value.

Live parameters

Straight from /v1/head — these change only by consensus.

Total supply0
Fee → validators0%
Reward floor / TB0
Circuit-breaker max draw0%
Genesis allocation Static context · not live

The frozen fair-launch genesis split. Zero premine to founders. Shown for context — it is not read from the endpoints above.

45%  —  ecosystem & participation pool
15%  —  validator / server rewards
40%  —  governed treasury
Fair launch, 0% premine. The genesis split is fixed at chain genesis. The treasury is spendable only by clamped on-chain governance — supply-neutral, capped per proposal.
Governance & upgrades

Proposals & protocol upgrades

Every parameter change is an on-chain proposal, clamped against abuse. A proposal passes with more than half of active voting power (quorum GOV_QUORUM_BP = 5001, i.e. 50.01%).

Active proposals

Read live from /v1/proposals.

Loading proposals…
Pass threshold: > 1/2 of active voting power · GOV_QUORUM_BP = 5001
Scheduled protocol upgrade

Where a future soft-fork "flip" — e.g. verifiable compute (v3) or confidential compute (v4) — would appear once scheduled.

Current protocol version
Pending upgrade
No scheduled protocol upgrade. Higher-version capabilities remain fail-closed until a coordinated activation is scheduled here.
Protocol upgrade ladder Roadmap · future steps not yet active

The soft-fork ladder. The current version is highlighted; each future step lists its honest activation and stays fail-closed until a coordinated flip is scheduled. Mirrors the capability matrix below.

Steps beyond the live version are a roadmap, not live capabilities. Each activates only via a coordinated governance-scheduled soft-fork; until then the network refuses to settle them rather than pretend.
Component & capability matrix

Every capability, by how it's actually secured

Trust tiers at the current protocol version (v1). Nothing here is called "trustless" unless cryptography or economic slashing actually backs it; higher tiers are honestly marked unavailable until their activation version.

Trustless
Chain-verifiable: cryptographic / economic-slashing backed. No trusted party.
Bonded-federation
Economic slashing of a bonded, provider-diverse operator set (BFT-sound: a <1/3 minority can neither frame nor fake). A trust assumption, stated honestly.
TEE-trust
Hardware attestation (SGX / TDX / SEV). Not live until protocol version ≥ 4.
Unavailable
Fail-closed. Activates at a future protocol version — never silently trusted.

At the live protocol version, TEE-trust and higher-version compute tiers are fail-closed — the network refuses to settle them rather than pretend they are trustless.

Cryptography

Post-quantum from the first block

Every vote and transaction is signed with ML-DSA (Dilithium2), the NIST FIPS 204 post-quantum standard — constant-time, deterministic to the byte.

signature schemeML-DSA (Dilithium2)
standardNIST FIPS 204
quantum resistancepost-quantum secure
constant-time signingby design
state transitionbyte-deterministic
classical ECDSAbroken by Shor
Identities & hashing

How accounts and state are addressed.

Address formatmn1… (bech-like)
Address derivationhash of the ML-DSA public key
State commitmentMerkle state root (per block)
Native unitNUANCE · 9 decimals
Verify, don't trust

This gateway — and how to check it yourself

This page is served by a live gateway node of the network. Don't take its word for the numbers above — reproduce them.

This gateway node

Reported by the node's own /_status (self-reported — verify independently).

Served by
Trust label
Chain id
Node reachability
A gateway is a convenience, not an authority. It can only serve content the chain commits to — and you can confirm every value here against your own node.
Verify independently

Three ways to check this page instead of trusting it.

1
Run your own nodeOne static binary joins the live network read-only — no stake needed: minutia-node join --network chain7.toml, then run. It syncs the same blocks. See get started.
2
Cross-check the state rootYour node re-derives the same state root shown above at the same height, byte-for-byte — or the chain has forked.
3
Content-addressed pageThis dashboard is itself served by its on-chain content id — its bytes are what the chain commits to, so they're tamper-evident.
Run a server & verify