________________________________________________________________________

Integration 101

Distributed Hash Table Network

Peer-to-Peer (including Peer to Server) Connectvity without DNS

---

________________________________________________________________________

Integration 201

The Underlay! philosophy
Making Your Incumbent Systems
Continuously and Readily Auditable,
With Cryptographic Proof.

The single most important positioning point: Tx-Rails does not ask customers to replace systems they already trust. That is the difference between an “underlay” pitch and a “blockchain” pitch.

A blockchain pitch says: “Migrate your data and your front-end onto our new platform.” The underlay pitch says: “Keep your platform. Bind us underneath. Every transaction your existing system commits is also faithfully recorded, cross-checked, and cryptographically anchored — without changing how your users interact with your product.”

This is the only positioning that makes sense for regulated incumbents (banks, housing associations, hospitals, government agencies) who have spent decades and tens or hundreds of millions of pounds/dollars building front-ends their staff and customers understand. Asking them to throw that away is a non-starter. Asking them to add a small atomic dual-write to an underlay that gives them audit-grade evidence, BFT cross-checking, and cross-jurisdictional tamper-evidence is a tractable conversation.

The auditor subsystem (ChubbyChecker) is what makes the underlay distinct from “just put it on a blockchain”. ChubbyChecker performs 129 cross-checks per transaction/block, operated by parties independent from the BFT validators. Compromise detection is automatic: when the count of provably-compromised servers exceeds the BFT threshold f, the system detonates — refusing to commit further state until the breach is resolved. This is the load-bearing safety net no blockchain pitch can credibly offer.

---

From underlay to substrate — one engine, your pace

Two things we say can sound like opposites: “keep the systems you trust — we bind beneath as an audit underlay” and “compose your own business processes from our Atoms.” They are not opposites, and they are not two products. They are the same deterministic action engine seen at different depths of adoption — and you choose the depth, per workflow, at your own pace.

The four integration modes below are rungs on one ladder. The further you climb, the more of your logic the engine carries — but you are never asked to climb in order to get value:

1. Pure underlay — change nothing. Hash-only or change-data-capture. Your apps and screens are untouched; we faithfully record, cross-check and anchor what they already commit. The Atom library runs behind the audit — as the schema ChubbyChecker validates against — and you never see it. (Modes A–B.)
2. Edge- and write-bound. A gateway, or a small atomic dual-write, lets the engine act on the transactions that matter — still your front-end, still your data, now with inline rejection and full-fidelity evidence. (Modes C–D.)
3. Substrate — compose with us. For greenfield builds, or the high-value flows you choose, you author business processes from Atoms in the Overseer Design Studio and the Overseer enforces them. Here Tx-Rails is the application substrate, not just the audit floor.

The through-line: the same audited, deterministic action engine that records the transactions your existing systems already commit can also run new ones — when, and only when, you choose to compose them. The underlay is complete on its own; composing is an expansion you grow into, never a condition of entry. That is why “underlay” and “build on us” are one continuous offer rather than a contradiction.

---

Four underlay integration modes

Each mode trades integration invasiveness for metadata fidelity, where “fidelity” is the share of the 33-field Transaction Metadata Trace (see [metadata-fields.md](metadata-fields.md)) that lands without changes to the customer’s screens. See the companion [4-integration-modes.md](4-integration-modes.md) for the headline summary; this document is the engineering-depth version.

Global View – 4 Modes of Integrating with Tx-Rails: From Underlay to Substrate. Only Mode A currently built and offered.

Mode	What customer does	Metadata fidelity	Use case	Built/Roadmapped
A. Hash-only	Nothing; tx-rails computes row-hash from CDC	24 / 33 fields, no semantic intent	Low-stakes flows where the audit just needs “this row existed at time T”	Built
B. CDC observation	Adds Debezium / equivalent to their DB; nothing in the app	27–29 / 33 (CRUD intent from CDC; user/role IF the customer’s table has audit columns)	Mid-stakes flows; most existing apps that already write created_by / modified_by to their rows	Roadmapped
C. Gateway-mediated	Routes API traffic through the tx-rails gateway; app unchanged	32 / 33 (gateway sees the HTTP method, the JWT, the body — derives semantic intent from path + verb)	High-value flows; new app deployments where touching the network edge is cheap	Roadmapped
D. SDK / atomic dual-write	App calls tx-rails alongside its own DB write	33 / 33 with explicit semantic intent	The very-high-value flows where the customer wants explicit REVERSAL / CORRECTION / RESTATEMENT tagging	Roadmapped

---

________________________________________________________________________

Integration 301

Kubernetes

---

________________________________________________________________________

Integration 401

Byzantine Fault Tolerance

---

________________________________________________________________________

Integration 501

The Auditor – ChubbyChecker

---

________________________________________________________________________

Integration 601

Decentralised Ledger Technology (DLT)

---

________________________________________________________________________

Integration Tx01

Three regimes (the 8 mechanisms collapse to these)

Automation:
Automated/Semi-Automated/Manual Operation provided

Regime	Scope	Protocol	Coordinator	Old mechanisms
Tx01/A — Atomic	intra-pyramid, intra-tower (one trust domain, low latency)	2PC over BFT	local (pyramid) – Nat. Meta-Fed	M2, M3, M7
Tx01/B — Orchestrated	domestic cross-sector / cross-data-centre (one sovereign)	Saga (compensation, no locks)	National Meta Fed/ (1/country)	M5 — re-cast as Saga, not 2PC
Tx01/C — Peered	international (no shared trust domain)	anchor + bilateral agreement + Saga compensation	none — mesh of National Meta Fed peers	M1 + M4

