Resolution model
- Sources. Each configured seed's
/infois fetched every 20 seconds, in parallel. - Observation. Whether each seed answered, its own block height (its own peerlist entry), its version and its peerlist. A seed that does not list itself has no height here.
- Stand-ins. Only when fewer than two seeds gave their own height: up to 8 validators are read in the same round: those DNO keeps as candidates, each of which answered as listed, at the seeds' height, within the last 24 hours. One within ±25 blocks of the one seed counts with it; with no seed, at least two of them, more than half of those that gave a height, within ±25 blocks of their median give the reading.
- Aggregation. The heights are compared with deterministic rules: the median, a ±25-block band, agreement. A reading that would be stable is degraded once DNO has counted 30 minutes without a new height.
- Public state. Status and the other six values on
/organism. The same inputs, history and observation age always produce the same public state.
While two seeds give their own height, status uses only those seeds. With fewer, it uses the one seed and the validators within 25 blocks of it, or validators alone, and /organism says which in witnesses. The resulting state reflects agreement, disagreement and uncertainty across the heights compared.
Source layers
| Layer | What DNO reads | Enters status |
|---|---|---|
| Public seeds | Kynesys-operated public endpoints: kyne-node2, kyne-node3, kyne-node3b. One operator: node3b is a second port on the same host as node3, not a fourth org, and a second hostname that points at node3 is an alias, not a fourth seed. | yes |
| Peer-listed identities | Identities copied from the seeds' own peerlists, with what those peerlists reported (online flag, sync status, advertised height). A new identity is kept after two public peerlists have listed it. DNO does not dial them. | no |
| On-chain validators | The validators table and the network parameters as the same three seeds return them (getValidators, getNetworkParameters), once a minute; a count only when two seeds give the same answer. Then one /info a round at the address each ACTIVE validator published on chain, only when it is a public http origin. Counts on /health; no address, key or stake is published. Up to 8 of those that answered as listed, at the seeds' height, are kept as candidates and read in the place of a seed that gives no height. | only in a seed's place, when fewer than two seeds give their own height |
| Cross-check RPCs | Public Demos RPC endpoints, dialed once per fleet cycle: answered or not, and latency. DAHR is attempted there (see below). | no |
| Fixnet (reference) | The peerlists of DNO's operator's own fixnet nodes, and of an anchor node when one is configured. The identities they list are probed for reachability, height and latency only when the address they advertise is a public http origin; other rows are shown as not probed. The operator's own nodes are not rows of the table; a configured anchor is, and heights are shown against it. An identity the public seeds' peerlists list is not kept in it. | no |
No row for a discovered identity carries an operator name: peer-listed identities appear as a truncated key on /reference and as discovered- plus the last 4 characters elsewhere, and discovered fixnet rows as discovered- plus the last 4 characters.
Separation rules
Public status, risk, trend, agreement, confidence and data quality are computed from the public seeds, and from validators that answer as listed when fewer than two seeds give their own height. Fleet data is used internally as a reference layer and does not influence public assessments; fleet views are served on DNO's internal listener only.
DNO does not validate. Its operator, XM33, runs a validator on the public Demos testnet. That validator is not fleet data in the public reading and has no place of its own in it: it can stand in for a seed only as any validator can, by publishing an address on chain and answering there as the listed key.
Public endpoints
- /organism
- The public reading. The contract is /organism/schema.
- /health
- The same labels and reasons without the summary sentence, and their parts: each seed,
witnesses(what the reading rests on),validator_growth, attestation state, and the on-chain validator counts (on_chain_validators,validator_watch). - /incidents
- Public records; each row is an incident or a condition record.
- /catalog
- Peer-listed identities, sanitized.
/catalog/lookup?key=0x…checks one full key against the catalog and the agreed validators list, and never returns a key. - /peers
- The latest crawl only, truncated identities.
- /federate
- Prometheus metrics: version, and cross-check RPC reachability and latency under neutral names.
- /badge
- An SVG of the current status word.
Every endpoint is listed on /docs.
DAHR
DAHR, the Demos Data Agnostic HTTPS Relay, is attempted on the cross-check RPCs, not on the seeds whose answers enter status. /health reports it in attestation: available, last_count (how many of those relays returned a transaction hash this cycle) and last_ok_at. /organism carries no attestation.
While on_chain_publication is disabled, DNO sends none of its own posts on chain (fleet alerts, recoveries, daily summaries; the public reading is never posted). The relays still happen: per the Demos docs each relay call creates a transaction, and DNO does not check that it was included. DAHR does not remove observational limits or guarantee future conditions. What one DAHR call records, and what it does not, is on About Demos.
Limits
Oracle outputs are based on externally observable signals available during each measurement cycle. Public endpoint availability, temporary network conditions or incomplete visibility may affect results. Outputs should be read as structured observed assessments, not guarantees of present or future network behavior.
A row in DNO's outputs is an observation of an identity or an endpoint, not a statement about whoever runs it.
The Oracle is a watch-only observability system with respect to the Demos network it observes: it does not command validators, advise operators, or predict outcomes. While on-chain publication is disabled, its on-chain activity is limited to DAHR requests on the cross-check RPCs. It does not provide financial, operational, legal, or governance advice.