How to read this document

What is here, what is deliberately not, and why the distinction matters.

Only open work appears below. Closed items have been deleted, not annotated. A list that keeps its successes becomes a list nobody finishes reading, and the successes are recorded in the commit history and in Integrity Criteria where they belong. The one exception is the short Permanent residuals section near the end: facts that are neither open nor fixable, kept only so they are not rediscovered as though new.

Each item says what it affects, what was measured, and what state it is in. “Measured” means read from a live system or from the source, with the method stated where the method is the interesting part. Where a figure is as-of a date, the date is given, because several figures in earlier versions of this document drifted out of true while nobody edited them.

Three states are used. Hazard is live — it is wrong now, or it will be wrong the next time something touches it. Built, not in service means the code exists and is correct as far as it is exercised, and nothing runs it; this is the single largest category in this estate and the one most easily mistaken for done. Decision means engineering is not the blocker.

The position in one page

Six things, which between them explain most of the list below.

Almost nothing has traffic, and most “blocked” items are blocked on that one fact. xpyr.pending_transfer and xpyr.ledger_journal both hold zero rows on all eight gov replicas, so there is no money anywhere in the system. The registry’s claims tree holds two party locations, seeded on 24 September purely to unblock the proof path, and idloc_claims.federation_identity_claims holds none at all. The chains themselves are busy — the gov meshes are past 779,000 and 728,000 blocks respectively and the registry mesh carries hundreds of thousands of app-hashes — so the meshes work and the pipelines above them have barely been exercised. That is the single most useful thing to know when reading the rest.

The recurring defect is not failure. It is silence that reads as health. This is the organising theme of the whole document and it has three distinct shapes, which are worth separating because they need different fixes. The looking is broken: a check whose target is fine and whose verification compares nothing with nothing. The wiring was never finished: a binary reading a setting no charm can supply, so a correct capability is unreachable and every local test passes. The writing lands nowhere readable: a grant to a role that does not exist, a table no auditor can select from, a record nothing ever reads back. In all three the component is correct, every signal says fine, and the property the component exists to establish does not hold.

The third shape was measured on 1 October and it had been live for weeks. Two separate gov mechanisms granted audit read access to cc_auditor_ro — a role that exists on member-classes and on the registry and on none of the eight gov Patroni clusters. Both gate their GRANT on the role existing, because an absent role is legitimately normal on some databases. So both ran clean DDL, granted nobody, and reported it accurately in a startup line nothing was reading: settlement auditor grants SKIPPED: role not present on this database. The catalog confirmed it — zero grants to any audit role on all four xpyr settlement tables, including xpyr.transfer_commitment, whose entire purpose is selective disclosure to an auditor. The role that works is cc_gov_ro, holding SELECT on 13 gov_coord tables. The log line was true and useless, because it never said which names it had tried, so a wrong constant and an undeployed audit tier read identically.

Nothing can put money into an account, and the obstacle is delivery rather than code. fund_position is the only production funding path and it requires a slab proof against a root in xpyr.anchored_root, which holds zero rows on all eight gov replicas. merkle-funnel has a real Hedera submitter, rolled to all four replicas and verified from /proc, so ANCHOR_CHAIN accepts hedera and not only filestub. It is inert for three reasons at once: anchor_chain is unset so the producer does not start; the deployed charm carries anchor_chain but none of the four hedera_* options the binary reads, so it cannot be switched on until that charm is repacked; and gov’s anchor relay is unconfigured. Neither half works alone — the funnel publishing with gov not looking, or gov reading a topic nothing publishes to, both leave the table empty.

The same source is checked out twice in several places, and the copy that compiles is often not the copy people edit. This has produced four distinct failures so far: fixes written to Go that never builds, a stale orgsnode charm deployed over a current one, a wrong conclusion that two auditor tiers were unaffected by a shared-package fix, and a determinism fix landing in the uncompiled copy. The guard that exists checks the directories builds run from, not the modules those builds compile in, so it is blind to exactly the case that bites.