________________________________________________________________________

Domestic, Inter-Sector and Global Trade

Where Tower Federations May or May Not Be Involved

________________

________________

________________________________________________________________________

________________

________________

________________________________________________________________________

________________

________________

________________________________________________________________________

Transaction Types

In the above arrangement, for a 2-Phase-Commit (2PC) transaction (ie demanding atomicity), Payer and Payee both prepare the transaction and issue “Vote Prepared” to the coordinating National-Meta-Federation which Commits the transaction, either succeeding or rolling back atomically. This is only feasible for an intra-tower or intra-shape transaction (Regime A), disqualified for cross-pyramid trade.
For a Saga Tx (Regime B)the National-Meta-Federation receives a Saga Request and polls the relevant Suspense Account then attempts to complete the Transaction, either succeeding or being forced to compensate all parties involved in the case of failure. This, unlike 2PC, is a multi-stage process.

________________

In the above arrangement, a 2-Phase-Commit (2PC) transaction (ie demanding atomicity) is likewise infeasible. For the required International Tx (Regime C) the participants must have pre-established a bi-lateral (or multi-lateral) written agreement. The transaction is a pseudo-Saga type, mediated by the agreed anchoring mechanism, where the transaction either succeeds or all parties involved are compensated in the case of failure.

________________________________________________________________________

Deployment Shapes

______________________________________

In the following, icons such as:
represent Virtual Machines

_____________________________________

---

________________________________________________________________________

Integration 701

Towers and Shapes

_____________________________________

National-Meta Pyramid

as Intra/Extra Sector Tower/Shape Coordinator

commercial-exec

audit-comm-exec

governor

audit-governor

Single Detached Pyramid	1 Federation carried. Overseen by Human Governance.	Virtual Machines Carried: 4 VMs. Governance Layer: 2 VMs
National-Meta-Pyramid	National-Meta-Federation	4 VMs: member-classes, audit-m-c, overseers, audit-overseers

_____________

The Tower: — Per-federation sovereign (premium-plus tier)

X federations, one Tower, 4 dedicated VMs/federation, sharing no validators with other federations. Strongest trust isolation; highest cost.

intra-member-classes-1

intra-overseers-1

audit-member-classes-1

audit-overseers-1

• 4 VMs in detached federation
• When to use: All Trade between parties with at least one Tower-Side.
• Customer profile: All Tower customers.
• Price point: highest per-federation; lowest operational risk.

_____________

Intra-Meta Level for Single Tower of Pyramids	X (0 < x < X+1) Federations overseen by Human Governance	Meta-Level: 4 VMs: governance-meta, audi-gov-meta; aggregator-meta-data-centre; audit-agg-meta
Pyramid 1	Federation 1: 8 Operational VMs:	intra-member-classes-1, intra-overseers-1, audit-member-classes-1, audit-overseers-1; aggregator-1-data-centre; tophats-1-data-centre; audit-agg-1; audit-tophats-1
Pyramid 2	Federation 2: 8 Operational VMs:	intra-member-classes-2, intra-overseers-2, audit-member-classes-2, audit-overseers-2; aggregator-2-data-centre; tophats-2-data-centre; audit-agg-2; audit-tophats-2
etc	etc	etc
Pyramid X	Federation X: 8 Operational VMs:	intra-member-classes-X, intra-overseers-X, audit-member-classes-X, audit-overseers-X; aggregator-X-data-centre; tophats-X-data-centre; audit-agg-X; audit-tophats-X

• 4 VMs per federation
• When to use: federations with statutory sovereignty obligations (a national wholesale market operator), federations with explicit regulator demands for hardware isolation, federations that compete commercially with peers in the same vertical and cannot share infrastructure.
• Customer profile: Tier-1 regulated utility, market operator, central bank-adjacent settlement layer, regulator running its own audit pyramid.
• Price point: highest per-federation; lowest operational risk.

_____________________

National-Meta-Federation

as Sector-Shape 1 Coordinator

governor

audit-gov

comm-exec

audit-comm-exec

_____________

intra-member-classes-1	intra-overseers-1	audit-member-classes-1	audit-overseers-1

_____________

Sector-Shape 1 — Per-federation sovereign (premium tier; the default we sell)

Shared Aggregator Level	Aggregating, Coordinating Tx for, and Anchoring All Pyramids. Automated.	6 National Aggregators: xpyr-aggregator-data-centre; xpyr-tophats-data-centre; audit-agg-xpyr; audit-tophats-xpyr; xnet-gov-sector-data-centre; audit-gov-sector-data-centre
Sector-Shape 1 Pyramid	Shape 1. One Federation carried per Pyramid	4 Virtual Machines Carried/Pyramid
Pyramid 1	Federation 1	intra-member-classes-1, intra-overseers-1, audit-member-classes-1, audit-overseers-1
Pyramid 2	Federation 2	intra-member-classes-2, intra-overseers-2, audit-member-classes-2, audit-overseers-2
Pyramid 3	Federation 3	intra-member-classes-3, intra-overseers-3, audit-member-classes-3, audit-overseers-3
etc	etc	intra-member-classes-x, intra-overseers-x, audit-member-classes-x, audit-overseers-x

_____________________

_____________________

National MerkleFunnel: All federations within one jurisdiction send all metadata to the Funnel.

National Merkle Funnel Level	Calculating Merkle Roots for All Pyramids, Anchoring and cross-checking replays.	1 National Meta Federation: (gov; audit-gov)	4 Virtual Machines Carried: aggd; audit-agg; tophats; audit-tophats
aggd-1	tophats-1	audit-agg-1	audit-tophats-1

_____________________