The National Registry
Who is this party, where do they legally sit, and who is entitled to stop them.
Every distributed system eventually has to answer those three questions. The National Registry is where Tx-Rails answers all three — on its own Byzantine-fault-tolerant mesh, with its own independent auditor tier, so the answers cannot be quietly edited by the operator of the system that depends on them.
The transaction layers of a supply-chain or business-process network are the part everyone designs first: nodes execute business logic, reach consensus, and anchor the result. But every one of those layers is standing on a set of assumptions it never verified. That a federation claiming to be a UK housing provider actually is one. That the data centre holding its records sits in the jurisdiction its contract names. That the regulator with veto rights over an action is the regulator on record. That an officer casting an executive consent vote holds that office today, not last year.
In most architectures those facts live in a configuration file, an admin database, or an identity provider — somewhere a single operator can change, without consensus, without an audit trail, and without anyone downstream being able to tell. That is the weak joint. An attacker who cannot break your consensus can very often simply re-register themselves as somebody with authority, and every honest node will then faithfully enforce the forged answer.
The National Registry removes that joint. Membership, jurisdiction and authority records are consensus state on a dedicated ten-node BFT mesh, written through the same FinalizeBlock path as any other transaction, and audited by a second, independent mesh of equal size whose only job is to disagree.
What the registry holds
The registry is not one service. It is a roster of related authorities sharing one consensus mesh, one block history and one audit tier. They fall into four groups.
1. Membership and identity — who is this party?
PyramidRegistryService holds the membership graph: which federations belong to which pyramid, registered and removed through consensus actions rather than an admin console — RegisterMembership, RemoveMembership, PyramidOf, ListMembers.
IDLocationClaimsService holds each federation’s own DID-verified self-attestation of who it is and where its parties sit — ClaimFederationIdentity, RegisterPartyLocation, and their lookups.
The distinction matters and is deliberate: membership is conferred by an administrator; identity is claimed by the party itself. Keeping them as separate records is precisely what makes it possible to detect the case where the two disagree.
2. Jurisdiction — where does it legally sit?
DataCentreRegistryService records the data centres a federation operates through, at three resolutions: the data centre itself, its country-level location, and its precise location — RegisterDataCentre, RegisterDataCentreLocation, RegisterDataCentrePreciseLocation, each with a corresponding lookup.
This is the layer that makes data-sovereignty claims checkable rather than contractual. When a federation asserts that its records are held in-country, that assertion is a registry record with a block height attached, not a clause in a PDF.
3. Authority — who can approve, and who can stop?
ExecutiveConsentService and RegulatorVetoService are deliberately two mechanisms rather than one, because approval and prohibition are not the same power and should not share a ballot. Both register their principals on-chain (RegisterOfficer, RegisterRegulator), both expose CastVote and GetVoteStatus, and both resolve their tallies through consensus.
The asymmetry is the whole point. A regulator veto is a single-vote instrument: one approve=false from any registered regulator resolves the tally against the action, regardless of how many others approved. Executive consent is a positive-assent instrument. Modelling a regulator’s power as “one more vote for or against” is the mistake that makes automated governance unacceptable to actual regulators.
4. Regulator-facing channels — how does bad news travel?
AssetAlertRegulatorRelayService and HazardAlertRegulatorRelayService are the registry’s receiving ends for the compliance fan-out raised in the workload meshes. When an auditor node detects an asset-attestation mismatch or a housing hazard, the finding is dispatched to three recipient classes — client, architect and regulator — and the regulator leg terminates here, at the registry, outside the operator’s own mesh.
That placement is the entire design. An alert a regulator is meant to receive must not be deliverable only into infrastructure controlled by the party the alert is about.
How it is built
The registry runs as ten registry-node applications. Each node bundles three processes:
| Process | Role |
|---|---|
registry-api |
The gRPC surface — all seven services above |
registry-abci |
The application layer — executes registry actions inside FinalizeBlock |
goldbftd |
Consensus — the platform’s own CometBFT fork |
Those ten nodes are deployed across three models in a 4/3/3 split, but they are one BFT quorum, not three — n=10, f=3. The model boundary is an operational convenience for deployment and blast-radius management; it is not a consensus boundary. Every node runs the full service roster regardless of which model it sits in, so no single service depends on a subset of the mesh staying healthy.
The mesh also has its own dedicated host. It is not co-tenanted with the transaction layers it serves, which means a resource-exhaustion event in a workload mesh cannot degrade the authority records that workload is being judged against.
Its auditor nodes
Every Tx-Rails layer is mirrored by an independent ChubbyChecker auditor mesh that re-derives what the workload claims and reports when the two disagree. That mirroring is not a gesture: each auditor tier is sized 1:1 against the layer it watches, and takes the same deployment shape.
The registry gets exactly that treatment. Ten registry nodes, ten independent auditor counterparts, in the same 4/3/3 three-model split — so every registry node is watched at matching capacity by a node that shares none of its infrastructure. The same discipline runs the length of the platform: the overseers’ auditor tier reproduces their 4/3 split node for node, and the aggregator and top-hat tiers scale with their workloads rather than against them.
What singles the registry out is not the size of its auditor but the consequence of getting it wrong. It is the layer whose corruption is hardest to detect from anywhere else: if the membership graph lies, every downstream mesh enforces the lie perfectly correctly — each one behaving exactly as designed, on false premises it has no way to question.
Alongside the general check suite, the registry auditor runs four checks that exist nowhere else:
| Check | What it independently re-derives |
|---|---|
| Veto tally replay | Replays every regulator-veto tally from its full vote history, through the same algorithm the store itself uses, and compares the outcome. A stored result that cannot be reproduced from the votes underneath it is a forged result. |
| Location provenance | Every registered data centre has matching location provenance. Registration and location are two separate consensus actions, so a data centre can exist with no recorded jurisdiction — which is exactly the state a party would want if it were claiming one country and operating in another. |
| Claim ↔ country binding | Every federation identity claim naming a data centre is bound to a data centre actually registered under that same claimed country. The two services deliberately have no database-level foreign key between them, so this cross-check is the only thing that closes the gap. |
| Membership integrity | Every pyramid membership has a corresponding federation identity claim behind it. Membership is conferred by an administrator; identity is self-attested by the federation. A membership with no claim behind it is authority granted to a party that never asserted it exists. |
Read together, those four are a single argument: the registry’s separate services are cross-checked against each other, by a mesh that shares none of their infrastructure. An operator who edits one record has to edit consistently across services that were designed not to trust each other, on a mesh they do not control, without the auditor catching the intermediate state.
Where it sits
Tx-Rails runs its transaction workload through a layered BFT hierarchy — member-classes nodes execute business processes, an overseers layer enforces the process definitions, aggregators batch and roll up, and a top layer anchors to external DLT. Each of those layers is mirrored by its own auditor mesh.
The National Registry sits beside that stack rather than inside it. It is not in the transaction path — a business process does not wait on the registry to execute. It is in the authority path: the layers consult it to know whose claims to accept, and it is the destination for the regulator-facing findings those layers raise.
Two properties follow from that placement, and both are deliberate:
- A separate failure domain. The registry has its own host, its own quorum and its own auditor mesh. A workload mesh halting, diverging or being rebuilt does not touch the authority records it is judged against — and cannot be made to.
- A separate operator boundary. The regulator alert relays terminate on infrastructure outside the mesh that raised the alert. The party being reported on neither operates the channel the report travels through, nor holds the records establishing who the report goes to.