Demos Network OracleDNOconnecting
Menu

Context for the reading

About Demos

Demos is the network DNO watches. This page sets out what the Demos documentation says about validators, shards, node health and DAHR, and which of those DNO can see from outside. Every protocol statement links to the page it comes from.

Source docs.kynesys.xyz Read 28 Sep 2026 DNO is not an official Demos product
On this page
  1. What Demos is
  2. Two mechanisms
  3. Validators
  4. A shard for each block
  5. Inside a shard
  6. A node's own health
  7. DAHR
  8. What DNO does with DAHR
  9. Words that must not share a label
  10. What DNO cannot see
  11. Sources

What Demos is

The Demos docs describe the Demos Network as an interconnectivity layer across chains and web contexts. The network has two parts, the node and the SDKs, and its nodes “can act either as validators or as synced read-only nodes” (architecture). Consensus is PoR-BFT, “Proof of Reputation (PoR) Byzantine Fault Tolerance” (consensus).

Parts the docs name

Consensus
PoR-BFT. Validators are shuffled into shards for each block; see below.
State
The Global Change Registry (GCR) holds account and subnet properties once blocks are synced (GCR).
Identity
Cross Context Identities (CCI): each address carries an identities object in the GCR (CCI).
Cross-chain
The XM SDKs “help you create payloads to interact with other blockchains from DEMOS” (XM).
Web2
DAHR relays an HTTP request and anchors hashes of the response on chain; TLSNotary produces proofs from TLS sessions (Web2). See DAHR.
Privacy
L2PS, the Layer 2 Privacy Subnet, “a privacy-preserving transaction layer that enables encrypted transactions” (L2PS).
Where DNO stands

DNO is an independent observer built by XM33, not part of Demos. Its public reading comes from three public Demos endpoints read from outside, and from validators that answer as listed when fewer than two of those give their own height. It does not operate the protocol, admit validators, or decide anything on the network. DNO itself does not validate. XM33 runs a validator on the public testnet. In the public reading it counts like any other validator, and only if it publishes an address on chain.

Two mechanisms, two questions

DNO's cross-check compares public answers. Demos shard composition is a consensus step inside the network. They answer different questions, and DNO never sees the second one.

Outside: DNO's cross-check every 20 s

  1. 3 public seedstheir /info answers
  2. Own heightseach seed's own peerlist entry
  3. Median, ±25a height in the band is aligned
  4. Agreementstrong · moderate · weak · unknown
  5. Statuson /organism, with its reason

Inside: Demos shard composition every block

  1. validators tableACTIVE rows are eligible
  2. CVSA seedSHA-256 over recent block hashes
  3. Compositionthe seed shuffles the eligible set; validators failing health or sync checks are skipped (Phase 1)
  4. Shardruns consensus for the block, one round at a time
Upper lane: what DNO computes. Lower lane: the Demos docs' description.no live data in this figure

DNO's cross-check

DNO, from outside

Question
Did the public seeds answer, do the heights they report agree, and has DNO counted less than 30 minutes without a new height?
Inputs
The /info answers of three public Kynesys seeds. A seed's height is its own peerlist entry; a seed that does not list itself has no height here. When fewer than two seeds give their own height, the /info answers of validators that answer as listed stand in.
Output
status on /organism, always with status_reason.
Also dialed
The cross-check RPCs (DAHR is attempted there) and fixnet peers for the reference table: never in status. The address each ACTIVE validator published on chain (counts only, on /health): in status only when those validators stand in for a seed.

Demos shard composition

The network, for every block

Question
Which validators form the shard for this block?
Inputs
Validators that are ACTIVE on chain, and the CVSA seed.
Output
The shard that runs consensus for that block.
What DNO sees of it
Nothing.

So a stable reading means the public seeds answered (or validators stood in for one), the heights compared agree, and DNO has not counted 30 minutes without a new height. It does not mean a shard formed, that a given identity sat in one, or that the network is healthy in the sense the Demos docs use.

Validators

In the Demos docs, a validator is “an on-chain row in the validators table”. Its status moves through three states, driven by three transactions: validatorStake, validatorUnstake and validatorExit (validator lifecycle).

Select a state to see its moves.

“Participating in consensus, eligible for shard selection.”ACTIVE, in the validator lifecycle page

MoveTransactionWhat the docs say
new → ACTIVEvalidatorStakeNeeds the minimum stake and a connection URL.
ACTIVE → ACTIVEvalidatorStakeA top-up adds to the stake.
ACTIVE → UNSTAKINGvalidatorUnstakeArms the lock: unstake_available_at = current block + 1,000.
UNSTAKING → EXITEDvalidatorExitOnly after the lock has elapsed.
UNSTAKING → ACTIVEvalidatorStakeA top-up clears the unstake, so every stake unit sits under a fresh 1,000-block lock before exit.
Validator states and moves.as the Demos docs describe · no live data

“Stake doesn't currently weight the random pick (Phase 2), but it gates eligibility (you must be ACTIVE).”

The minimum stake, and reading the table

