Criteria Catalog

DNO's published observation-criteria definitions · Criteria Framework v1.0 · effective 2026-07-06 · definitions only, descriptive not prescriptive · machine-readable companion: /criteria.json

How to read a criterion

Every criterion answers four questions, in order: measures what (the observable quantity), from what vantage (where DNO stands when it looks), with what limitation (what bounds or invalidates the observation), and what it does not mean (the interpretations the criterion cannot support). A criterion is a definition, not a result. This page contains no results.

Vantage and epistemic rules

These rules govern every criterion and are why the definitions hold even before any observation is published.

Vantage — what DNO can and cannot see

A Demos node speaks three layers: an internal binary peer-to-peer transport (OmniProtocol), a JSON-RPC layer, and messaging channels. DNO observes only the JSON-RPC and peerlist layer. It does not see consensus rounds or block-sync traffic directly. Everything DNO reports is the node's reported state over RPC, not a direct view of consensus.

The do-not-collapse rule

When DNO cannot check something, the result is insufficient — never a pole. A criterion never silently resolves a missing, partial, or unverifiable observation into “met” or “not met.” unknown, insufficient, and unavailable are first-class outputs. This is the rule that most distinguishes an observer from a scorer: a scorer guesses; an observer declines.

Non-circularity

Any criterion that compares a node against a reference (sync distance, consistency) compares against an external reference head, never against DNO's own observed set. Judging nodes by how well they match DNO's prior view is a feedback loop that destroys an observer's independence; it is structurally excluded.

Identity continuity is a prerequisite

A participant that changes identity does not shed prior observation history and start a clean window. Rapid or repeated identity change extends the insufficient period rather than permitting a fresh favorable result.

On-chain fact vs. observed reachability

