The National Meta-Federation
Where the “top-level” rules, when they apply to a company, are decided, are enforced, by whom, and on whose authority.
Also where the Executives of trading companies make decisions.
Every network that spans more than one organisation eventually needs to answer a governance question rather than a technical one: who may change the rules everyone else is bound by. There are 2 categories here: Firstly, Government appointed Regulators; secondly, Commercial (unregulated) Executives who need a secure system to Govern Trading with other companies on behalf of their own companies. The National Meta-Federation is where Tx-Rails puts those two sets of decision makers; on its own Byzantine-fault-tolerant mesh, with its own independent auditor tier, so a rule change is a transaction in a block rather than an administrator’s afternoon.
Below it sit the working layers: member-classes nodes executing business processes; an overseers layer enforcing process definitions internal to enterprises; aggregators and top hats carrying the record outward. Those layers are very good at doing what they are told. On the one hand the meta-federation is the layer that decides what regulated companies are told — and also which external transactions regulated business processes are forbidden, and finally it acts as the body upon which responsibility for legal breaches falls. On the other hand, the Commercial Executives represent their own companies in inter-company dealings, in particular, contract negotiations and transacting (eg being entitled to approve or block transactions).
In most architectures authority like that occurs as a deployment pipeline and an admin console. Whoever can merge and deploy can change the rules, often without agreement, frequently without a durable record, and also without the affected parties being able to verify what changed. Those are governance gaps, and they are items an auditor, a regulator or a counterparty will actually press on — because it is the point where a technically sound system can still be made to do the wrong thing legitimately.
What it governs
The Regulator governance mesh runs a small, deliberate roster of services. They divide along a line worth noticing: authoring a rule, running it, and stopping it are three separate powers with three separate mechanisms.
Authoring — what the rules are
For Regulators, GovernorStudioService is where regulation definitions are composed and versioned. A regulation definition forms part of the specification the overseers layers enforces downstream, so this is the surface on which “what the system under regulation is allowed to do” is actually written.
Running — the rules in flight
GovernorInstanceService and GovernorRuntimeService handle live instances of those definitions: starting them, advancing them, and reporting their state. The distinction from the studio matters — changing a definition and changing a running instance are different acts with different blast radii, and they are not the same permission.
Legitimately using rules in Stopping processses — the power to refuse
RegulatorVetoService is the asymmetric one, and deliberately so. A veto is a single-vote instrument: one refusal from a registered regulator resolves the matter against the action, regardless of how many parties approved it. It is not a seat at the table with a vote like everyone else’s.
(An ExecutiveVetoService is analogous to the latter Veto Service. Here the single-vote instrument operates in the same way except in relation to commercial Negotiations, Contracts and Transactions.)
Modelling a regulator’s authority as “one more vote for or against” is the mistake that makes automated governance unacceptable to actual regulators. A regulator’s power is not to out-vote you. It is to stop you.
The second arm of this Governance Tier is the commercial Executive Layer. This layer operates as a centre for inter and intra-pyramidal trade. Its positioning at a level between companies is why the technical system is shared with Regulators. This layer should not be associated with Industry Regulators, however, and it is only the networking equivalences with Regulators’ roles, in purely technical terms, that has led us to colocate these two separate services. That is, specifically both Regulators and Commercial Executives can coordinate transactions.
Contact: john@itotchaincloud.com.au
How it is built
Each governance node bundles five processes:
| Process | Role |
|---|---|
gov-api |
The gRPC surface — the studio, instance, runtime and veto services above. |
governor-abci |
The application layer — executes governance actions inside block finalization, so a rule change is consensus state. |
goldbftd |
Consensus — the platform’s own CometBFT fork. |
executive-gateway |
The authenticated entry point for executive actions. |
login-service |
Session and identity handling for the above. |
Nodes are deployed seven to a mesh, split 4/3 across two models. As elsewhere in the platform, the model boundary is an operational convenience for deployment and blast-radius management — it is not a consensus boundary. All seven form one quorum.
Two such meshes run side by side, on separate identities, so that a commercially-operated governance domain and a sovereign-operated one can exist in the same deployment without sharing a quorum. They are built from the same code and the same charm: the difference is who operates them, not what they are. That is by design, and it is what allows an operator to be swapped without re-engineering the platform — but it also means the separation is one of custody and consensus, not of capability.
The enforceable regulated-versus-unregulated distinction is applied per federation, not per deployment: a federation is explicitly marked as regulated, which forces its actions through a real manual approval gate rather than an automatic one. The distinction travels with the federation, wherever it is governed.
Its auditor nodes
Each governance mesh is mirrored 1:1 by its own independent ChubbyChecker auditor tier — seven nodes watching seven, in the same 4/3 shape, sharing none of the workload’s infrastructure. Both governance domains have one; neither audits the other.
That sizing is the platform’s standard discipline rather than special treatment: auditor tiers are provisioned against the layer they watch, not to a fixed number. What the governance tier specifically re-derives is whether the recorded outcome of a decision can be reproduced from the votes underneath it. A resolved tally that cannot be replayed from its own vote history is a forged decision, and it is detectable without trusting the mesh that recorded it.
This is the check that matters most here, because governance failures do not look like outages. They look like a perfectly healthy system enforcing a rule nobody legitimately approved.
Where it sits
The meta-federation is in the transaction path. Although company business processes, if they are external transactions, have a separate attestation pathway, they do wait on the meta federation to coordinate non-automatic transactions. It sits above the working layers, in the authority path, in the same way the National Registry sits beside them.
The two are complementary and deliberately separate:
- The National Registry answers who is this party, where do they legally sit, and who may stop them — identity, jurisdiction, standing.
- The Meta-Federation answers what are the rules, which version is in force, and who approved it — policy, versioning, consent.
Keeping them apart is what stops a single compromise from being decisive. Forging a rule change requires the governance mesh; forging the authority to make it requires the registry; and each is watched by an auditor tier (Chubby Checkers) that shares nothing with the other. An attacker needs to be right in two independent places at once, and consistent between them, without either auditor noticing the intermediate state.
Why governance needs consensus
The objection is the same one levelled at the registry: this is heavy machinery for what most systems implement as a config repository and a code review. And the answer is the same in shape but sharper in consequence.
A rule change is not valuable because it is stored. It is valuable because every node below will enforce it faithfully, without re-deriving whether it should. That is exactly the property worth attacking — and a conventional pipeline offers a privileged path to it: a merge, a hotfix, an emergency deploy, each of which can move faster than anybody’s ability to notice.
Putting the decision in consensus removes that path. A rule change becomes a transaction in a block: ordered, agreed by seven independent nodes, replayable by anyone holding the history, and re-derived by seven more that gain nothing from agreeing. A regulator’s refusal becomes a recorded act with a tally that can be replayed, not an email somebody has to be trusted to have acted on.
The meta-federation does not make the platform run. It makes the platform’s rules something you can hold somebody to.
See also the companion documents on the National Registry, for the identity and jurisdiction records these decisions are checked against, and on the Merkle Funnel, for how the resulting history is anchored beyond the operator’s reach.
Contact: john@itotchaincloud.com.au
Tx-Rails — Built by IT/OT Chain & Cloud Australia (ITOTCCA). Sydney · London.