The minimum stake is a network parameter, minValidatorStake, not a fixed figure. The public Demos SDK reads the value in force with getNetworkParameters(), which it describes as the genesis defaults with every active network upgrade applied, and returns it as a whole-number string (Demos SDK). DNO assumes no figure.

The same SDK lists validator rows with getValidators(): the rows whose status is still active at a block. The lifecycle page describes UNSTAKING as still active until exit and EXITED as removed from the active set, so a count of exited validators does not come from that list.

What DNO sees of this

Counts, as the public seeds list them. Once a minute DNO sends both calls to the three public seeds. It publishes how many rows are ACTIVE and minValidatorStake, each only when at least two seeds return the same answer; it publishes no address and keeps no stake. It then dials the address each ACTIVE validator published on chain and counts the answers: see how the counts are made. It publishes no identity. Given one full key, Find a node on the homepage says whether the agreed list shows that key ACTIVE or UNSTAKING, lists it with another status or does not list it, or that no agreed list is available; it says nothing about any other key.

The first read, with DNO's probe tool on 29 September 2026 at 09:05 UTC: two of the three public seeds returned the same 35 rows, all ACTIVE, and the same minValidatorStake, 1000000000000 as reported. The third seed did not answer.

The first dial, with the same tool at 11:31 UTC that day: 26 of the 35 rows were dialed at the address they published and 9 were not. 7 answered as their own key, all at the seeds' height; 18 answered with another key; 1 did not answer. A count of the published addresses at 11:41 UTC: the 9 publish none, and the 26 sit on 8 origins, one of them published by 19 keys. 2 of the 7 keys that answered as themselves are public seeds. 18 listed keys share one published origin with a key that answered. That is not 18 nodes down. Two runs from one place, not this cycle.

The identities in DNO's catalog are names listed on public peerlists, not validator rows: a larger catalog is not a larger validator set.

A shard for each block

“PoR-BFT shuffles the eligible validator set into per-block shards using the CVSA seed — a deterministic SHA-256 over recent block hashes”

Because the seed comes from recent block hashes, the same page says “no operator can predict or influence which validators land in their shard”.

Phase 1: out-of-sync validators are skipped

“validators that fail health/sync checks are skipped during shard composition for the affected blocks”

The docs name the causes as “bad latency, divergent state, or active malice”, and say plainly that this is not a penalty: “Phase 1 does not slash, burn, or otherwise penalise stake.” Slashing, “active stake removal as a punitive response to provable misbehaviour”, “is a Phase 2 feature.”

Select a validator to mark it out of sync for this block.
  1. Recent block hashes (made up)
  2. Seed: SHA-256 of thosecomputing
  3. Validators this block

    ACTIVE, eligibleout of sync: skipped this blockEXITED: never eligible

  4. Order drawn from the seed
  5. A shard for block 1
Illustration of the docs' description, computed in your browser: made-up hashes, twelve generic validators, a shard of four. The pages linked here do not give the following, so they are placeholders: how many recent hashes feed the seed (three here) and how they are combined (their hex joined, then SHA-256), the shuffle (Fisher–Yates on a SHA-256 stream), the shard size, and when out-of-sync validators are skipped (before the shuffle, here).no network data · DNO does not see this step

Inside a shard

“Per-shard consensus itself runs sequentially — one consensus round per shard at a time — not multiple rounds in parallel within the same shard.”

The parallel part is applying transactions. Within one block, independent transactions are split into groups and up to 8 groups are applied at once; the gain “lives in transaction-application within a block”, “not in concurrent consensus rounds”.

What DNO sees of this

A height that moves, or does not. A designed pause and a fault look the same from outside, so DNO never says why a height stopped.

A node's own health

Every Demos node answers an unauthenticated GET /health on its RPC port. The status is the node's own word (health and readiness):

StatusWhat the docs sayHTTP
ok“All subsystems healthy, main loop alive.”200
degraded“At least one non-critical subsystem is failed, but the chain and main loop are alive.”200
dormant“The node booted with an empty peer list and intentionally skipped signaling/MCP/TLSNotary/main loop.” Sent with an X-Demos-Dormant: true header.200
failing“The mempool/DB is unreachable, the chain subsystem failed, or the main loop died (and the node is not dormant).”503

On readiness, the same page adds that “a probe wanting to gate traffic until consensus participation can additionally inspect dormant / the X-Demos-Dormant header or require boot.complete === true”.

What DNO sees of this

None of these words. DNO reads each seed's /info, not its /health, and none of these statuses appears in DNO's reading. The peerlists DNO reads carry an online flag and one more status flag for each listed peer. DNO shows the online flag as peer-reported and leaves the other flag out, because the pages linked here do not say what it means.

DAHR

DAHR is the Data Agnostic HTTPS Relay (DAHR API reference). A client using the SDK calls createDahr(), then startProxy({ url, method }). A Demos node forwards the request to the target, returns the response, and hashes it.

  1. 1client → Demos nodestartProxy({ url, method })
  2. 2Demos node → target URLforwards the requesthttp or https only
  3. 3target URL → Demos nodethe response
  4. 4Demos nodeSHA-256 of the body, SHA-256 of the headersheaders are canonicalized first: keys lower-cased, volatile and hop-by-hop headers dropped, sorted by key
  5. 5on chainone web2Request transaction per callit stores the hashes, not the data; the pages linked here do not say which party signs and broadcasts it
  6. 6SDK → clientthe response, its hashes and the txHashreturned once the transaction is confirmed and broadcast; txHash is optional in the result type