The independence claim is the load-bearing thing that is not engineering. The custody arrangement with an arm’s-length agency is unsigned. Until a second organisation runs the checkers, holds keys we never see and operates its own control plane, the audit tier is independent of the consensus and not of the operator, and should be described that way in every document that touches it. Most of the code this implies is built or building; the gap is organisational. The Emergency Brake being 1-of-1 and Game Day drills being run by the party under test are the same gap wearing different clothes.

What gates everything else

Six items whose resolution unblocks disproportionately more than their size suggests.

Live security exposure

Evidence that is written where nothing can read it

The third shape of the silence pattern, and the one with the most instances. In each case a record exists or is being produced, and the thing that was supposed to consume it cannot or does not.

Built, correct, and unreachable

The supply-side twin of the silence pattern. A binary reads a setting; no charm can supply it; every test passes and the capability is dead. There is still no guard comparing the settings a binary reads against the options its charm declares, so the next instance will again be found by trying to use the feature.

Correctness defects in code that runs

These compute or record the wrong answer today, as opposed to not running at all.

Duplicated source, and builds that cannot see it

One family, because every item here has the same consequence: a correct fix that does not reach the artefact, with a successful build either way.

Operational fragility

Assurance gaps

The reason a green audit result is not yet evidence. Of the items Integrity Criteria records, those below have not closed.

The registry’s shape

Read from the live registry rather than the repository, because the schema is not in the checkout: national-registry/registry is the charm directory, and a repo-wide search for registry_coord in Go returns nothing. Nine application schemas and 27 tables as at the last re-measurement. Two business rows exist in the entire registry — the party locations seeded to unblock the proof path — against hundreds of thousands of rows of consensus bookkeeping. The findings below are structural and none has closed.

Blocked on decisions

Engineering is not the blocker on any of these.

Naming and transport: what should replace plain DNS

A position, not a decision already taken. The question is what clients should trust when they connect, and the honest answer is that today they trust the wrong thing.

The defect is not that DNS is old. It is that DNS is load-bearing for identity. A domain-validated certificate is issued on proof of domain control, so the chain runs registrar → TLD → DNS → certificate issuance → TLS identity. Every link is a party that can be compelled, and several are jurisdictional. For a platform whose proposition is cross-jurisdictionally verifiable proof, that is a hole in the transport that the cryptography above it cannot close: a single registrar or government can decide who a user reaches, regardless of how sound the consensus and the anchoring are.

Encrypted DNS and DIDs fix different halves, and neither is redundant. DNS-over-HTTPS or DNS-over-TLS closes the privacy and on-path tampering legs: an observer no longer sees which names are resolved, and a hostile local network cannot forge answers. It does nothing about authority — the record can still be revoked or seized, and issuance is still tied to domain control. An Elastos DID closes exactly the leg encrypted DNS leaves open, by removing DNS from the identity path altogether. Verified against the live network on 2026-08-09: EID mainnet is reachable at api.elastos.io/eid (chain ID 22) and resolution through the custom did_resolveDID JSON-RPC method is free and already works, needing no funds and no contract knowledge. Only publishing costs ELA.

Where Kademlia fits, and where it does not. Kademlia is a distributed hash table: instead of asking one authority where something lives, a client routes the question through other peers, hopping progressively “closer” to whichever node is responsible for the key. Closeness is the XOR of two identifiers, so a node’s ID decides which keys it answers for — and that one property is the source of both its appeal and its central weakness.

The failure mode is eclipse, and it is targeted rather than random. A Sybil attack is simply the observation that node identifiers are cheap, so one party can run thousands. Eclipse is what that buys: because responsibility is determined by XOR distance to a key, an adversary can grind identifiers — generate them until enough land near the key, or near the victim — until the peers a client would consult are all its own. Every routing table entry the victim holds points into attacker-controlled space. The attack is not probabilistic and does not require majority control of the network; it requires only enough identifiers positioned in one small region of the keyspace, aimed at one target.

