Domestic Transactions:-
Each of the above Shapes can transact in one of two ways: For transactions requiring strict atomicity the Genuine 2 Phase Commit (2PC) method is used, with, for transactions within one Tower’s or Shape’s Pyramid, a Coordinator. For all 2PC transactions the outcome is either Commit Success or Atomic Rollback. 2 PC transactions (Regime A) are not available for interactions outside a single Pyramid.
The second possible means of transacting domestically between federations involves Coordination in a process called a Saga which uses Suspense Accounts. Saga transactions are coordinated by a country’s national-meta-federation (extra-Tower) or a local intra-meta-federation (intra-Tower), for Tower-sided transactions, and they use National Aggregators as coordinators for non-Tower (Shapes 1, 2 and 3) cases. A Saga transaction is either completed or compensated.
The above 2 transaction modes can be triggered in one of two ways. For transactions requiring manual initiation the transfer is possible using the 2PC method when atomicity is required and available, or, for transactions with less strict requirements or for domestic/inter-pyramid, the Saga method is employed. The second triggering method is via IIoT devices in connection with Smart Contracts, where there are dangers inherent in using the Saga method, such that this mechanism is unavailable for IIoT/Smart Contract transfers (due to insurmountable complications when a Saga transaction must be reversed/compensated). In all Smart Contract/IIoT trades the 2PC mechanism must be employed.
International Trade:-
A “pseudo-Saga” mechanism is used here, with mutual mediation achieved via the agreed Anchor (DLT) Interface.
_____________________
Shape we will NOT ship — single global pyramid
One pyramid serving energy across UK + AU + EU + US. Jurisdictional sovereignty collapses; data sits where it must not sit under GDPR / state-data-protection law; a single legal action against the pyramid operator pauses the global energy substrate. Off the table — we do not pitch or build this configuration.
_______________________________
What this gives up (summary across shapes)
- Per-federation cost is higher than a multi-tenant alternative under Shape 1. A small / low-volume federation (e.g. early-stage carbon-renewables registry) gets the same 4-VM footprint as a heavily-used wholesale-market federation. Shape 2 (grouped pyramids) is the standard answer to this; Shape 3 is the explicit budget answer when even Shape 2 is too much.
- Inter-federation transactions across pyramids are not free. Cross-pyramid flows require one of the five mechanisms below (§2). The mechanisms apply equally to Shape 1 and Shape 2 — they govern cross-pyramid flow, not cross-federation flow. Within-pyramid cross-federation flows in Shape 2 are free.
Commercial framing
We lead with “your own pyramid, your own enterprise validators, your own trust boundary” (Shape 1) as the premium offering. At full scale most customers will land on Shape 2 (grouped pyramids by trust cluster) — we don’t bury this; we present it explicitly as the realistic operating shape and price it accordingly. Shape 3 (single jurisdictional pyramid) is the explicit budget tier, available on request with the substrate work above completed.
The sales conversation is therefore:
- “Your range of federations = their own independent 8 VMs each = your own pyramid” (Tower Shape, specialist pitch, premium plus pricing)
- “Your federation = your own pyramid” (Shape 1, default pitch, premium pricing)
- “As you add federations, we cluster them by trust domain so you’re not paying for 4 VMs per federation forever” (Shape 2, full-scale operating shape, mid-tier pricing)
- “For a single-jurisdiction pilot or a small-scale test, one pyramid carries the whole vertical” (Shape 3, budget/pilot tier, lowest pricing)
The substrate supports all four. Customers choose by trust trade-off + budget — and can migrate between shapes (Shape 3 → Shape 2 → Shape 1 → Tower) as their scale + regulatory demands grow.
_______________________________
2. The inter-federation trade problem
I. First Design Pass
Most non-trivial energy-sector flows (for example) cross federation boundaries:
Inter-Sector trade is also possible, and we allow for it
- Wholesale settlement — market-ops clears → retail settles → metering verifies → payments transfers (4 federations).
- Guarantee-of-origin lifecycle — generation issues → carbon-renewables registers → retail claims for green-tariff → audit-compliance verifies (4 federations).
- Flexibility dispatch — DER-microgrids offers → flexibility clears → distribution instructs → generation responds (4 federations).
- Insurance claim — iot-scada / weather-geo detects → insurance triggers → payments settles (3 federations).
- Regulatory disclosure — almost every operational federation → audit-compliance + authorities.
_____________________________________________
Cross-federation trade is the rule for most non-trivial flows, not the exception. A pyramid can ship today and run its within-federation flows end-to-end without any cross-pyramid mechanism in place; cross-pyramid flows (including Inter-Sector, Inter Data Centre and International flows) are also currently possible inside tx-rails, via legacy RPC.
The eight cross-pyramid mechanisms we will implement, in order of priority:
_______________________________
Mechanism 1 — Cryptographic handoff via Hedera anchor (default, v2)
Pattern: Pyramid A commits an event, anchors its slab to Hedera Consensus Service every 24 blocks. Pyramid B subscribes to Hedera, sees the anchored event, verifies its inclusion in A’s Merkle root, and creates the corresponding event in B’s own state machine.
Trust properties:
– One-way, asynchronous.
– B does not have to trust A — B verifies the Hedera anchor + the Merkle inclusion proof.
– A’s compromise cannot inject events into B unless A’s BFT mesh + the Anchor + the Merkle proof all collude (i.e. A’s compromise is total + Hedera is compromised + the Merkle proof verification logic in B is broken). Three independent attack surfaces.
Latency: Bounded by slab cadence (every 24 blocks ≈ 2–4 minutes in current PoC sizing) + Hedera consensus (~3 seconds) + B’s poll interval. End-to-end ≈ 5 minutes worst-case for a slab-to-slab handoff. Acceptable for the majority of energy flows (settlement is T+1 anyway, GO transfer is T+5 to T+30 minutes in existing markets).
Substrate state: the emitting side is production-grade — the slab-Merkle producer and the Hedera anchor outbox feed a real Hiero-SDK submitter (live TopicMessageSubmitTransaction), with a Vault-based operator signer and Mirror-Node verification (the file-stub submitter is now only a no-credentials PoC fallback). The previously-missing receiving side is now scaffolded: a Mirror-Node subscriber observes peer pyramids’ anchored slab roots and registers each through consensus (the RegisterExternalAnchor action), so every aggregator replica trusts the identical root set; the saga’s proof-carrying Verify gate then accepts cross-pyramid Merkle-inclusion proofs against those roots. Remaining: validating the on-wire anchor-message format against the live submitter, and the per-federation event-of-interest dispatch. This Mechanism is one way for Pyraamids in a Tower Shape to transact.
When this is enough:
– Guarantee-of-origin transfer between generation → carbon-renewables → retail (T+5–30 min latency tolerable).
– Disclosure event handoff (operational federation → audit-compliance / authorities).
– Settlement notification between market-ops → payments → counterparty federations (T+1 settlement is the baseline).
– ~80% of energy inter-federation flows.
When this is not enough:
– Real-time dispatch (sub-second wholesale balancing) — see Mechanism 2.
– Atomic balance updates across two ledgers (settlement-payment ↔ counterparty-balance in the same instant) — see Mechanism 2.
Implementation plan:
– v2 stage 1 (DONE): Phase 2 Hedera SDK landed — the real Hiero-SDK submitter + Vault signer + Mirror-Node verification replaced the file-stub on the emit side.
– v2 stage 2 (scaffolded): Cross-pyramid subscriber framework — the Mirror-Node root subscriber + RegisterExternalAnchor consensus action are in place. Per-federation config (which peer topics to subscribe to, which event types to filter for, which local action to dispatch on receipt) and the on-wire format validation remain.
– v2 stage 3: Reference cross-federation flow: GO issuance in generation → registration in carbon-renewables. End-to-end test with two pyramids on one demo cluster. Production-ready handoff for the carbon-renewables charter customer.
Engineering estimate: Phase 2 (SDK swap) ≈ 2 weeks. Subscriber framework ≈ 4–6 weeks. Reference flow ≈ 2 weeks. Total ≈ 8–10 weeks from v1 (substrate ship) to v2 stage 3 (first production cross-federation flow).
Mechanism 2 — Intra-Sector/Data-Centre Coordinated two-phase commit (2PC, v3)
Implementation status (2026-06-12): genuine 2PC (Option 1) is now implemented for intra-sector cross-pyramid commits, with the shared sector aggregator as the BFT-replicated Coordinator (aggd/internal/twopc: coordinator + participant + driver + in-doubt resolution). The coordinator’s logged decision is the commit point and is BFT-committed via the Begin2PC / RecordVote2PC consensus actions — every aggregator replica derives the identical decision from the same votes, so no single replica can equivocate; presumed-abort is driven by the consensus block time. Safety (no-split, validity, decision finality, in-doubt convergence, conservation) is covered by unit tests + an ~8M-exec no-split fuzz (see docs/cross-pyramid-saga-test-plan.md §2.5). It coexists with the Option-2 Saga mechanism: 2PC is the synchronous-atomic path for the high-value flows that need it, while Saga remains the default for latency-sensitive / asynchronous flows. Remaining before production: the participant Prepare/Commit/Abort cross-mesh transport to the pyramids, and a durable decision log for in-doubt recovery after an aggregator restart. Trade-off: 2PC reintroduces participant resource-locking + in-doubt blocking (an IIoT latency hazard); the BFT coordinator removes coordinator-failure blocking, not participant blocking.
Pattern: Option 1: In this “2PC” (two-phase commit) design, both pyramids prepare a transaction. Both pyramids return prepared-vote. The national aggregator coordinator issues commit.
Option 2: In the alternative, IIoT-UNsafe design employing the Aggregator/Auditor shared between Pyramids in their nation, as Saga Coordinator, the transaction on both initiator and counter party Pyramids is visible (as Metadata). Note that this preferred (aggregator-coordinated) design is a saga, not synchronous 2PC: the transfer reaches one of three terminal states — committed, compensated, or expired — with value conserved by double-entry at every step (initiator → suspense → counterparty on success; suspense → initiator on compensation/expiry). Atomicity is of-outcome (settle-or-compensate), not a synchronous two-phase commit across the meshes, as found in Option1. Option 1 (a genuine 2PC) remains the fallback only if the national-aggregator saga proves insufficient (ie the transaction absolutely requires Atomicity).
Trust properties:
– Stronger settlement guarantee than Mechanism 1: the transfer either settles to the counterparty or is compensated back to the initiator — value is never stranded in suspense. (This is saga atomicity-of-outcome, not synchronous cross-mesh 2PC.). For option 1 the transaction is either successfully committed or it is aborted
– Higher complexity: requires a coordinator that does not become a single point of trust failure. Production design uses the shared aggregator for both options (Mechanism 3, option 1) or the common Aggregator (Mechanism 3 option 2) as the coordinator, with cryptographic prepare-receipts on both sides so the aggregator cannot equivocate without detection, in the case of Option 1, or where the shared Aggregator/Auditor in Saga-mode settles both the initiating party and the counter party as a single audited outcome (settle-or-compensate saga, not synchronous 2PC).
Latency: Bounded by the longest-path BFT round in either pyramid (~1–2 s in PoC sizing) (+ coordinator round-trip for Option 1). End-to-end ≈ 3–5 seconds. Less than this for Option 2.
Trust caveat: Our design addresses the single-point-of-trust by making the coordinator a BFT-replicated aggregator whose decision is consensus-committed (so no single replica can equivocate) — the implemented twopc coordinator above. The decision being BFT-held also means an in-doubt participant can recover it from any replica. The one piece still owed before production is the participant cross-mesh transport; until that lands, 2PC is exercised only via the in-process test harness, and the Option-2 saga remains the shipping path.
When this is required:
– Real-time wholesale-market clearing where bid + clearing-price + dispatch must commit atomically (energy market-ops → generation).
– Settlement payment + counterparty-balance must update in the same instant (payments → counterparty federations).
– Cross-federation balance transfers (insurance → payments).
– ~15% of energy inter-federation flows — but high-value ones.
Implementation plan:
– v3 stage 1: Production design document. Survey existing BFT-2PC literature (HotStuff, PBFT-2PC extensions, optimistic-rollup commit patterns). Decide on the design — possibly two-phase optimistic-commit with Hedera-anchored fraud proofs.
– v3 stage 2: Reference 2PC implementation between two meshes in the same pyramid first (lower risk; same controller, same BFT layer).
– v3 stage 3: Cross-pyramid 2PC. Reference flow: wholesale-clearing across market-ops + generation. End-to-end production-ready by v3 ship.
Engineering estimate: Design ≈ 4 weeks. Implementation ≈ 12–16 weeks. Hardening + testing ≈ 6–8 weeks. Total ≈ 6–8 months from v2 ship to v3 ship.
-
- Pattern: – 2PC coordinatorThe coordinator role that issues commit/abort decisions for cross-pyramid atomic transactions is taken by the shared Aggregators alonngside the alternative IIoT-safe 2PC pattern, also implemented in the shared Aggregators. Coordinator decisions are themselves BFT-committed inside Aggregator, so a faulty aggregator cannot equivocate.
– Dispute resolution — when two federations disagree on the meaning or status of a cross-federation event, the aggregator logs are used to arbitrate.
– Audit-window coordination — when authorities want to audit across multiple federations, the shared aggregator issues the cross-pyramid read tokens.
- Trust properties: A regular pyramid by construction — 4 meshes for a Shape-1 pyramid (member-classes / overseers + 2 auditor mirrors), or 8 for a Tower. BFT consensus + ChubbyChecker audit.
- Implementation plan:
– v2 stage 1 (concurrent with Mechanism 1): Provision the aggregator. Define its actions (RegisterFederation, UpdateFederationPolicy, IssueCrossFederationAuditToken, RecordCrossFederationDispute).
– v3: Shared Aggregators take on the 2PC coordinator roles.
- Alternative (IIoT-Safe) Pattern: With the exception of the Tower Shape, the shared Aggregators already include connections to, and knowledge of, all sector-wide events by Metadata.
- Member set: The members are exactly the consituents of the sector
- Functions:
– Federation registryChubbyChecker can be used to vet the validity of Federations-within-Pyramids. The Aggregators have access to the PyramidId and CounterPyramidId fields in Metadata. Where these fields are unequal, Aggregators can intercept the txId value of such cross-pyramid transactions and initiate the original txId retroactively, since it will be designed to be in a pending state (temporarily transacted to a “cross-pyramid” suspense account when the counter party is unreachable from the initiating pyramid).
– Cross-federation policy — rules that span federations (e.g. “no entity can simultaneously be a member of generation + market-ops in the same jurisdiction” if such a separation rule applies; “GO retirement events must be cross-verified by carbon-renewables”) can likewise be enforced by governance of the design (specialised by Vertical Sector) of an extra cross-pyramid-checks package in the Aggregator section of ChubbyChecker. No retroactive transaction from a suspense account can fire until the Sector’s cross-pyramid checks are completed successfully.
– 2PC coordinator — is not needed if the Cross-Pyramid transactions take on the employment of a Saga coordinator, so they can be designed and governed, per Vertical Sector, to take on the role that issues retroactive commit/compensate decisions for cross-pyramid transfers — a saga (settle-or-compensate), not a synchronous 2PC. Value is held in a suspense account between initiation and the terminal state, and completion is proof-carrying: the counterparty pyramid verifies the initiating tx’s Merkle inclusion + Hedera anchor and commits its own side in its own BFT mesh — the aggregator orchestrates settlement but never mints on a pyramid it does not validate. The initiating party’s transaction metadata must mirror that of the counter party. Delegated aggregator actions are themselves BFT-committed, so a single bad actor cannot equivocate. The design requires the ability for aggregators to recognise and respond to cross-pyramid transactions. The receipt of a transaction request is required..
– Dispute resolution — when two federations disagree on the meaning or status of a cross-federation event, the evidence of the shared ChubbyChecker’s and Aggregator’s logs can be used to arbitrate.
– Audit-window coordination — the audit process performed by the 4 sector-wide Virtual Machines is already in place.
- Trust properties: The aggregator’s and tophat’s 4 meshes, include BFT consensus and ChubbyChecker audit. In these transactions involving Tower-Shaped Federations, there will be a need for governance, since aggregator operations must be designed to take care of cross-pyramid transacting within the Sector’s Cross-Federation Regulations and Policies, as part of its aggregating and delegating processes.
- Trust properties: Nevertheless the 2PC option must be available as there are cases where atomic transactions are mandated (eg IIoT transactions).
- Implementation plan:
– v2 stage 1 (completed): Redesigning the aggregators. Define its new actions (RegisterFederation, UpdateFederationPolicy, Add CounterPyranidIdf, IssueCrossFederationAuditToken, RecordCrossFederationDispute).
– v2 stage 2: Charter membership (initially: ITOTCCA + 1–2 regulators + 1–2 industry bodies). Real governance votes happen here.
– v3: Aggregator/ChubbyChecker take on the 2PC coordinator role.
-
Engineering estimate: Provisioning + action surface ≈ 0 weeks (substrate is already there; work is complete). Charter membership + first real-world dispute resolution ≈ 8–12 weeks of relationship work (most of which is sales/governance, not engineering).
Mechanism 4 — Bilateral cryptographic agreements (v3)
Pattern: Two federations that frequently inter-trade pre-register each other’s anchor topics + signing keys. Inbound events from the registered partner are accepted on cryptographic verification (Mechanism 1 style) but without an additional Hedera round-trip — the receiving pyramid trusts the sending pyramid’s BFT commitment + signed anchor directly.
Trust properties:
– Faster than Mechanism 1 (skips the Hedera round-trip).
– Requires the two federations to have a written bilateral agreement, signed by their governance bodies through the meta-federation.
– Lower trust-isolation than Mechanism 1 — if A’s BFT mesh is compromised, A can inject bad events into B without the Hedera anchor as a backstop. Reserved for pairs where the two federations explicitly accept this lower bar in exchange for latency.
When this is appropriate:
– High-volume pairs where Hedera anchor latency is unacceptable (e.g. metering → retail in jurisdictions with sub-second billing requirements; rare today).
– Federations with overlapping membership where the trust gap is already low (e.g. retail + EV-charging where the same retailers participate in both).
– ~5% of energy inter-federation flows.
Implementation plan:
– v3 stage 4 (after 2PC ships): Bilateral-agreement registration in meta-federation. Per-pair pre-shared keys + topic subscriptions. Reference bilateral: metering ↔ retail.
Engineering estimate: 4–6 weeks once Mechanism 1 + 3 are in production.
This Mechanism represents the second method (after Mechanism 1) for inter-Pyramid trade for Tower Shaped Pyramids.
A final Mechanism to achieve atomicity (IIoT-safe) for inter-Pyramid trading in the case of Tower Shapes, is to establish a Meta-Federation and to implemnent Genuine 2PC using the Meta Federation as Coordinator. The same Meta Federation can be used to implement the complementary Saga pattern to provide an atomicity-non-critical inter-Pyramid transaction. The Tower Shape is the only case requiring a Meta Federation in this way, whereas non-Tower trade within ITOTCCA networks employs National Aggregators which stream metadata from all underlays/substrates. None of this data is strategic. See 31 Metadata Fields.
_______________________________
Mechanism 5 Intra- and Inter-Sector Transactions, Within or Between Data-Centres, via National Aggregator layer as coordinator
- Option 1a: Genuine Coordinated two-phase commit NOT involving IIoT devices and Smart Contracts. This option will be implemented in a similar way to Mechanism 2/3 Option 1, but will be conducted for defined transactions (internal to ITOTCCA networks) via an automatic multi-party voting mechanism, which will need to include a general right-to-veto a transaction. This will normally mean, in an M-sided transaction, either M parties agree or the transaction fails. However, where possible, an N-of-M arrangement is feasible. Automatic coordination is thus possiblle via the National Shared Aggregators. “Manual” operation becomes effective with the inclusion of regulators with veto rights in otherwise automatic transactions.
- Option 1b: Genuine Coordinated two-phase commit involving IIoT devices and Smart Contracts. This option will be implemented in a similar way to Mechanism 2/3 Option 1, but will be conducted for IIoT transactions via the automated international IOTA blockchain. The occurrence of an event will be determined by reference to IOTA. Depending on the nature of the event, different outcomes will be produced. This will generally mean, in an M-sided transaction, if N-of-M parties agree then the transaction proceeds. Specification of N = M is supported, as is the participation of regulators as in 1a. IIoT transactions must be 2PC transactions (genuine two-phase commit). As such, all parties will be required to issue “Vote Prepared” notices and must use their Nationa’s Aggregator to coordinate, which then attempts to atomically commit the transaction. The transaction will be rolled back in this same process if it fails.
- Option 2: Saga Transactions. This option will be implemented in a similar way to Mechanism 2/3 Option 2, but will be conducted for defined transactions via an automatic multi-party voting mechanism, which will need to include a general right-to-veto a transaction. This will normally mean, in an M-sided transaction, either M parties agree or the transaction fails. However, where allowed, an N-of-M arrangement is feasible, with regulation included. The National Aggregator may be used.
- Option 3: External (to ITOTCCA networks) Transactions. For this option we make provision for a Mechanism 1 (Hedera) transfer.
- These plans for a National Intra- and Inter-Sector Aggregator/Tophats/Auditor installation have already been completed. They include connection to metaadata from all (non-Towwer) Underlays/Substrates in a country, and therefore have meta-knowledge of, all nation-wide events via the transactions’ Metadata. None of the accessible metadata constitutes strategic information.
- Member set: The members are exactly the consituents of all national customer sectors
- Functions:
– Federation registryThe National ChubbyChecker can be used to vet the validity of Federations-within-Pyramids, Pyramids-within-Sectors and Sectors-within-nations. The Aggregators have access to the PyramidId, CounterPyramidId, SectorId, CounterSectorId, DataCentre, CounterDataCentre, Country and CounterCountry Id fields in all Metadata. Where the SectorId and CounterSectorId fields are unequal, AND Country and CounterCountry Ids are equal AND regardless of equality or inequality of DataCentre and CounterDataCentre Ids, Aggregators can intercept (upon request) the initiating txId value of such intra- and cross-sector transactions and activate the original txId retroactively, if a Saga, since it will be designed to be in a pending state (temporarily transacted to a “cross-sector-cross-data-centre” suspense account or to a “cross-sector-intra-data-centre” account (depending on the status of DataCentre and CounterDataCentre) when the counter party is unreachable from the responsible intra-Sector (Cross-Pyramid) Aggregator when it tries to retroactively action the initiating transaction – see Mechanism 3 Option 2 above – the Alternative Pattern. The case of Intra-Sector Cross-Data-Centre flows is similar with unreachable transaction targets posted instead to the “intra-sector-cross-data-centre” suspense account at the National Data Centre.
– Cross-federation, Cross-sector and/or Cross-Data-Centre policy — rules that span federations, sectors and Centres can likewise be enforced by governance of the design (specialised by Vertical Sector-Pairs) of an extra cross-centre-checks package in the National Aggregator section of ChubbyChecker. No intra- or inter-sector retroactive transaction from a suspense account can fire until the Centre Pair’s cross-sector or intra-sector checks are completed successfully.
– The National Aggregators will need to act as 2PC coordinators when demanded so they must be able to recognise an explicit requirement for 2PC, request the “Vote Prepared” acknowledgement and initiate an atomic commit, being prepared to roll back in a single action if the transaction fails. The initiating party’s transaction metadata must mirror that of the counter party. An additional set of ChubbyChecker cross-checks must be applied, when appropriate, per Sector-Pair, such that in the marginally delayed commitment process, the aggregators/auditors would post-process the cross-sector transactions, including dual post transaction checks of both initiating and counter party sides. There is a similar dimension required for cross-data-centre components. Delegated aggregator actions are themselves BFT-committed, so a single bad actor cannot equivocate. The design requires the ability for aggregators to recognise and respond to national cross-centre and/or cross-sector transactions. In the first stage this recognition will manifest as an explicit transaction request (received manually or semi-automatically if a Tower-sided tx) for coordination at the national Aggtrgator (National-Meta-Federation for Towers).
– Dispute resolution — when two federations disagree on the meaning or status of a cross-centre event, the evidence of the shared ChubbyChecker’s and Aggregator’s logs can be used to arbitrate.
– Audit-window coordination — the audit process performed by the 4 cross-sector Virtual Machines is already in place.
- Trust properties: The aggregator’s and tophat’s 4 meshes, include BFT consensus and ChubbyChecker audit. There will be a need for governance, at least in the coding process, since aggregator operations must be designed to take care of cross-sector and cross-centre transacting within Regulations and Policies, as part of its aggregating and delegating processes.
- Implementation plan:
– v4 stage 1 Designing the cross-sector/cross-centre aggregator. Define its new actions.
– v4 stage 2: Charter membership (initially: ITOTCCA + several regulators + relevant industry bodies). Real governance votes happen here.
– v5: National Aggregator/ChubbyChecker takes on the 2PC coordinator role.
Engineering estimate: Provisioning + action surface ≈ 8 weeks (substrate is already there). Charter membership + first real-world dispute resolution ≈ 12-16 weeks of relationship work (most of which is sales/governance, not engineering).
Mechanism 6 Intra- and Inter-Sector, International Transactions
- Option 1a: Genuine Coordinated two-phase commit NOT involving IIoT devices and Smart Contracts and NOT involving banks (ie internal transactions). This option will be implemented in a similar way to Mechanism 2/3 Option 1, but will be conducted for defined transactions via a regulated, semi-automated or automatic international voting mechanism, which will need to include a general right-to-veto a transaction. This will normally mean, in an M-sided transaction, either M parties agree or the transaction fails. However, where possible, an N-of-M arrangement is feasible. Automatic coordination is also possiblle. In both automated and regulated arrangements, a leading-nation-coorfinator must be elected.
- Option 1b: Genuine Coordinated two-phase commit involving IIoT devices and Smart Contracts but not involving banks (ie External Transactions). This option will be implemented in a similar way to Mechanism 2/3 Option 1, but will be conducted for IIoT transactions via the automated international IOTA blockchain. The occurrence of an event will be determined by reference to IOTA. Depending on the nature of the event, different outcomes will be produced. This will generally mean, in an M-sided transaction, if N-of-M parties agree the transaction proceeds. Specification of N = M is supported. Transactions of this type must be 2PC transactions (genuine two-phase commit). As such, whether regulated or automatic, all transacting parties will be required to issue “Vote Prepared” notices and must already have elected a leading-nation-coordinator which then attempts to atomically commit the transaction. The transaction will be rolled back in this same process if it fails.
- Option 2: Internal (NOT involving banks) Saga Transactions. This option will be implemented in a similar way to Mechanism 2/3 Option 2, but will be conducted for defined transactions via a regulated international voting mechanism, which will need to include a general right-to-veto a transaction. This will normally mean, in an M-sided transaction, either M parties agree or the transaction fails. However, where allowed, an N-of-M arrangement is feasible. Automatic coordination is also possiblle. In both automated and regulated arrangements, a leading-nation-coorfinator must be elected.
- Option 3:All External (involving banks) Transactions. This option will be implemented in a similar way to Mechanism 1, relying on the Trust provided by Hedera (Hiero) Decentralised Ledger Technology.
- Functions:
– Federation registryThe Global Intra- and Inter-Sector ChubbyChecker are used to vet the validity of Federations-within-Pyramids, Pyramids-within-Sectors and Sectors-Globally. The Aggregators have access to the PyramidId, CounterPyramidId, SectorId, CounterSectorId, DataCentre, CounterDataCentre, Country and CounterCountry fields in all Metadata. In the case of Sagas, where the SectorId and CounterSectorId fields are either equal or unequal, and the Country and CounterCountry Ids are different, (contingent upon the Aggregator receiving a request to make a Saga transaction), Aggregators can intercept the initiating txId value of such intra- and cross-sector transactions and action the original txId retroactively, since it is designed to be in a pending state (temporarily transacted to an “intra-sector-international” suspense account or an “inter-sector-international” suspense account (London-based) when the counter party is unreachable from the responsible intra- or inter-Sector Aggregator as it tries to retroactively action the initiating cross-pyramid transaction – see Mechanism 3 Option 2 above – the Alternative Pattern.
– Cross-federation International policy — rules that span federations and countries can likewise be enforced by governance of the design (specialised by Nation-Pairs) of an extra cross-sector-checks package in the Intra-Sector International Aggregator section of ChubbyChecker. No international retroactive transaction from a suspense account can fire until the Nation Pair’s intra-sector or inter-sector checks are completed successfully.
– 2PC coordinator and Saga coordinator — these roles both require that Cross-Nation transactors are able to participate in elections of leading-nation-coordinators. The actions of the Delegated National Aggregator actions, on all sides, are themselves BFT-committed, so a single bad actor cannot equivocate. The design requires the ability for national aggregators to recognise and respond to cross-nation transaction requests.
– Dispute resolution — when two federations disagree on the meaning or status of a cross-sector event, the evidence of the shared ChubbyChecker’s and Aggregator’s logs can be used to arbitrate.
– Audit-window coordination — the audit process performed by the 4 cross-sector Virtual Machines is already in place.
- Trust properties: The aggregator’s and tophat’s 4 meshes, include BFT consensus and ChubbyChecker audit. For prescribed transactions there will be a need for governance, since aggregator operations must be designed to take care of intra-sector transacting within the Data Centre’s International Regulations and Policies, as part of its voting, aggregating and delegating processes.
- Implementation plan:
– v5 stage 1 Designing the international actions of national aggregators. Define their new actions.
– v5 stage 2: Charter membership (initially: ITOTCCA + several regulators + relevant industry bodies). Real governance votes happen here.
– v6: Aggregator/ChubbyChecker takes on the 2PC and Saga elector roles.
– v6: Aggregator/ChubbyChecker takes on the 2PC and Saga leadership roles if/when elected.
Engineering estimate: Provisioning + action surface ≈ 8 weeks (substrate is already there). Charter membership + first real-world dispute resolution ≈ 12-16 weeks of relationship work (most of which is sales/governance, not engineering).
This mechanism involves the usually Manual (human-governed) versions of the above Saga and 2PC transaction types, when necessary as part of intra-Tower cross-Pyramid transactions. Provision is made for automated and semi-automated classes.
- Option 1 (2PC) and Option 2 (Saga): These options will be implemented in similar ways to Mechanism 2/3 Options 1 and 2, but we define a National-Meta-Federation of all National Tower-Shaped federations that will play the role of coordinator in all trading cases involving Tower Shapes on either or both sides, with the exception of intra-Tower trade.
- That is to say all trade internal to ITOTCCA’s networks that is not internal to a Tower and that involves Tower-Shaped Sectors will pass through this type of Federation as Coordinator, and (for internal trade) will involve the election of a leading National-Meta-Federation, in the case of international trade.
- Option 3: “External” Transactions (involving banks): These options will be implemented according to the guidelines of Mechanism 1.
- All trade external to ITOTCCA’s networks could pass through this type of Federation as Participant with other external parties, and could involve the use of Mechanism 1 in the cases of domestic and international trade.
- That is to say all trade internal to ITOTCCA’s networks, but not internal to a Tower that involves Tower-Shaped Pyramids could pass through this type of Federation as Coordinator, and would then involve the election of a leading National-Meta-Federation, in the case of international trade.
Engineering estimate: Provisioning + action surface ≈ 8 weeks (substrate is already there). Charter membership + first real-world dispute resolution ≈ 12-16 weeks of relationship work (most of which is sales/governance, not engineering).
_______________________________
_________________________________________________________
_______________________________
2. The inter-federation trade problem
II. Second Design Pass
The (new) three cross-pyramid mechanisms (reduced from Pass I’s 8 Mechanisms) we will implement:
Status: proposed (supersedes the M1→M8 escalation ladder in tx-rails/docs/federation-trust-model-NEW.html for the cross-federation transaction model). Date: 2026-06-30.
Context: Decided after a critical review of the road to “8 mechanisms working.” The core realization: a machinic voting system (BFT) is unsafe and infeasible internationally — both technically (BFT is O(n²), needs a bounded validator set + partial synchrony) and politically (no shared trust domain across sovereigns; the number of nations far exceeds any super-connected BFT). The 8-mechanism ladder has the wrong polarity.
A. The principle: invert the ladder
Consensus strength must decrease as transaction scope widens — not increase. The old ladder implied more coordination/voting as you go international; that is exactly backwards.
- intra-pyramid / tower → FULL BFT + 2PC (synchronous atomicity)
- domestic cross-sector → SAGA (eventual + compensation) — single sovereign
- international → ANCHOR + BILATERAL (ordering only) — no voting
Three regimes (the 8 mechanisms collapse to these)
| Regime |
Scope |
Protocol |
Coordinator |
Old mechanisms |
A — Atomic
|
intra-pyramid, intra-tower (one trust domain, low latency) |
2PC over BFT |
local (pyramid) – Nat. Aggregator/
Intra Meta-Fed (tower) |
M2, M3, M7 |
B — Orchestrated
|
domestic cross-sector / cross-data-centre (one sovereign) |
Saga (compensation, no locks) |
National Meta Fed/
National Aggregator/
(1/country) |
M5 — re-cast as Saga, not 2PC |
C — Peered
|
international (no shared trust domain) |
anchor + bilateral agreement
+ Saga compensation |
none —
mesh of National-Aggregator/
National Meta Fed peers |
M1 + M4 |
Why 2PC only in Regime A: 2PC is a blocking protocol — a coordinator crash after prepare leaves participants holding locks indefinitely. That is tolerable only co-located within one operator/trust domain. Across operators, data-centres, or borders it is actively unsafe; use Saga.
C. Mechanism disposition
- Keep: M1 (anchor handoff), M2 (intra 2PC), M3/M7 (meta-fed coordination of tower 2PC/Saga), M4 (bilateral cryptographic agreements).
- Re-cast: M5 (national aggregator) — domestic cross-sector via Saga, not 2PC. The supervening one-per-country national aggregator orchestrates; it does not BFT-vote across sectors.
- Collapse: M6 (international/global aggregator-as-coordinator) → bilateral peering between national aggregators via anchor (M1) + agreement (M4). There is no international coordinator.
- DELETE: M8 (super-meta-federation as BFT coordinator). Doomed — BFT cannot span nations technically or politically. Do not build it.
International settlement is therefore a mesh of bilateral relationships between sovereign national aggregators, not a hub and not a global validator set. This is identical to the previously-favoured 2-plane design (national aggregator per country, no intermediates) — the two analyses converge.
D. Anchor 
is an interface, not Hedera 
Hedera as the international anchor reintroduces a trust dependency (a ~30-member council under aBFT; a permissioned ordering service) — a weaker form of the “whose validators?” problem, outsourced. Mitigate by abstraction:
- Define an
OrderingAnchor interface: Anchor(root) → (orderedReceipt, timestamp, proof) + Verify(receipt). It provides non-repudiable ordering / notarization only — it does not vote on validity.
- Hedera is one implementation. Business logic depends on the interface, never on Hedera directly, so a council-governance or availability event is not an international-settlement outage.
- Validity in Regime C comes from the bilateral cryptographic agreement (M4), not from the anchor.
Implemented: the-situation/internal/anchor (interface + ed25519 in-memory ref impl) and internal/anchor/hcs (Hedera Consensus Service impl).
E. Open questions — MUST be answered before any transaction code / proto
- Atomicity claim for Regime C. Anchor + bilateral gives non-repudiable ordering and agreement, not atomic settlement. Specify the exact guarantee and the compensation/timeout state machine (one side anchors, the other never does → timeout → compensate). See
REGIME-C-STATE-MACHINE.html.
transactions/v1 proto shape (the currently-missing gen package national-meta-federation imports). It must encode the regime — likely distinct message sets for Regime A (2PC coordinator) vs Regime C (anchor/bilateral), or a unified envelope with a regime discriminator. Do not generate it until this is decided — the wire format is the most expensive thing to get wrong.- Saga compensation registry (Regimes B & C): where compensations are declared, how they are triggered, idempotency under retry/partition.
F. Known liabilities (block trust until resolved)
- cometbft v0.38-vs-v1 alias shim (
goldbftd/abci/types/compat_v1_aliases.go): app targets v1 ABCI semantics; fork is v0.38.19. The alias makes it compile but masks possible semantic drift in the consensus layer Regime A depends on entirely. Resolve by a real version decision before building settlement on it.
- ~105 nested tower/federation copies still on pre-normalization module paths; their standalone builds diverge from the workspace.
- Nothing in the current build has been runtime- or property-tested at the settlement level. “Builds” ≠ “atomic under partition.”
G. Action
- Update
federation-trust-model-NEW.html (the ratified doc) to this 3-regime model: delete M8, re-cast M5 as Saga, collapse M6 into bilateral peering, mark the anchor as an interface. (Done — supersession banner inserted.)
- Do not write transaction wire code until §5 is pinned.
_____________________
3. IIoT & Internal-DB Smart-Contract Origination
Status: design note. Companion to TRANSACTION-MODEL-DECISION.html (regimes A/B/C) and the regime engines in internal/regimea(BFT)/regimeb/regimec.
Thesis: internal-DB smart contracts and IIoT devices are not a fourth regime. They are the origination layer — autonomous, machine-driven producers of transactions that then flow through whichever of Regime A / B / C the transaction’s scope demands.
A. What “internal database-based smart contracts” are
Not EVM/external-chain contracts. A contract here is a business process authored in the gov/Governor studio (BPDI): a set of steps, transitions, and bindings. It executes as deterministic atoms (the Action.Execute(ctx, db, config, actionCtx) interface in orgnodes-core/abci/actions) directly against the BFT-replicated SQL state, inside FinalizeBlock. Determinism across replicas is enforced by construction (BFT-consensused BlockTime, deterministic generate_record_id() — see SCHEMA_RULES); there is no separate VM.
B. Contracts and IIoT are originators, not a regime
A contract atom (or an IIoT device event) originates a settlement transaction. Where that transaction goes is decided by scope, exactly as for human-initiated flows:
- atom touches only its own pyramid’s DB → Regime A (intra, BFT-atomic).
- atom’s process spans domestic sectors/data-centres → Regime B (national-aggregator Saga).
- atom triggers a cross-border transfer → it originates a Regime C Intent (anchor + bilateral).
C. The key seam: a contract atom IS a Regime-B Step
The Regime-B Step interface (Execute + Compensate, both idempotent) is exactly the shape of a BPDI atom plus its declared reversal. So the Regime-B engine already built is the cross-sector smart-contract runtime: a multi-sector contract is a Saga whose steps are its atoms and whose compensations are the atoms’ declared reversals. No new execution model is needed — the contract’s compensating logic (authored in the studio) becomes Step.Compensate, and the orchestrator’s journal gives the contract durable, resumable execution.
D. What IIoT specifically requires
- Machine origination with identity. Device events must be DID-authenticated and signed (the per-pyramid trust list); a device’s signature authorizes a contract trigger (
StartInstance/Transition) or a Regime-C Intent, just as a human governor’s would.
- Determinism. Because atoms execute in BFT, an IIoT-triggered atom must consume the consensused inputs (BlockTime, ContextData), never a device’s wall clock or a raw sensor read at execution time — the reading must be an input carried in the transaction, not fetched during execution. This is the same determinism rule that makes the contract safe to replicate and its output auditable.
- Throughput. IIoT is high-volume. Anchoring every cross-border event individually to Hedera (Regime C) is cost/latency-prohibitive (REGIME-C-STATE-MACHINE.html §8 #2). The answer is batched anchoring: accumulate many roots, anchor a single Merkle root per batch, and issue per-root receipts carrying a Merkle inclusion proof. This preserves the
OrderingAnchor abstraction while amortizing cost across thousands of device events.
E. Concrete code seams (to build)
- BPDI-atom ↔
regimeb.Step adapter — wrap an actions.Action + its declared compensation as a Saga step, so studio-authored contracts run on the Regime-B orchestrator unchanged.
- Batching
OrderingAnchor (internal/anchor/batch) — Merkle-batch wrapper over any anchor, the IIoT throughput enabler; per-root receipts verify via inclusion proof + the batch’s underlying anchor receipt.
- Originator / trigger — a small interface for autonomous (device/contract) initiation that produces signed Intents/Sagas from events, so origination is uniform whether the source is a human governor, a contract atom, or an IIoT device.
None of these freeze a wire format; all are testable offline on MemAnchor + MemJournal.
_____________________
4. Regime C — International Settlement State Machine
(proposed, for review)
Status: design review closed 2026-07-23 — the two-sided commit predicate P (§D) is implemented and tested. Of §E’s three stated assumptions, (b) and (c) hold in code, verified; (a) — the anchor’s own consensus safety — is not, and cannot be, verified by this codebase, and stays permanent residual trust rather than a to-do (see §E’s own updated note). Formal (TLA+) verification closed 2026-07-24 (§H item 5) for the part of the no-split-brain claim this codebase actually controls — this engine’s own concurrency bookkeeping, not assumption (a) — and found and fixed a real bug in the process (a late settle could silently overwrite an already-compensated intent). Wired live 2026-07-24: RegisterAgreement/SubmitIntent/RecordIntentReceipt/RecordCommitment/GetIntentStatus are real gov-api RPCs (proto/gov/v1/gov.proto), behind an –enable-regime-c flag that’s off by default (regimec.NewProductionEngine refuses to start without live Hedera credentials). See this doc’s own §2 (Second Design Pass)..
A. What Regime C can and cannot give
- Cannot: true atomicity / simultaneity. Impossible without a trusted coordinator, which is exactly what sovereignty forbids.
- Can: “agreed-or-compensated” — every leg either completes or is provably reversed, within a bounded time τ, with a non-repudiable evidence trail sufficient for off-system (legal/regulatory) dispute resolution. Eventual consistency, not atomic commit.
The design’s whole job is to make the commit/abort decision a deterministic function of anchored, non-repudiable evidence, so both parties — and any auditor — compute the same outcome without communicating. That deterministic predicate is what replaces the coordinator.
B. Participants & pre-conditions
- NA_I, NA_C — initiator and counterparty national aggregators (one per country; Regime A/B internally).
- OrderingAnchor — neutral ordering/notarization oracle (
Anchor(root)→(seq, ts, proof), Verify). Provides a total order + non-repudiable timestamps; does not judge validity. Hedera is one impl.
- Bilateral agreement (M4) — pre-established: exchanged DIDs/keys, agreed suspense accounts on each side, timeout τ, amount/terms schema, and dispute terms. No per-tx trust is created on the fly.
- Suspense accounts — local, reversible holds on each side. The compensatable intermediate state. Funds in suspense are neither spent nor received until settlement.
C. Per-party state machine (symmetric)
Both sides run the same machine. The initiator starts at the debit transition; the counterparty enters at PREPARED on observing R_intent.
- IDLE → initiator: debit→SUSPENSE (reversible), build Intent{txid, terms, amt, cp, deadline}, Anchor →
R_intent
- PREPARED → counterparty: validate M4+terms, credit→SUSPENSE (reversible), build Commitment{txid, accept, deadline}, Anchor →
R_commit
- COMMIT_VISIBLE → both
R_intent and R_commit observed in the anchor’s total order; evaluate commit predicate P (§4)
- P true → SETTLING → SETTLED (suspense → final, on BOTH sides, deterministically)
- deadline elapses without P → EXPIRED → COMPENSATING → COMPENSATED (suspense → reverse)
- contested evidence → DISPUTED (anchored evidence escalated per M4 terms; off-system resolution)
D. The commit predicate P (the heart of it)
P(txid) ≡ there exist, in the anchor’s total order, both:
- a valid
Intent(txid) signed by NA_I, and
- a valid
Commitment(txid, accept) signed by NA_C,
each with anchor-assigned timestamp ≤ its stated deadline (use the anchor’s clock/sequence, never local clocks — this removes skew ambiguity).
- P true → both parties MUST move suspense→final.
- deadline elapses without P → both parties MUST compensate.
P is a pure function of anchored evidence, so it evaluates identically on NA_I, NA_C, and any auditor. There is no state only one party can see. Implemented and tested in the-situation/internal/regimec (Evaluate; see TestNoSplitBrain).
E. Why no split-brain (claim — challenge this)
Implementation status against these three assumptions (2026-07-23 review; updated 2026-07-29 to stop conflating (a) with a narrower guarantee it doesn’t
cover): (b) and (c) hold in code, verified. (b): P compares Receipt.Timestamp, never wall-clock, and a boundary-exact test confirms strict ≤. (c):
regimec.verifyCounterpartyAuthorship rejects any evidence claimed to be from the counterparty (whichever of Intent/Commitment that turns out to be, per-txid —
resolved by comparing the evidence’s FederationID against the Agreement’s own, since either party can initiate) unless its ed25519 signature verifies against
Agreement.CounterSigningPublicKey — a missing key, missing signature, or bad signature are hard rejections, not silent skips. (a) itself — the anchor never
forking/reordering/equivocating — is Hedera’s property, not this codebase’s, and is not something any amount of review or testing here can establish; it
remains exactly the residual trust the paragraph above names, permanently, not a status that can ever read “verified.” What IS true in code, and worth stating
precisely rather than folding into “(a) holds”: regimec.NewProductionEngine takes no anchor parameter at all — its anchor is sourced exclusively from
anchor.NewLiveFromEnv internally, which errors rather than silently falling back to MemAnchor when live Hedera credentials aren’t configured. There is no call
site where a caller could pass in MemAnchor by mistake, because there is no argument to pass one through — the same structural guarantee (c) has, not a
“remember to call the right function” convention. That closes a real, previously-open gap (“production silently ran on a fake anchor”) — but it was never, and
isn’t now, evidence that Hedera itself is safe.
.
F. Failure modes
| Failure |
Handling |
| NA_C never commits |
NA_I’s anchored deadline elapses → P false → NA_I compensates. Liveness bounded by τ. |
| NA_I crashes after both anchored |
On recovery, re-derive state from anchored receipts (idempotent, §7); P is true → settle. No ambiguity. |
| Anchor unavailable |
Cannot reach commit point → both eventually compensate on timeout. Safe (no false commit), not live. Motivates anchor fallback impls. |
| Byzantine counterparty repudiates a signed commitment |
Non-repudiation (signature + anchor) defeats it; → DISPUTED; anchored trail resolves off-system per M4. |
| Replay / double-spend |
txid + anchored total order block replay; local suspense hold blocks double-spend within a side. |
G. Non-negotiable implementation properties
- Idempotency: every transition keyed by
(txid, phase); re-processing an anchored receipt is a no-op. Required for crash recovery by re-derivation from the anchor.
- Suspense before commit: never debit/credit final state before P; only suspense holds, which are always reversible.
- Deadlines in anchor-sequence, not wall-clock.
- All evidence anchored before acted on: a side acts on
R_* only after Verify against the anchor.
H. Open questions (block coding)
- Multi-leg / N-party settlement (a chain of >2 national aggregators): does P generalise, or is it strictly bilateral with chained bilaterals? (Chained bilaterals are safer; N-party atomic is back toward the coordinator problem.) Still open. Current code is structurally bilateral-only (Agreement/Intent both hard-key a single FederationID/CounterFederationID pair) — matches this doc’s own stated Scope, so not a blocker for a first corridor, but genuinely unbuilt beyond it.
- Anchor cost/throughput: anchoring every Intent+Commitment to Hedera has per-message cost/latency. Batch roots? Per-corridor aggregation? Still open and unaddressed at the Engine layer —
RecordIntentReceipt/RecordCommitment take an already-produced receipt; batching (or not) is entirely the caller’s problem. The batching OrderingAnchor wrapper exists and is tested elsewhere in this codebase but has zero importers.
- τ selection: too short → false compensations under normal latency; too long → funds held in suspense across borders. Per-corridor parameter in M4. Partially addressed: τ is now a single, code-enforced value per Agreement (§B) rather than one each caller could pick independently — but what value to pick per corridor, and how the two parties agree on it out-of-band before registering matching Agreements on both sides, is still undecided.
- HTLC alternative for pure asset swaps: for the swap subclass (each side locks an asset), hash-time-locked contracts give stronger atomicity (preimage reveal) without an anchor. Worth a dedicated path? Probably yes for FX-style swaps; the anchored-Saga here is the general-settlement path. Still fully open — no code anywhere.
- Formal verification: the no-split-brain claim (§5) deserves a TLA+/model-checked treatment before production. This is money crossing borders. Still open. A test suite now exists that exercises the scenarios a proof would need to cover (both evidence-arrival orders, late/declined commitments, the exact-deadline boundary, cross-instance convergence from shared Store state) — useful as regression coverage and as a spec of intent, but it is example-based, not exhaustive, and is not a substitute for this item.
_______________________________
5. What this decision deliberately does NOT cover
- Federation lifecycle events (creating a new federation, retiring a federation, merging two federations). The meta-federation framework supports these but the operational runbook is TBD. Defer until v2.
- Cross-jurisdictional governance (what happens when a federation spans UK + AU and the two regulators disagree). Likely solved by separate jurisdictional pyramids of the same federation (i.e.
tx-rails-energy-generation-uk and tx-rails-energy-generation-au are distinct federations, even though they share an action surface), with Mechanism 1 handoff between them. Defer until a customer with a multi-jurisdictional footprint asks for it.
_______________________________
6. Plan Forward — Prioritised Roadmap
Status: as of 2026-06-30. Companion to TRANSACTION-MODEL-DECISION.html, REGIME-C-STATE-MACHINE.html, IIOT-SMART-CONTRACT-ORIGINATION.html, COMMERCIAL-DESIGN-PRIORITIES.html.
Where we are: all three regime engines exist and are unit-tested on an in-memory substrate — Regime A = existing BFT (goldbftd); Regime B = internal/regimeb (national-aggregator Saga); Regime C = internal/regimec (anchor + bilateral, no-split-brain). Supporting: internal/anchor (interface + ed25519 ref impl), internal/anchor/hcs (Hedera, compiles), internal/anchor/batch (IIoT throughput), orgnodes-core/abci/contractsaga (BPDI contract → Saga). Workspace: 19/21 modules build. Update, 2026-07-23: Regime C’s commit predicate is now genuinely two-sided (a real Commitment type, not just the Intent half) and counterparty-authorship is cryptographically enforced (§4.D/E) — see §4 for the current, detailed state. TLA+ modeling of Regime C’s own concurrency structure closed 2026-07-24 (internal/regimec/tla) — found and fixed a real compare-and-swap bug. Update, 2026-07-24 (later the same day): all of Phase 1 is now closed — partition/crash property tests found and fixed the same class of bug in regimeb plus a genuine double-compensation gap; multi-leg/N-party resolved as chained bilaterals; transactions/v1 turned out to already be authored, generated, and wired (aggd/internal/txservice) from work predating this session, just never reflected here. See §6’s Phase 1 section below for the detail on each.
Ordering principle: dependency-ordered, and correctness gates precede money. Nothing settles real value across borders until the verification gate (Phase 3) passes. “As far as visible” means confidence falls with phase number; Phase 4 is market-contingent.
NOW (P0) — finish the engine seams
- Originator / trigger interface — uniform, signed origination from a human governor, a contract atom, or an IIoT device, verified against the per-pyramid trust list, producing Regime-B/C transactions. The last engine seam. Done, 2026-07-24:
governance/internal/origin (validation logic) plus a new governance/internal/keyregistry package (the per-pyramid trust list, Mem+PG-backed) wired live into gov-api‘s Prepare/SubmitSagaStep/SubmitIntent — each gained origin_kind/origin_identity/origin_signature/block_time fields and enforces the Regime-A-only restriction on contract-atom/IIoT origination uniformly across all three RPCs, not just within one. origin_kind left unspecified skips the check entirely, so this was purely additive over every existing caller. RegisterOriginKey/RevokeOriginKey/ListOriginKeys manage the trust list, admin-gated the same way as SetVoterRegistry. 14 new tests.
Exit: the engine layer is feature-complete on the in-memory substrate. Met, 2026-07-24.
Phase 1 (P0) — Validate the model before freezing anything
- TLA+ / model-check the Regime-C commit predicate (no-split-brain, §4.E). This is money crossing borders. Done, 2026-07-24 (
internal/regimec/tla), for the engine’s own concurrency structure — found and fixed a real bug: Store.UpdateIntentStatus wrote unconditionally, letting a late settle silently overwrite an already-compensated intent. Does not, and cannot, verify §4.E assumption (a), the anchor’s own consensus safety — that stays Hedera’s property, not this codebase’s.
- Partition & crash property tests of
regimeb/regimec — beyond happy-path: reordering, dropped messages, mid-step crashes, idempotent replay. Done, 2026-07-24. Found and fixed two real bugs while writing them: regimeb.Journal.SetStatus had the identical unconditional-write race regimec‘s TLA+ review found (two Orchestrator instances sharing one Journal could let a stale MarkCompleted overwrite an already-COMPENSATED saga — fixed with the same compare-and-swap pattern), and RecordCompensation had no idempotency guard at all (a retry double-invoked Compensate). Also fixed both regimeb and regimec‘s Status() trusting an Engine-local cache instead of reading the store directly. Reordering, dropped-message, and repeated/concurrent-sweep coverage added to both packages.
- Resolve Regime-C multi-leg / N-party (chained bilaterals vs N-party — the latter drifts back toward a coordinator). Done, 2026-07-24: chained bilaterals — see §4.H’s own item for the detail.
- Decide & author the
transactions/v1 proto per regime, then regenerate — this is the deliberately-deferred wire format and it unblocks the national-meta-federation build (the one genuine remaining compile gap). Already done, discovered 2026-07-24: proto/transactions/v1/transactions.proto is authored (a TransactionType regime discriminator, exactly the shape asked for) and generated; national-meta-federation‘s full workspace build is clean (confirmed via go build ./... across every module) and aggd/internal/txservice already implements TransactionService against it. This predates the current session’s work and was simply never reflected here.
Depends on: engines done. Exit: model validated; wire format frozen with confidence. Met, 2026-07-24.
Phase 2 (P1) — Real anchor & first corridor (the commercial wedge)
- Hedera HCS integration test on testnet — credential-gated, skips cleanly without creds; proves the
OrderingAnchor abstraction against the real ledger. Written, 2026-07-24 (internal/anchor/hcs_live_test.go): submits a real HCS message and polls the real public Mirror Node until the round-trip verifies (retried, not a fixed sleep — indexing takes a few real seconds). Confirmed it skips cleanly without HEDERA_OPERATOR_ID/HEDERA_TOPIC_ID. Not yet run against a live, funded testnet account — no such credentials exist in this environment; that residual is honest, not claimed as verified.
- End-to-end corridor — two national aggregators settling a Regime-C transaction over Hedera, with the batch anchor carrying IIoT-scale volume. Still open. This is a live-deployment demonstration, not something written in code — no LXD/Juju cluster or funded testnet credentials exist in this environment (same standing gap as every other deploy-testing item this session). The building blocks it depends on (Regime C wired live behind
--enable-regime-c, the live Hedera integration test above, the batching anchor) are all in place; nothing has actually run the corridor end-to-end.
- Evidence-trail export — the anchored Intents/Commitments/settlements as a queryable, court-admissible artifact (seed of the compliance product, COMMERCIAL #2). Done, 2026-07-24:
ExportEvidence RPC bundles one intent’s full Agreement/Intent/Commitment evidence. Deliberately excludes the anchor’s own inclusion proof — independently re-derivable from ordered_receipt via the anchor’s own Verify, not something this service should custody rather than the public ledger itself.
Depends on: Phase 1. Exit: one live corridor, demonstrable, with exportable evidence — the sellable wedge. Partially met: exportable evidence is real and tested; the live corridor demonstration itself remains the one genuine gap, blocked on deploy infrastructure this environment doesn’t have.
Phase 3 (P0-risk) — Consensus & security hardening — THE GATE
- Reconcile cometbft v0.38↔v1 — resolve the alias liability to a real version decision. Regime A’s atomicity (and therefore everything above it) rests on this consensus layer. Done, 2026-07-24 — see §1.F’s own item for the full detail.
v1.0.1 confirmed real and buildable, reconciled to it across every active build path; goldbftd‘s committed binary rebuilt against it.
- Security review of the settlement path: key custody, signature/replay handling, anchor-trust assumptions, suspense-account invariants. In progress, 2026-07-24 — full review conducted, 8 findings prioritised by severity/exploitability. Tier 1 (key custody: envelope encryption for
trace.org_trace_record‘s sensitive fields, removed in the 23-field collapse) is fixed — a minimal per-record AES-256-GCM design (DEK per record, KEK-wrapped via a local or Vault-backed KeyProvider, AAD-bound to identity), landed in both governance (tx-execution tier is dead code there, prepared-but-unwired) and orgnodes-overseer (the live call site). Tier 2 (signature/replay: nothing in the tree produced or checked real transaction signatures) is fixed — org-gateway now signs every transaction with its own key immediately after DID-verifying the caller (gateway-attested, not per-client, signing), and CheckTx‘s pre-commit gate has real key-lookup and replay-detection providers wired in place of the permanently-empty registry that made every provider-dependent check fail closed. Testing this surfaced and closed a second gap in the same area: the existing hash/signature checks never re-derived their digest from a transaction’s other fields, so a field mutated after signing (with the signature itself left untouched) would have passed unnoticed — a new binding check in CheckTx catches this. Tier 3 (bundled findings: aggd/internal/regimec zero anchor verification, and a self-reported anchor timestamp) is fixed — Regime C’s RecordAnchorReceipt previously accepted any anchor claim at face value; it now verifies the counterparty’s signature against the bilateral agreement’s registered key and independently confirms the claim against Hedera Mirror Node, using the anchor’s own verified consensus timestamp (never self-reported) checked against the intent’s deadline. Regime C remains unreachable in production today (no producer wires RegisterBilateralAgreement/RecordAnchorReceipt yet) — this closes the gap before that changes, not after. 5 lower-priority findings remain open, including a newly-noted one: aggd-abci‘s CheckTx has no caller authentication for any action at all, a materially bigger gap than either finding this tier addressed. Tier 4 (bundled findings: escrowexec wired unconditionally, and aggd/internal/regimec.Engine has no persistence) is fixed. Investigation found both less severe than the findings implied but real: escrowexec is reachable via an unauthenticated-by-default RPC, but its ledger is private, always-empty, never-funded scaffolding, so the actual risk was unbounded in-memory record accumulation, not fund loss — now gated behind --enable-escrowexec, off by default. regimec genuinely had zero persistence, unlike the Saga engine it says it mirrors — but AggregatorApp.Info() never reporting its last-applied height was accidentally forcing CometBFT to replay the entire chain through FinalizeBlock on every restart, which is what had been keeping regimec’s state alive; that same bug hard-crashes the node if block-store pruning is ever configured, and re-verifies every historical anchor against Hedera Mirror Node on every restart. regimec now has real Postgres persistence (folded into the app’s consensus hash, closing a related gap where regimec state divergence across replicas went undetected), and Info() reports the real height, so the whole app resumes normally instead of replaying from genesis. 4 lower-priority findings remain open.
- Standalone-build reconciliation for the ~105 nested tower/federation copies (or a formal decision to dedup them). Done, 2026-07-24 — see §1.F’s own item for the full detail. Real count was 10, not ~105; all 10 resolved (9 renamed, 1 formally kept separate).
GATE: no production settlement of real value until Phase 1 verification AND this phase pass. Settlement on an un-reconciled consensus layer is uninsurable.
Phase 4 (P1/P2) — Productize & scale (market-contingent)
- Multi-anchor implementations (national CBDC ledger, consortium notary) — each unlocks a sovereign market that would reject Hedera (COMMERCIAL #3).
- Corridor pricing & tiering aligned to the shapes; evidence-as-compliance packaging; gov/BPDI studio as a low-code product; per-pyramid SLA / observability dashboards.
- IIoT device identity — wire the Originator to real DID-authenticated device fleets at volume.
Confidence: lower — sequencing here follows market demand, not just dependency.
The gates (non-negotiable before money crosses borders)
- Regime-C predicate formally checked (Phase 1).
- Engines pass partition/crash property tests, not just happy-path (Phase 1).
- cometbft consensus layer reconciled to a real version (Phase 3).
- Security review of the settlement path complete (Phase 3).
_______________________________
Bottom line
- Variable Number of Federations = network = pyramid. Adopted as the default trust unit.
- Four production deployment shapes coexist.Tower (per-federation sovereign — the premium-plus pitch – 8 Virtual Machines per Federation – the ultimate in isolation); Shape 1 (per-federation sovereign — the premium pitch – 4 Virtual Machines per Pyramid, with 4 per sector) is what we lead with; Shape 2 (grouped pyramids by trust cluster — eg 5–7 pyramids covering 26 federations) is what most customers will operate at full scale; Shape 3 (single multi-tenant pyramid per jurisdiction — budget tier) is the on-request opt-in. Shape 3 has 8 Virtual Machines, with fully capable trading facilities, including – where permitted – cross-sector, cross-data-centre and international transactions. We will NOT ship a single global pyramid.
- Customers can migrate between shapes (Shape 3 → Shape 2 → Shape 1 → Tower) as scale + regulatory demands grow. The substrate supports all four.
- Cross-federation flows are real and frequent. We acknowledge this and have completed engineering for our five-mechanism plan to address them — and we can ship right now with all of them in place, because plans have engineering already implemented to v5. Note that Shape 2 makes most cross-federation flows intra-pyramid and therefore free of the cross-pyramid mechanism cost — a structural advantage of the grouped shape that the pricing should reflect.
- The v2 substrate is in place. Hedera anchoring is production-grade on the emit side (Hiero-SDK submitter + Vault signer + Mirror-Node verification); the cross-pyramid receive side (Mirror-Node subscriber +
RegisterExternalAnchor consensus action) is also complete. The aggregator-coordinated saga (Mechanisms 3 opt 2 / Mechanism 5 / Mechanism 6) is complete — see the next bullet. Shape 3 still needs ~4–5 weeks of per-network-config substrate work (DID trust lists, member-registry gating, audit-window scoping) before it’s production-ready.
- The cross-pyramid saga substrate is complete. An exact-decimal settlement ledger (double-entry, WORM journal) + the suspense-account taxonomy + a tier-aware coordinator implement Mechanisms 3 (opt 2), 5 and 6: deterministic routing, the sector→national→international escalation hand-off, proof-carrying commit (Merkle inclusion under a Hedera-anchored root), single-transaction atomicity (escrow + journal commit together), idempotency under the multi-replica broadcast, and consensus-block-time expiry/compensation. Funding follows Option A (settlement positions): an account is credited only against a proof of the pyramid’s own debit, so the aggregator never mints unbacked value. The Postgres persistence + the live Hedera transport are compile-checked; periodic position settlement/reconciliation is the main remaining piece.
_____________________
7. orgnodes-governors + Meta-Federation Coordinator Redesign — Scope
Status: scoping, agreed 2026-07-21. Not yet implemented. Gap-fill and redesign against §§1–4 above and the existing (partially built) gov.proto / gov-api / gov-abci / bpdi / regimea|b|c infrastructure in governance — nothing here is greenfield design.
0. Ground truth
- Regime A (2PC) is mandatory-available at intra-pyramid/tower scope, but does not exclude Saga there too: the regime table names the coordinator, it doesn’t forbid a strictly-safer, non-blocking protocol from also being offered at that scope for transactions that don’t need synchronous atomicity.
- Regime B (Saga) is domestic cross-sector only, coordinated by national-meta-federation / national-aggregators (1/country). No 2PC across pyramids.
- Regime C peer selection:
isTower || counterIsTower → national-meta-federation is the peer; else → national-aggregators is the peer. (CoreMeta.isTower / counterIsTower, fields 64/65, added to proto for this purpose.)
- Origination is uniform across human governor, BPDI contract atom, and IIoT device — all produce the same signed Intent/Saga shape (see §3). IIoT/smart-contract origination is hard-restricted to Regime A (2PC) only, per §3 — Saga is never available to it.
- Off limits, unchanged by this work:
tx-rails and national-aggregators‘s existing agg/tophats layer (merkle computation, anchor staging, the full automated Regime-A processing role). Any national-aggregators work below is additive only.
- Stale, ignored: the “Super-Meta-Pyramid / Super-Meta-Federation” BFT-coordinator VM diagram in the Deployment Shapes section above — superseded by the M8 deletion in §2.II.C.
0a. Two-layer governance model (settled 2026-07-21, refines §7’s original national-aggregators scoping)
Every company has an Overseer layer — internal business-process creation/enforcement, executive-controlled, entirely within that company’s own domain (orgnodes-overseer, unchanged, already built). That much was never in question.
What changed: a Gov layer — joint governance of a cross-boundary (inter-company) trading relationship or smart contract — is needed by any company doing cross-boundary trade, not only Tower/regulated verticals as originally assumed. The need doesn’t come from regulation; it comes from there being two parties to a deal, neither of whom should unilaterally control it. What Tower/regulated-vertical status changes is the Gov layer’s membership composition, not whether it exists:
- Tower / regulated verticals (e.g. UK Social Housing, post-Grenfell and post-Awaab’s-Law: strict regulation, frequent inquiries, this product line’s continuous-anchored-auditable-data pitch exists specifically to answer them): joint membership = the trading parties’ own overseer representatives, plus regulators where an actual mandate or consent exists — not a blanket “any governor can veto anything.”
- Unregulated companies: joint membership = the trading parties’ own overseer representatives only. Probity and mutual assurance between the companies actually trading, no external party at all. This is exactly the case §3’s national-aggregators scoping under-specified — see the revised entry below.
Consequence for the earlier “national-aggregators coordinates all domestic transactions automatically, regardless of any policy” assumption (§3’s original scoping): unwise, once seen against this model. Confirmed against real code, not just discussed in the abstract — aggd/internal/saga.Coordinator, national-aggregators’ actual current domestic-Saga mechanism, has zero policy/gating concept anywhere in its API (no CastVote-equivalent, nothing). Resolution is the same M-of-N/ApprovalPolicy mechanism §1 below already built for the Tower tier, additive in front of (never modifying) the existing aggd role — see the revised national-aggregators entry in §3.
Open, not yet designed: where the consent/mandate record lives (who tracks “company X granted/was-mandated oversight from governing body Y”), whether CastVote enforces it as a hard check or trusts whoever authors the policy, and how identity verifies across the Overseer/Gov layers’ different systems (they don’t coincide today — overseer-api is per-company, and only ever deploys at underlay-substrate/tx-rails (see §3 below — confirmed 2026-07-23 that it has no legitimate home at national-aggregators or either meta-federation repo); gov-api is per-federation/pyramid/tier, and deploys at all four repos.
1. What already exists (governance repo) — do not rebuild
| Piece |
Location |
State |
| Protocol definition |
proto/gov/v1/gov.proto |
Complete: GovernorRuntimeService, Regime, CoordinationMode enums, all three regimes’ RPCs (GovernorStudioService removed from this proto entirely — BPDI’s own studio surface now lives in oversight, see §3) |
| API server |
governance/cmd/gov-api/main.go |
Real, wires GovernorRuntimeService, broadcasts via mempool — trimmed to cross-federation coordination only (Regime A/B/C, CastVote), see §3 |
| Consensus app |
governance/cmd/org-server-abci/main.go |
Real (relocated here from internal/bpdi/cmd/gov-abci when BPDI split out of governance, see §3) |
| Runtime backend |
governance/internal/gov (1475 lines) |
client/convert/runtime/server/state, since grown to include CastVote/ApprovalPolicy, mandates, and the voter registry |
| Regime A engine |
governance/internal/regimea (168 lines) |
Real: participant/vote tracking, Approver interface already implements AUTOMATIC/SEMI_AUTOMATIC/MANUAL |
| Regime B engine |
governance/internal/regimeb (680 lines) |
Complete: durable Postgres persistence (PGJournal, hydrate-on-miss cache, idempotent SubmitStep), wired live into gov-api/main.go — see §2 |
| Regime C engine |
governance/internal/regimec (1014 lines) |
Complete: durable Postgres persistence, two-sided commit predicate with counterparty-authorship + anchor-substitutability enforcement, design review ratified 2026-07-23 (§4), formally verified 2026-07-24 (§4.H). Wired into gov-api‘s live RPC surface behind --enable-regime-c — see §2 |
| Anchor interface |
governance/internal/anchor (816 lines) |
OrderingAnchor interface, MemAnchor/HCSAnchor impls, NewLiveFromEnv guard (§4.B); batch/ subpackage for Merkle batching |
2. Cross-cutting mechanisms — status
- Batching
OrderingAnchor (internal/anchor/batch) — RFC 6962-style Merkle-batch wrapper (domain-separated hashing, no duplicate-leaf padding), one underlying Anchor call per batch, per-leaf receipts independently verifiable. 18 tests. Complete as a standalone package; dormant — unreachable from the live gov-api server since the overseer-api split (§3, intra-meta-federation) trimmed anchor construction out of its main() entirely (no Merkle/anchor role belongs at this tier).
- Regime B / Regime C engines — both complete with durable Postgres persistence (new
gov_coord schema). regimeb.Orchestrator: PGJournal, hydrate-on-miss saga cache (survives restart), idempotent SubmitStep (a retried call for an already-executed step key returns the existing result, no re-execution or double-journaling), federation_id/counter_federation_id persisted per entry; wired live into gov-api/main.go. regimec.Engine: Store interface (MemStore/PGStore), hydrate-on-miss agreements/intents, CheckTimeouts queries Store.PendingPastDeadline directly (correct across multiple Engine instances sharing one store). 19 tests (10 regimeb, 9 regimec) plus 3 new RPC-layer tests, since grown to a genuinely two-sided commit predicate with counterparty-authorship and anchor-substitutability enforcement (§4.D/E) and its design review closed, 2026-07-23 (§4’s own Status line). Wired live into gov-api‘s RPC surface 2026-07-24 (RegisterAgreement/SubmitIntent/RecordIntentReceipt/RecordCommitment/GetIntentStatus), behind --enable-regime-c (off by default).
- Live
OrderingAnchor implementation — governance/internal/anchor.HCSAnchor, real Hedera, falls back to MemAnchor without credentials (anchor.NewFromEnv()). Complete as a package; no longer structurally unreachable — gov-api/main.go constructs it via regimec.NewProductionEngine when --enable-regime-c is set, refusing to start rather than silently falling back to MemAnchor for money-adjacent evidence. Still off by default in every current deployment, pending an operator actually setting the flag with live Hedera credentials configured.
3. Per-repo scope
Rewritten 2026-08-12 to reflect the architecture as it actually stands today, not the July snapshot this section previously described. intra-meta-federation, national-aggregators, and underlay-substrate no longer exist — all three were retired and deleted outright once their functions had genuine, better homes elsewhere (see each below). The BPDI-relocation and per-repo agg/tophats narrative that used to anchor this section is superseded: business-process authoring now lives in exactly one place, and the agg/tophats co-function has been consolidated into a single shared service used by every trading tier.
tx-rails
The “Tower” repo: member-classes (org-node mesh, org-server-abci), the two independently-deployed BPDI/business-process meshes (overseers1, overseers2 — each a separate company’s own oversight/overseer-api instance), and this tier’s own regulated-vs-commercial gov-api presence. Every org-server-abci unit now runs executive-gateway as a charm sidecar (login/org-gateway auth), replacing the earlier standalone gateway apps entirely.
Retired, not ported: tx-rails’ own embedded agg/tophats role — the full Merkle-aggregation + Hedera-anchoring co-function that used to live inside this repo. Every trading tier needs the identical function, so maintaining a separate copy per repo was pure duplication with no behavioral difference between copies. Replaced by merkle-funnel (below), a single shared deployment tx-rails now relates to across a cross-controller CMR rather than running its own.
Kept: org-server-abci/member-classes exactly as before — identity, transfers, BPD (business-process-design) governance enforcement (the cc-bpd-0xx check family), asset/housing compliance actions (cladding-forgery, Awaab’s-Law hazard-remediation). oversight/BPDI stays here, its one genuine home (see the naming note below) — underlay-substrate, its previous intended destination, no longer exists.
national-meta-federation
The sole remaining Tower/meta-federation coordination repo. (intra-meta-federation previously existed as a parallel domestic-coordination sibling; it has been retired and its coordination role folded into this repo — there is no longer a separate “intra” vs. “national” split at this tier, one coordinator serves both scopes.) Carries no business-process-authoring tier of its own — BPDI/oversight has exactly one home, tx-rails, per the naming rule below; this repo is coordination-only.
Extended: a second, commercial-posture govnode/auditor-gov tier alongside the original regulated tier — same binary, same code, different deployment configuration (regulated-vs-commercial is a config switch on the same gov-api/gov-abci deployment, never a fork). executive-gateway is sidecared into every gov-api-k8s unit here too.
Related, not embedded: this repo has no agg/tophats role of its own — its govnode/auditor-gov apps relate to merkle-funnel across a cross-controller relation for the shared anchor/merkle function, the same pattern tx-rails uses.
Regime C (the cross-pyramid/international settlement path, Hedera-anchor-backed) lives in governance‘s gov-api, used identically by tx-rails and national-meta-federation — no per-repo variant.
merkle-funnel (new)
The shared agg+tophats co-function every trading tier now relates to instead of embedding its own copy. Two Juju models — merkle-funnel-worker (agg-node + tophats, the live function) and merkle-funnel-auditor (auditor-agg + auditor-tophats, an independent BFT-verifying copy) — each app single-unit, its own local goldbftd BFT engine.
agg-node‘s inbox poller reads directly from each trading tier’s org-node Postgres via orgnode_sources (JSON array of {network_id, dsn}), tags ingested batches with its own configured network identity, and rolls them into Merkle-anchored slabs. tophats submits the compounded roots to Hedera testnet (real HCS anchoring, not the local file-stub fallback) and writes the resulting hedera_tx_id back — independently verifiable by anyone via the Hedera Mirror Node, with zero trust required in the platform itself. No code fork from tx-rails’ original agg/tophats implementation: the Go source is built straight from tx-rails’ own aggd/tophats modules; this repo owns only the charm/rock packaging layer and the shared-deployment wiring.
governance
Cross-federation transaction coordination: Regime A (2PC), Regime B (Saga), Regime C (Hedera-anchored international settlement), and CastVote. Split further since the July architecture: membership lookup and identity-claims verification — previously part of this repo’s own scope — are now two separate, independently-deployed standalone services this repo’s clients call over gRPC rather than functions this repo implements directly:
pyramid-registry-api — federation-to-pyramid membership (PyramidOf) and federation-identity claims (ClaimFederationIdentity/LookupFederationIdentity, backed by a real Elastos EID mainnet DID contract verification, not a mock).id-location-claims-api — country/data-centre/sector location-claim verification, the fail-closed check aggd‘s applyInitiateTransfer consults before moving value across a claimed jurisdiction boundary.
Both are hosted on a shared, dedicated shared-registries-a VM — genuinely shared infrastructure, not duplicated per trading tier, exactly like merkle-funnel. governance itself retains the coordination/consensus logic (Regime A/B/C engines, CastVote/ApprovalPolicy tallying, the historical self-transaction rejection fix) and the registry-api/registryabci code that now lives at national-registry (below) rather than as a standalone deployment of its own.
national-registry
The shared regulator-veto and pyramid/data-centre-provenance mesh — a generalized registryabci ServiceType framework (RegistryProposal envelope, real BFT consensus, not a plain CRUD API) hosting: data-centre registry entries with provenance (approving_authority/approval_reference), pyramid-membership referential records, and the CastVote-based regulator-veto MANUAL-floor mechanism relayed into org-server-abci via an outbox+poller (vetorelay). Deployed as a multi-node mesh (registry-node units + a paired gov-api-node + auditor tier), with its own chubbychecker-registry auditor layer checking vote-tally replay consistency, DC-provenance completeness, and federation/country-binding integrity — catching DB-level tampering or eligibility-bypass that application-layer checks alone can’t.
executive-gateway (new)
A single shared authentication/authorization gateway service, sidecared as a charm layer into every tier that needs it: org-server-abci (member-classes, as org-gateway), the BPDI/oversight meshes (overseers1/overseers2, as overseer-gateway), and gov-api-k8s (both national-meta-federation’s tiers and national-aggregators’ former tier, as governance-gateway) — three logical roles, one binary, config-selected per deployment. Replaces three previously-standalone gateway applications entirely; the standalone apps have been removed.
chubbychecker family
The Byzantine-fault-tolerant auditor layer — not one binary but seven separately-deployed tiers sharing a common chubbychecker/checks+providers framework: the org-node tier (data-integrity/anchoring checks), the BPD-governance tier (workflow/token/RBAC enforcement, the cc-bpd-0xx family, now including asset-attestation forgery detection and Awaab’s-Law hazard-remediation compliance), the aggregator tier, the TopHats/cross-network-anchor tier, and — new since the registry/governance split above — a dedicated chubbychecker-registry tier (vote-tally replay, DC-provenance, federation-binding integrity) and a dedicated chubbychecker-governance tier (coordination-gate bypass detection, approval-policy self-consistency, saga-compensation completeness, historical self-transaction audit).
proto / gen/go
Changed since July: the itotcca/gen-go repo that gen/go used to be fast-forwarded from as a real submodule was destroyed; gen/go is now a plain vendored directory, regenerated directly from proto via buf generate and committed as ordinary source in each consuming repo, not pulled as a shared submodule pointer. Each repo that embeds its own copy of aggd/tophats/chubbychecker as a nested submodule (tx-rails does) carries its own gen/go copy too, resolved via that repo’s own go.work — there is no longer a single shared HEAD every repo tracks for this content, each vendored copy has to be regenerated and kept in step independently when the proto source changes.
Retired repos
| Repo |
Why retired |
Where its role lives now |
| intra-meta-federation |
Duplicated national-meta-federation’s own coordination role with no real behavioral difference between “intra” and “national” scope. |
national-meta-federation (single coordinator serves both). |
| national-aggregators |
Its aggregator + Merkle/anchoring (tophats-equivalent) role was pure duplication of what every trading tier needs identically; its governance-VM role duplicated governance‘s own coordination logic. Confirmed zero remaining consumers before deletion. |
Aggregation/anchoring: merkle-funnel. Coordination: governance (co-located with the relevant trading tier’s own gov-api). |
| underlay-substrate |
Was carrying a minimized mirror of tx-rails plus the BPDI relocation target — a second, smaller copy of functionality tx-rails already owned outright, kept in sync for no independent reason. |
tx-rails (member-classes, BPDI/oversight, everything underlay-substrate used to mirror). |
Naming (still holds)
oversight (repo) / overseer-api (binary) — business-process-design/execution. One genuine home: tx-rails. No other repo hosts a company’s own business processes.governance (repo) / gov-api (binary) — transaction coordination only (Regime A/B/C, CastVote). Deployed at every trading tier (tx-rails, national-meta-federation) with a regulated-vs-commercial posture selected by config, never by forking the code.
_____________________
represent Virtual Machines