“Each startProxy call creates one on-chain web2Request transaction that stores only hashes of the response (body and headers), not the full data.”

What one call records

  • SHA-256 hashes of the response's body and headers, in one on-chain web2Request transaction.
  • Anyone holding the same response bytes can hash them and compare.

What it does not

  • Store the response itself: only hashes go on chain.
  • Say whether the content is correct, current or complete.
  • Prove the TLS session. That is TLSNotary, a separate mechanism the docs list as slower (about 2–5 s against about 500 ms) and costlier (1+ DEM plus gas, against gas only).

Same letters, different object: the Key Server OAuth flow returns a DAHRAttestation, an Ed25519-signed record that the Key Server performed a verification (Key Server OAuth). DNO does not use it.

What DNO does with DAHR

  1. Each cycle DNO dials its cross-check RPCs. For each one that answers, it asks a Demos node, through the SDK, to relay a GET of that RPC through DAHR.
  2. It counts an attestation only when a transaction hash comes back, and keeps the URL, the transaction hash, the response hash, the HTTP status and the time.
  3. When on-chain publication is enabled, DNO attaches those records to its fleet alerts and daily summaries, never to the public reading. On-chain publication is disabled, so DNO posts none of them. The relays themselves still happen: per the Demos docs each relay call creates a web2Request transaction, and DNO counts a relay when a transaction hash comes back, without checking that the transaction was included.
  4. /health reports the state in attestation: available, last_count (how many of those relays returned a transaction hash this cycle) and last_ok_at.
Not the seeds

The three seeds whose answers enter status are not relayed through DAHR, and /organism carries no attestation. That is why the homepage says Observe. Explain. and mentions DAHR once, under the API: the sentence about the cross-check RPCs while attestation.available is true, and “DAHR attestation unavailable.” while it is false. The sentence also says that the reading itself is never posted.

Words that must not share a label

Demos uses its own words for a node's health, a validator's status and a validator skipped from a shard. DNO's words are different, and they describe what DNO saw from outside.

Show
WordWhose wordMeaningDNO sees it?
ok degraded dormant failingthe node's own GET /healthok: subsystems and main loop up. degraded: something non-critical failed, chain still up. dormant: booted with no peers and skipped work on purpose. failing: chain, mempool or main loop down.No. DNO reads /info, not /health.
ACTIVE UNSTAKING EXITEDthe on-chain validators tablea validator row's status. ACTIVE is eligible for shard selection.Counts of ACTIVE and UNSTAKING rows, as two public seeds list them. EXITED rows are not in that list, and no row is named.
out of syncconsensus, Phase 1that validator is skipped for shard composition on those blocks. It is not slashing.No.
stableDNOthis cycle's reading of the public seeds, or of the validators standing in for a missing one: the heights compared agree (strong), DNO has not counted 30 minutes without a new height, and no warning or critical public incident is active.Yes. It is not ok, and it is not ACTIVE.
at the seeds' heightDNOa validator's own height, in its answer when DNO dialed the address it published, within ±25 blocks of the seeds' median.Yes, for validators that answered. It is not Demos' sync check, and it is not out of sync.
strong agreementDNOevery own height sits within DNO's band, ±25 blocks of the median, and the spread is at most 20 blocks.Yes, for the heights it compared: the seeds' own; one seed's and the closest stand-in's; or, with no seed, the counted stand-ins'.
sufficientDNOat least two seeds reported their own height, or validators that answer as listed stood in for the missing one, and the observation is at most 300 s old.Yes. It describes DNO's vantage, not the network.
reachable unreachableDNO, for endpoints it dialsan endpoint DNO dialed answered, or did not: the probed seeds on the homepage, the cross-check RPCs on /federate, the probed fixnet rows on /reference.Yes, for those endpoints. Never for peer-listed identities, which DNO does not dial.
peer-reporteda seed's peerlistwhat a public peerlist said about another identity. DNO did not dial it.As reported, never confirmed.

All 3 public seeds answered and their reported heights agree.One of the plain sentences DNO uses for a calm reading. It never says the Demos network is healthy.

What DNO cannot see

  • Who is in a shard.
  • EXITED validators: the list DNO reads holds only rows still active at the block.
  • Votes, admission, and the health and sync checks consensus applies.
  • A node's own /health status.
  • Whether a peer-listed identity is a validator, or whether it answers: DNO does not dial the catalog, and matches no catalog row against the validator list. Find a node checks only the one full key a reader gives it.
  • Why a validator does not answer DNO. The address may refuse outside callers or be out of reach from here only; the row on chain does not change.
  • What stands behind an address that several validators publish. Its answer names one key.
  • Why height stopped. A designed pause and a fault look the same from here.

Sources

Demos documentation at docs.kynesys.xyz, read on 28 September 2026. If the docs change, this page may lag; the linked pages take precedence.

How DNO forms its own reading: Methodology · Sources · Agent guide.