For an audit platform this is the worst available failure, because it lies by omission and produces no error. An eclipsed client is not disconnected and sees nothing malformed. It sends lookups, receives well-formed answers, and gets a complete-looking view of a reality the adversary selected. The damage is specific to what auditing is for: an auditor that cannot see a finding reports no findings, and absence of evidence is indistinguishable from evidence of absence. A hijacked DNS record at least tends to fail loudly — a certificate mismatch, a refused connection, an outage somebody notices. An eclipse is quiet by construction, and a clean audit report produced under one is worse than no report at all, because it will be believed. This is the same defect that recurs throughout this document in other clothes: a check whose target is real but whose looking is broken.

The bootstrap problem survives the change. A DHT cannot be joined from nothing; something must supply the first peer. In practice that is a hardcoded address list, a signed bootstrap file, or DNS seed names — which is how DNS tends to reappear underneath the very system adopted to replace it. Adopting a DHT as the naming layer therefore does not remove the dependency it was chosen to remove; it moves it somewhere less examined.

The operational objections are mundane and decisive. Enterprise networks block peer-to-peer traffic as a matter of policy, inbound connections die at corporate firewalls and behind NAT, and a DHT lookup costs several round trips where a resolver cache costs none — a poor trade on an interactive submission a user is waiting on. None of this is fatal to a background process; all of it is fatal to a naming layer that every client must traverse before it can do anything at all.

What changes when identity comes from keys. Every objection above is an objection to trusting the DHT. Once the platform’s identity is a public key and the response is signed, the routing layer is untrusted by construction and eclipse degrades from deception to denial: an adversary who controls every peer a client can reach still cannot produce a signature it does not hold, so the worst it achieves is preventing a connection. Denial is survivable, detectable and recoverable — another discovery path, a cached address, a different network. Deception is none of those things. That difference is the whole argument, and it is why the role matters more than the technology.

The rule that keeps it safe: a discovery channel may tell you where, never who or what. Answers that are self-authenticating — a signed DID Document, a content-addressed slab, an attestation carrying its own did:key signature — may be routed through anyone, because the recipient verifies them without reference to how they arrived. Answers that would be believed on the strength of their source must never be. In particular, no query whose meaning depends on completeness may be served this way: “every attestation for this height” or “all findings against this federation” cannot be answered over a DHT, because omission is undetectable and the honest-looking short answer is exactly what an eclipse produces. Those questions belong to a quorum that can be counted, which is what the BFT meshes already are. As one discovery path among several, feeding identities that are verified afterwards, Kademlia is a good fit and being eclipsed costs a connection attempt rather than integrity. As the naming layer, or as the transport for any completeness claim, it is not.

A permissioned DHT changes the analysis, and the two DID methods do opposite jobs. Everything above concerns an open DHT, where eclipse is cheap because identifiers are free. Bind a node identifier to an admitted DID and minting a thousand identities means obtaining a thousand credentials — issuance being a governed, on-chain, auditable act that leaves evidence in the same ledger the auditors read. Grinding is closed the rest of the way by deriving the identifier from the registered DID and rate-limiting registration, plus per-bucket diversity caps that only a permissioned network can enforce, because only there can you tell who is who. The bootstrap regress becomes void: peers come from the on-chain directory the platform already operates, so DNS never reappears underneath. Here the two DID methods are complementary rather than alternatives. A did:key cannot be revoked — it is purely generative, the identity is the key, which is exactly why an attestation signed under one verifies offline and forever with no registry to reach. An Elastos DID is an on-chain document with rotation and revocation, which is exactly what membership needs and what did:key structurally cannot express. So: Elastos DID for admission, did:key for attestation, Kademlia for routing alone.

What a closed perimeter does not buy: private is not trusted. The members of a permissioned network are the parties being audited. The entire reason for BFT meshes and independent auditor tiers is that participants may be compromised or hostile; if members could be trusted, none of it would be needed. An admitted member holding enough node identifiers can still eclipse a peer, with better cover than an outsider, because every entry in the routing table is legitimate. Two consequences survive the perimeter unchanged. Completeness claims remain unservable over a DHT, so “every attestation for this height” belongs to a quorum that can be counted. And an insider who cannot forge will instead try to silence: partition an auditor and it stops seeing, whereupon it reports no findings, which reads as nothing wrong. Denial is only safe when it is detected, and today it is not — see the row above on counting expected attesters against reporting ones.

