Network explorer

The validator count is read live above — and so is the largest share beside it, which is the cell that actually answers the question. A count is not a decentralisation, and this one in particular is not. Two validators are bonded, both the project's, and neither reaches two thirds — so the anti-grinding seed is armed and the draw reads live VRF contributions. Stopping either validator stops block production for everyone: fault tolerance is zero, for the opposite reason to before. It resumes when the missing node returns, and the target is a third validator — exactly as it was at a count of one. Every validator here is the project's own: a count can rise while the trust behind it does not, and nothing in the sentence before it depends on that count. No wording on this site claims otherwise. Total supply started at 10,000,000 DNDR and can only fall: the standard mint module is absent from the binary so nothing can be issued, while the fee burn retires a little at every settled job — which is why the figure above reads slightly under ten million. The genesis hash shown is the one the joiner script checks before it lets a node sync.

These five counters are a partition of the same audits, and reading any one alone misleads. audits opened (drawn) is the chain's own counter, incremented at opening time whichever way the audit arrived; it is the total the four classes below must add up to. committee anchored counts the audits that got as far as seating jurors — being drawn is not being seated, and being seated is still not being checked. An audit verifies something only when a quorum of jurors actually votes: conducted (quorum) counts those, and it is the only figure that proves verification. expired (no quorum) counts audits that timed out for lack of voters, so a network too small to audit itself shows up here on purpose. deferred (no jury) counts jobs the lottery did select but whose opening was deferred — because the seed was unavailable or the pool of eligible jurors was below the floor (AuditDeferred, ADR-034). It is emphatically not "jobs that never reached the draw": those leave no trace at all, which is exactly why this query has to exist. vindicated = confirmed honest · clawed back = payment reclaimed. A slash against an honest miner would be a protocol failure, not a success metric, and it is shown here for that reason.

This is the panel that explains the zeros above. The protocol pays for work from block 1, but with hold_bps at 10000 the miner's entire net share goes into retention at settlement instead of into its account, and is released at audit finality. Held is not cancelled and does not expire: each retained amount is dated on-chain and queryable with dendrad query jobs held-summary. It drains by two different routes, and only one of them needs an audit. A job the lottery does not select finalises at its checkpoint and releases straight away — which is why this total has already fallen on this network while conducted (quorum) sat at zero. A job the lottery does select stays held until a committee returns a verdict. Attributing the whole backlog to "once audits can resolve", as this note used to, made a drop look like a verification that had not happened. Bond escrowed is the collateral posted by challengers; jurors locked counts stake immobilised by an audit in flight.

The committee seed is built from VRF contributions so that no single party chooses who audits whom. The check on that seed runs before the per-job lottery, and it is checked per block. A validator contributes to the block it reaches in time, not to the chain in general, so with one contributor on a home link the count is met on a minority of blocks and missed on the rest. Read the first rows as a sample, never as a state — reload and they change.

Two heights, and they are not the same one. seed block is where the reading comes from: the chain looks for a seed at the current height and falls back to the one before, so the contributor count belongs to that block, not to measured at height, which is only when the query ran. And a seed can exist below the floor — the chain writes one whatever the count was, and it is the count that authorises a draw. That is why committee seed says which side of the floor it is on rather than a bare "present": presence alone is not a working beacon, and this cell used to go green on it.

Two different things can stop an audit, and this panel keeps them apart. On a block below the floor, no job reaches the draw at all. Above it the lottery runs: a job it does not select finalises and releases, a job it does select opens an audit — and that audit still needs a jury, which is every registered miner except the one under audit, with audit_min_quorum of them actually voting. draws ever run and verdicts returned are cumulative counts from the chain, so they answer those questions properly; blocked by names whichever is binding today. This is the protocol failing closed — a payment that cannot be verified is not paid out, and it is not destroyed either. The word "decentralised" on this site qualifies this seed and nothing else.

Read from the chain, not from this file, so the numbers quoted elsewhere on this site can be checked against the network that is actually running. All of these are governable and can change. bps are basis points: 10000 = 100%.

⚠️ This panel counts MINERS, not validators, and the two numbers are meant to differ. A node appears here only if it declares hardware to the capacity endpoint, which is something miners do and validators have no reason to: a validator secures consensus rather than running models, so it has no GPU to declare. live nodes below a larger validators count in the Chain panel is therefore the expected reading, not a contradiction — and it is stated here because without it the two panels look like they disagree. There is no validator inventory on this page; the validator set is a count and a power distribution, read from /rpc/validators.

The figures below are self-reported by operators and are not verifiable: a node can claim any GPU. The registry is public, so anyone could announce a fleet and inflate the totals. The headline figures therefore count only nodes whose declared identity exists in the on-chain miner registry — inflating those requires staking first — and the raw declared total stays visible next to them rather than being passed off as a measurement. identity only says the id exists in that registry; it says nothing about the hardware. Treat this as an inventory, never as proof of the network's power. The proven facts are in the panels above.