A value recorded on-chain (for example, a validator's registered state) and a reachability observation made from DNO's vantage are categorically distinct, and are never merged into one statement, column, or field. DNO reports each as what it is.

The criteria (v1.0)

The threshold values below are DNO's own published parameters for its observation window — not values Demos requires of anyone. They are versioned (see Changelog) and auditable as data in /criteria.json. The observation window used throughout is 120 hours; this is the criteria framework's own window and is distinct from any live rolling metric shown elsewhere on the site (for example, a 7-day uptime figure on /methodology).

C1 · Sync distance

Measures: the difference between an observed peer's reported chain tip and the external reference head, sampled per observation cycle. Vantage: the peer's tip via its RPC (getLastBlockNumber / node info), compared to the external reference head.

Threshold (v1.0): within 3 blocks.  Window: 120 hours.  Possible states: within threshold · outside threshold · insufficient · reference anchor unavailable.

Limitation: point-in-time per cycle; RPC responses may be cached (network parameters carry a ~30-second server-side TTL). If the reference anchor is unavailable the state is insufficient — DNO never falls back to comparing against its own set. Does not mean: correctness, quality, or standing. A lagging tip is a lag observation and nothing more.

C2 · Uptime

Measures: the fraction of observation cycles in the window in which the node was observed reachable. Vantage — three distinct facts, never conflated: (1) direct reachability — DNO fetches the node itself; (2) reference-peerlist presence — the node appears in the external reference's peerlist; (3) relayed liveness — a liveness flag the network itself reports. A published uptime definition names which of the three it counts and labels the others as separate.

Threshold (v1.0): at least 97% of cycles.  Window: 120 hours.  Possible states: within threshold · outside threshold · insufficient.

Limitation: absence from a roster is not downtime — a node DNO has not observed enough is insufficient, never counted as failing. Does not mean: service quality, or reachability for any other client on any other network path.

C3 · Response rate

Measures: the fraction of DNO probe requests in the window that received a well-formed response, from DNO's vantage only.

Threshold (v1.0): at least 95%.  Window: 120 hours.  Possible states: within threshold · outside threshold · insufficient.

Limitation: the probe does not capture latency; response rate is not response speed. Does not mean: throughput, latency, or quality of service to any other consumer.

C4 · Stability

Measures: the count of observation-reset events in the window (a reset truncates the continuity of the window).

Threshold (v1.0): at most 2 resets.  Window: 120 hours.  Possible states: within threshold · outside threshold · insufficient.

Limitation: governed by the identity-continuity rule — identity change never sheds history; churn extends insufficient. Does not mean: misbehavior. A reset is an observation-continuity fact, not a judgment about the node.

C5 · Minimum observation age

Measures: whether a full, unbroken observation window exists for the participant.

Threshold (v1.0): at least 120 hours of continuous observation.  Possible states: sufficient · insufficient.

Limitation: any gap yields insufficient; boundaries are strict (119.9 hours is not 120); a single monotonic time source is recorded with each observation. Does not mean: that a node observed for less time is deficient — only that DNO has insufficient history to say anything.

C6 · Consistency

Measures: agreement between an observed peer's state and the external reference head, reported as a fact with magnitude — never collapsed into a good/bad pole. Vantage: the network's own GCR Status hash; a divergent status hash between an observed peer and the reference at the same height is the consistency signal.

Threshold (v1.0): descriptive — no numeric threshold. Divergence is reported as a fact with magnitude, not scored.  Possible states: consistent · divergent (with magnitude) · insufficient · reference anchor unavailable.

Limitation: meaningful only when the observed peer and the reference share the same genesis fork schedule; divergence clustered around a fork-activation height may reflect binary/version skew rather than fault, and is described as such, not judged. Does not mean: agreement with DNO, honesty, or safety.

State vocabulary (defined here; applied to no participant on this page)

DNO's observation outputs, when published on a separate surface, draw only from this fixed vocabulary:

meets_published_criteria = true | false — a binary result against the disclosed thresholds above, accompanied by the criterion-level facts. It is never a score, grade, ranking, trust level, or validator-quality metric.

insufficient observation history — not enough continuous observation to evaluate.  reference anchor unavailable — the external reference needed for C1/C6 was not available.  criterion unavailable — a specific criterion could not be observed this cycle.  attestation unavailable — used only where source attestation genuinely does not exist; DNO distinguishes “published on-chain” from “source attestation available.”

Defining this vocabulary does not mean DNO is currently computing or publishing per-participant results — see below.

What DNO deliberately does not do

The restraint here is not a limitation to apologize for; it is the source of DNO's credibility.

DNO does not score, rank, grade, certify, approve, recommend, or predict. DNO does not publish per-participant results on this page — this document is definitions only. DNO does not republish, mirror, or derive from any reputation, credibility, points, or per-account labelling that may exist elsewhere; where such signals exist, they belong to the systems that maintain them. DNO does not act on the set it observes, participate in the network, or influence admission.

A DNO observation means exactly one thing: an independent, non-participating observer, with no stake in the outcome, saw this from its stated vantage, subject to the limitations named above.

Relationship to a published observation surface (gated — not live)

These definitions exist independently of any surface that would apply them. An evaluator that emits meets_published_criteria per participant is a separate, gated capability and is not live. Two conditions gate it, and neither is satisfied by this document: (1) a sufficient, continuous observation history exists (until then, the honest output is insufficient observation history); and (2) the external boundary is settled — a public position that admission is not DNO's to grant and that any DNO methodology is one non-binding evidence source, with no mechanical “meets-DNO-criteria → promoted” rule. Publishing these definitions requires neither gate. Applying them to participants in public requires both, plus a named external consumer that has stated a specific need and accepted the constraints on use.

Versioning and changelog

Criteria Framework version: 1.0  ·  Effective date: 2026-07-06. Every change to a threshold, window, measurement source, or state definition increments the framework version, is recorded below with an effective date, and preserves prior versions for citation. /criteria.json is the machine-readable form of this document and carries the same version and effective date; the two must not diverge.

Grounding note

The observable quantities and their limits are grounded in the Demos network's own documented behavior (node RPC surface, validator lifecycle, GCR state-consistency hashing, consensus and fork semantics) as verified against primary sources on 2026-07-06. The threshold values (3 blocks, 97%, 95%, 2 resets, 120 hours) are DNO's own published parameters, not values Demos requires of anyone. DNO takes no position on whether Demos's own criteria are correct or sufficient.