Member-level Sybil is a different problem and it does NOT lead to eclipse. Everything preceding concerns NODE identifiers, where cheap identities buy XOR-adjacency and therefore eclipse. Binding node IDs to admitted DIDs closes that. The remaining Sybil surface is a different population entirely: member companies, covered under assurance gaps above. It buys votes, not routing-table entries, so it eclipses nobody — and conflating the two understates both. Permissioning does not remove it; it converts it from a compute problem into a due-diligence problem, executed on paperwork before it ever reaches the network.

Whether a DHT is the right answer at all is a question of scale, not of security. Kademlia earns its complexity where membership is large, unknown and churning. This membership is governed and enumerable, and the meshes themselves are 7 to 13 nodes — a list, not a routing problem. For a few hundred stable organisations a signed membership list distributed over the consensus already running is simpler and strictly safer, because there is no routing table to poison. A permissioned DHT begins to pay for itself at thousands of endpoints with real churn, where keeping that list current everywhere becomes the harder problem. The decision turns on endpoint count and turnover and should be taken on those numbers.

The shape that follows. Identity is the public key; the platform already runs this, with auditor attestations signed under did:key identities and verifiable straight off the chain with no schema and no build of ours. Discovery — DNS, a DHT, a signed bootstrap list, a configuration file — becomes a hint rather than a trust anchor, and the same rule governs all of them equally: they may route, they may not attest. A hijacked record can then stop a client connecting and can never impersonate the platform, because the name was never what authenticated it. Nearly all of the risks DNS forces onto clients are identity risks wearing naming clothes; remove DNS from the identity path and what remains is a routing optimisation that may be duplicated, replaced or lost without consequence — which is also the test for admitting any new discovery mechanism, Kademlia included. If losing it entirely would cost only reachability, it is safe to add. If losing it would change what a client believes, it is in the wrong layer.

What would still be required, in rough order of difficulty.

Permanent residuals

Neither open nor fixable. Recorded only so they are not rediscovered as though new, and so nobody spends effort trying to recover what the arithmetic says is gone.

What to do next

Four observations that follow from the list rather than from preference.

Three missing guards would convert most of this document from recurring surprises into build failures. They are: a check that every setting a binary reads is declarable by its charm; a duplicate-checkout gate that looks at the modules builds compile in rather than the directories they run from; and a rule that no grant, no gate and no digest may name a role, table or column as a compile-time constant where it is really a runtime fact about the deployment. Each of the three has already produced multiple independent incidents. None of them is more than a day’s work, and each one retires a whole category rather than an item.

Prove every guard in both directions, without exception. Every guard in this estate that was tested only in the passing direction has eventually been found to pass when it should have refused — a check comparing nothing with nothing, a pack that skipped a charm, a gate piped into grep that took the pipe’s exit status, a role check asking about a role that did not exist. The discipline that works is mechanical: inject the defect, watch the named guard fail, revert, watch it pass. A guard nobody has seen fail is not a guard.

Several irreversible windows are open only because nothing has traffic yet, and they are closing. Aperture II’s A3 can attest that commitments matched the plaintext only before sealing. The registry schema can gain foreign keys, history tables and constraints as a schema edit only while its tables are empty — and they are no longer quite empty. Two rows are trivially migratable and the point is the direction, not the number. Doing this now is cheap; doing it later is a migration under load, on tables whose constraint violations inside FinalizeBlock halt a mesh rather than reject a row.

The naming question should be settled before the client surface is built, not after. Deciding that identity comes from keys rather than names changes what the client does at connection time, and retrofitting it means re-issuing every client. The directory already exists in the registry schema, resolution already works on mainnet, and the one genuinely unbuilt piece is the session binding. That is a small, well-defined piece of work sitting in front of a decision that gets more expensive to reverse with every client shipped.

Tx-Rails — Built by IT/OT Chain & Cloud Australia (ITOTCCA). Sydney · London.