Tx-Rails — Underlay Integration Patterns

One-line summary: Tx-Rails is an underlay, not a replacement. Customer companies keep the front-ends they trust and bind Tx-Rails beneath as a continuous cryptographic audit layer. Today that binding happens primarily through one real, built, verified, packaged integration path — hash-only attestation. The three deeper paths have moved past “built”: each is now deployed in our own estate and committing through consensus. On 30 September 2026 a change made at the source of each path produced a new attestation that was committed and read back identically from two independent validators — Mode A at block 760820, Mode B at 760822, Mode C at 760824, Mode D at 760826. They remain reference implementations a customer’s own team adapts, not packaged products, and no customer has been onboarded through any of them. This document describes what each path actually does, what it doesn’t, and exactly how far each one goes.

The underlay philosophy

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 also gets a cryptographic fingerprint, cross-checked and 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 one small, well-scoped call to an underlay that gives them tamper-evident, cross-jurisdictionally-verifiable proof is a tractable conversation.

The auditor subsystem (ChubbyChecker) is what makes the underlay distinct from “just put it on a blockchain”. ChubbyChecker performs independent 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 not two products. They are the same deterministic action engine seen at different depths of adoption — and you choose the depth, at your own pace.

Pure underlay — change nothing about your front-end. Hash-only attestation. Your apps and screens are untouched; we faithfully record, cross-check and anchor the fingerprint of what they already commit. The wider Atom library runs behind this — as the schema ChubbyChecker validates against on the platform side — and a hash-only customer never touches it.
Substrate — compose with us. For greenfield builds, or customers who want deeper adoption, 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 a fingerprint of what your existing systems already commit can also run new processes directly — 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.

Mode A — Hash-only attestation: what’s actually built

What changes in the customer’s system: the customer’s transaction commit path is extended to publish a cryptographic hash of each committed transaction to the Tx-Rails underlay, via a signed call carrying a verified tenant identity.

What Tx-Rails receives: the hash, plus the identity/block-position metadata needed to place it. Not the transaction body, not the parties, not the amounts, not the timestamps as authoritative inputs.

Guarantees Mode A provides:

Tamper-evidence: “this hash was committed at this time” is provable later, by anyone, using a portable proof artifact and public cryptographic primitives — not a claim that requires trusting the Tx-Rails database or software.
Forward-only audit trail: the customer can prove their own hash sequence matches what was actually anchored.
Cross-jurisdictional verifiability: Merkle roots of block slabs are anchored to Hedera, so a third party in another jurisdiction can verify the hash sequence existed without trusting the customer or Tx-Rails.
Durable evidence, not a single-validator dependency: the raw block data and transaction-location index a proof is built from are both independently archived (cmd/block-archiver), not held only on the validator’s own disk — and a proof can be located from the transaction’s own content hash, not only from an internal Tx-Rails record of where it landed.
Choice of anchor, not lock-in to one: Hedera is the default, but the anchor submitter is chain-selectable, and a built, tested Ethereum path already exists alongside it (see the Status table below) — a deployment picks the anchor that fits its own risk/cost tradeoff rather than inheriting a single fixed choice.

Guarantees Mode A does NOT provide:

Independent re-verification of transaction contents — ChubbyChecker cannot cross-check data it doesn’t have. (Where re-verification is structurally possible at all — two independent parties each submitting a claim about the same event — it’s Regime C’s bilateral settlement predicate that already provides it, not a Mode A/B/C/D gap; see below.)
Detection of “the customer published a hash of a fake transaction body that they later substituted into their own system” — Mode A trusts the customer’s hash submission for what it represents.
The full BFT cross-validation story: with only hashes, the BFT mesh has nothing semantic to validate.

When Mode A is appropriate:

Customers in proof-of-existence regimes where merely showing “this record existed at this time” satisfies the regulatory requirement.
High-volume / low-margin transaction streams where richer integration overhead would be prohibitive.
Initial pilot phase before a customer commits to deeper integration — noting that the deeper paths below, while they now run and commit in our own estate, aren’t packaged products a customer can simply install yet.
Customers whose regulatory environment forbids transmitting transaction details to an external system at all — Mode A already satisfies this by construction, since it never receives them.

Roadmap: the deeper integration menu

The original design for this platform sketched three additional integration modes, trading integration invasiveness for how much metadata lands automatically. All three are now deployed in our own estate and committing through consensus (goldbftd + org-server-abci + org-gateway, plus a real Postgres for the two that need one) — see below for exactly what each one covers.

What “committing” means here, and why the distinction is worth labouring. For most of the time these three were described as working, they were not. The gateway returns a success code and a real transaction id as soon as a submission passes admission control — and admission control runs neither the action’s own validation nor the authorization check. A rejected submission still comes back as accepted, and still appears in a block. Every one of the three was reported as working on exactly that evidence, and none of them had ever committed anything. The only proof that holds is a new row of attested state, read back from two independent validators and found identical. That is the test each of the four now passes, and it is the only one quoted above.

None of the three is a packaged, install-and-go product, and no customer has been onboarded through any of them — this document stays honest about that gap rather than presenting more than what’s actually there.

CDC / change-data-capture observer (Mode B) — deployed and committing. cdc-observer attaches to the customer’s Postgres write-ahead log as a genuine logical-replication client (pglogrepl, decoding pgoutput directly — no Debezium/Kafka dependency) and observes committed changes asynchronously, with no change to the customer’s application. Forensic, not preventative, by construction: the customer’s transaction is already committed to their own database by the time this mode observes it — there’s nothing to block. Identity attribution uses one coarse service-account credential per customer deployment (real tenant boundary, but per-user attribution is lost) — no new verifier code needed, since the same static-token pattern the SDK path already uses covers it; a mapping layer back to real identity from the customer’s own audit columns has no prior art anywhere in this codebase and remains unbuilt. The WAL operation itself (INSERT/UPDATE/DELETE) maps directly onto the matching RequType value. Ships in connectrpc/services/org-gateway/cmd/cdc-observer, verified against a real Postgres with wal_level=logical.
Gateway-mediated (Mode C) — deployed and committing. edge-gateway is a real inline HTTP reverse proxy, not the heuristic REST-inference engine early sketches worried this mode would need — semantic inference from arbitrary REST shapes doesn’t generalize across customers’ API conventions, so this reference implementation uses an explicit per-customer route-mapping config (method + path prefix → atom) instead, exactly the same “customer states it, nothing infers it” approach the SDK path’s semantic-intent tagging uses. It reuses org-gateway’s existing JWT verification entirely — edge-gateway never inspects a credential itself, only forwards it through. Because it sits inline, it’s the one of the three that’s genuinely preventative: fail-closed, unconditionally, by design — any rejection blocks the request before it ever reaches the customer’s backend. That’s also its real cost: an outage there is a materially different reliability commitment than an out-of-band audit sidecar, since it breaks the customer’s application, not just their audit trail. Ships in connectrpc/services/org-gateway/cmd/edge-gateway.
SDK / atomic dual-write (Mode D) — deployed and committing. The customer’s application calls Tx-Rails alongside its own database write, with explicit semantic-intent tagging (REVERSAL / CORRECTION / RESTATEMENT, now real RequType values, not a sketch). This is the cleanest of the three from a trust-model standpoint, since the customer’s own authenticated session makes the call directly — no inference, no identity-federation problem. True cross-system atomicity is a hard distributed-systems problem in practice; the realistic version, and the one that’s built, is an outbox pattern (write intent locally, relay asynchronously) — eventually-consistent, not literally atomic, and explicitly not preventative in this shipped form: unlike Mode C, the customer’s local write already happens before Tx-Rails could ever reject it. org-gateway‘s ExecuteAction accepts a client-supplied idempotency key and derives a deterministic transaction id from it, so a crashed or retried relay never double-applies the customer’s write — verified against a real goldbftd + org-server-abci + org-gateway stack, including the case where CometBFT’s own mempool rejects an exact-duplicate retry outright before it ever reaches the application layer. A reference outbox-relay implementation (Postgres-backed store, Connect-RPC client, a runnable poller) ships in connectrpc/services/org-gateway/cmd/dualwrite-relay for a customer’s own team to adapt to their own outbox table.

What’s still missing across all three, alike: packaged, documented client libraries or install paths beyond each reference Go implementation, and no customer onboarded through any of them yet. If and when that changes, this document will describe them as packaged products — the same standard applied here for each one’s core mechanism.

What Tx-Rails actually sees today

Every transaction processed through Mode A generates a metadata envelope handled under a fixed privacy contract: no business content, ever. What lands is identity/location pointers (tenant boundary, transaction id, block/slab position), the cryptographic hash itself, and consensus bookkeeping (block id, height). None of it carries business meaning by construction — a user identity is a verified but opaque tenant marker, not a name; the hash is a cryptographic commitment, not content.

This makes Mode A the most private of anything this platform could offer, not the least: because Tx-Rails never receives the content at all, there’s no leakage question to manage the way there is for the deeper modes above. All three of those now receive real content when a customer adopts them (unencrypted, no visibility controls) — a customer-key encryption / privacy-ladder answer to that gap remains undesigned for all three alike; that’s future work, not a currently-configurable option for any of them.

The 4 Integration Modes

The four Modes answer how content reaches Tx-Rails at all — nothing, a write-ahead-log observer, an inline gateway, or a direct SDK call. A separate question, orthogonal to all four, is who can decrypt what arrives. That is the visibility ladder (see below), and a customer picks a position on both axes independently.

Local View – A –
Integration Modes A; B; C; D: Core Mechanisms: From Underlay to Substrate

Mode	Status	What customer does	Metadata fidelity	Use case
A. Hash-only	Built, live	Commit path publishes a signed hash of each transaction; nothing else	Identity/location + cryptographic-commitment + BFT/discriminator fields only, of 33 — no content, no amounts, ever, by construction	Every customer scenario today; the only fully packaged, customer-adoptable mode
B. CDC observation	Deployed in our own estate and committing through consensus — reference implementation, not a packaged product	Real Postgres logical replication (`pglogrepl`, no Debezium/Kafka needed); nothing in the app	Adds CRUD intent directly from the WAL operation; coarse per-customer service-account attribution, not per-user — audit-column mapping back to real identity remains unbuilt	Frozen-vendor systems — the tooling is real; no customer has been onboarded through it yet
C. Gateway-mediated	Deployed in our own estate and committing through consensus — reference implementation, not a packaged product	Routes API traffic through a real inline reverse proxy (`edge-gateway`); app unchanged	Derives semantic intent from an explicit per-customer route config (method + path), not HTTP inference; attribution via org-gateway’s existing JWT verification, forwarded through unchanged	Clean single API edge — the only one of the three that’s genuinely preventative (fail-closed); no customer has been onboarded through it yet
D. SDK / atomic dual-write	Deployed in our own estate and committing through consensus — reference implementation, not a packaged SDK	Calls tx-rails alongside its own DB write, via a reference outbox-relay a customer’s own team adapts	Carries the full 33/33, with explicit semantic intent — real now, not a sketch	Very-high-value flows needing explicit REVERSAL / CORRECTION / RESTATEMENT tagging — the tagging is real; no customer has been onboarded through it yet

Where Rung 2 actually stands, and where it is going. Ten fields of every transaction record are already sealed individually under a platform key, each with its own per-record data key bound to the record and field it belongs to: the client node, the signing string, the user and role, the database, schema, table and record identifiers, and the amount mantissas and exponents. That last group of four matters more than it looks — a pointer to the exact customer row a transaction touched is a de-anonymisation index if it is left in the clear, whatever else is protected.

What is not yet sealed is the business payload itself on the content-receiving Modes. The intended floor is that it should be — content held under a key we hold, rather than in the clear. Rung 2 costs nothing structurally, because the platform can still decrypt to validate and cross-check exactly as it does with plaintext; what it buys is that a copied disk, a stolen backup, or a replica that escapes its blast radius yields ciphertext instead of customer records. The mechanism is not speculative: it is the same envelope encryption already proven on those ten fields, and on the pre-registration baseline store, extended to one more column.

Your Mode sets a ceiling on which coordination Levels you can use

The Modes and the coordination Levels are usually described separately, which hides a dependency between them that decides what a customer can actually buy. Level 1 is the registry: who is a member of a sector, and who vouches for them. Level 2 is the crossing: what may pass between sectors, under which regime, and the durable record that it did.

Level 2 has to read a transaction to apply a regime to it. It is deciding which regime governs a crossing and which authority owns it — and neither question can be answered from a hash. So Mode A cannot reach Level 2, not as a matter of configuration or licensing but because the information Level 2 needs was never transmitted. A Mode A customer gets Levels 0 and 1 in full, and every ordinary transfer inside their own sector; a crossing into another sector needs Mode B or deeper. This is the one place where the two axes are not independent, and it is worth stating plainly rather than letting a customer discover it after choosing a Mode for confidentiality reasons.

Where Level 2 stands, measured 1 October 2026. Level 2 runs on two governance meshes which are the same binary in two postures — a regulated one and a commercial one. The rule is that regulation attaches to the company: once a party comes under regulation, its transfers settle via the regulated mesh regardless of what geography alone would have chosen. Until this week nothing computed that. Routing was derived from addressing only — pyramid, sector, data centre, country — and no code anywhere consulted regulated status, so a regulated counterparty could be hosted by the commercial mesh on geography alone, and both meshes could each believe they owned the same transfer. Settlement needs exactly one authority per transfer, so that was a correctness defect and not a preference.

Host selection now exists as a pure function of (regulated status, then coordination tier), and the governance deployment enforces it rather than trusting callers to apply it — a rule only the caller applies is a convention, and a convention is not a control. The binary carrying it is live on all eight governance validators, verified by digest inside each running container rather than from a deployment status field. The enforcement itself is deliberately switched off. It arms per mesh, by an explicit setting, so that “the code is deployed” and “the control is on” remain two separately verifiable facts; a misconfigured value blocks the unit with a named reason rather than silently disabling the control. What a regulated federation is stays a registry of explicit records, readable and revocable — never inferred at runtime from anything about the identifier itself.

Local View – B –
The Data Visibility Ladder — four rungs, independent of which Mode you pick

The four Modes above answer how content reaches Tx-Rails at all — nothing, a WAL observer, a gateway, or a direct SDK call. A separate question, orthogonal to all four, is who can actually read whatever content does arrive once one of them is sending it. That’s the Data Visibility Ladder: four rungs, each an explicit answer to “who can decrypt this field, and what does the platform give up or gain in exchange.” A customer climbs the rung that matches their own risk tolerance against how much platform-side service — cross-checking, referential validation, independent audit — they want in return. The full design lives in structured-atom-privacy-ladder-design.md; this section is the customer-facing summary, kept in sync with it.

Rung	Who can decrypt	What the platform gives up	Status
1 — Plaintext	Everyone in Tx-Rails’ own operational chain	Nothing — full validation, full ChubbyChecker cross-checking	Default today, for every content-receiving Mode (B, C, D), once adopted
2 — Platform-key encrypted	Tx-Rails (customer explicitly consents)	Nothing structurally — the platform can always decrypt to validate/cross-check, same as plaintext, just protected from anyone outside the platform’s own key custody (a stolen DB backup, a network intercept)	Mechanism built, carrying no production data. The field sealer and its schema exist and are exercised by tests, and organisations.tenant_sealed_fields is present in the live schema — but measured 2026-10-02 it holds zero rows, against 33,964 rows in trace.slab_anchors on the same tier. No record has been sealed in a running deployment. This is the intended floor for the content-receiving Modes and the current direction of travel, not a capability available today
3 — Customer-key encrypted	Only the customer — Tx-Rails genuinely cannot decrypt, even in principle	Depends on the field — nothing, if the platform never validated that field’s content anyway; the rest of the cross-check catalogue, for the narrower case below	Already solved today for fields Tx-Rails never validates. Genuinely open only for the narrower case where we are expected to validate customer key-encrypted data.
4 — Partner-key encrypted	Only a named third party the customer chooses (a manufacturing partner, a regulator) — asymmetric, multi-recipient	N/A — separate key-management machinery layered on top of Rung 3	Undesigned. No code anywhere.

Trust, confidentiality and security — four questions that get asked as one

“Is my data safe with you?” is really four questions with different answers, and separating them is the only way to say anything precise.

Question	What it actually asks	Which axis answers it
Confidentiality	What does Tx-Rails receive?	Your Mode — fixed before anything is transmitted
Retention	What does it keep, and who can read it afterwards?	Your Rung on the visibility ladder
Trust	What must you rely on us to do correctly?	Everything above Rung 3 — key custody, access control, honest operation
Security	What survives if we get it wrong?	Only Mode A and Rung 3 survive a total compromise

A guarantee resting on our conduct is a different kind of promise from one resting on the architecture. The first can fail quietly; the second cannot fail at all, because there is nothing to fail. Mode A and Rung 3 are the only two positions on either axis that are architectural. Where Rung 2 actually stands, and where it is going. The sealer covers ten fields of a transaction record, each sealed individually under a platform key with its own per-record data key bound to the record and field it belongs to: the client node, the signing string, the user and role, the database, schema, table and record identifiers, and the amount mantissas and exponents. That last group of four matters more than it looks — a pointer to the exact customer row a transaction touched is a de-anonymisation index if it is left in the clear, whatever else is protected. That is what the mechanism does, not what any deployment currently holds. Measured 2026-10-02 on the member-classes tier, organisations.tenant_sealed_fields contained zero rows while trace.slab_anchors contained 33,964 — so roughly thirty-four thousand transactions have been traced and none has been sealed. Switching the sealer on for a real deployment is the work; the field list above is the design it will apply.

Routing is not exposure

A reasonable assumption is that the more of your traffic passes through our infrastructure, the more of it we see. That is not how it works. What we see is fixed by your Mode, before a packet moves. Routing a Mode A hash through one gateway, four, or a national tier changes nothing, because there is no content at any hop to intercept. On a content-receiving Mode we process your data because that is what the Mode is for, gateway or no gateway.

A mandatory chokepoint does buy something real — every submission is recorded before it executes, so nothing enters unobserved. It does not change what we can read.

What each Mode costs you in exposure, and buys you in assurance

Mode	Confidentiality from us	Evidentiary value	Integrity before submission
A — hash-only	Structural — nothing to intercept	Proves something changed. Cannot show what	Yours. We were not there
B — CDC observer	Set by your Rung	Full	Observed at the database — captures what was actually written
C — gateway-mediated	Set by your Rung	Full	Assured — in the path, can reject before the write lands
D — SDK dual-write	Set by your Rung; bulk attachments can be sealed under your own key today	Full	Atomic with your own commit — the tightest binding to your database state

These are not a price ladder with a cheap end and a premium end. They are four answers to one question: who do you need to be protected from?

Mode A’s limit, stated as plainly as its strength

Mode A cannot detect tampering that happened before you sent the hash. The hash is computed after your transaction has already executed in your own system, so a record altered inside your estate beforehand is attested faithfully as though it were correct. We can prove what we received and that nothing changed it afterwards. We can never prove what you did. Choosing Mode A for confidentiality means also choosing to own that half of the problem.

Modes B, C and D each close that gap differently — by observing at the database, by rejecting in the path, or by binding atomically to your commit. That is the real reason all four exist.

What none of it protects you from

Every mechanism here answers one question: has this record changed since it was submitted? None of them answers whether it was true when it was made. We can prove a transaction was submitted, when, by whom, and that nothing altered it since. We cannot prove the underlying event happened, that the figures were honest, or that the person authorising it was entitled to. Tamper-evidence is not truth, and any vendor claiming otherwise is selling something that does not exist.

Verify rather than believe

Your integration Mode is recorded with every transaction we hold, so you can confirm your traffic was treated as the Mode you contracted for — not merely be told it was.
The Mode A guarantee is enforced in code, not policy. A Mode A submission carrying anything beyond the attestation envelope has it discarded before storage, and the event logged as the contradiction it is.
The anchors are public. Roots are published to a public ledger, so you can verify that what we hold today is what we held then — without asking us, and without our cooperation.
The audit tier is separated from the workload it audits, on its own infrastructure and under its own administration, so the party being checked is not the party doing the checking.

Edge cases

Air-gapped / public-DLT-prohibited environments

Some regulated environments (defence, national-security, certain financial-services back-offices) prohibit anchoring any data — even Merkle roots — to a public distributed ledger like Hedera. Mode A still works within the customer’s own network in this case: hash attestation and BFT cross-validation are unaffected. What’s lost is the cross-jurisdictional verifiability story — a third party outside the customer’s network can’t check Hedera to verify anything, because nothing was anchored there. The audit chain becomes verifiable only by parties the customer admits to their own network. For most regulated commercial workloads, Hedera anchoring is permitted and the full cross-jurisdictional story holds.

Data sovereignty without public-DLT prohibition

A more common variant: customers (especially government and critical-infrastructure) require the source-of-truth to remain in-jurisdiction. Mode A already satisfies this by construction — Tx-Rails never receives the transaction content at all, so there’s no content to keep in- or out-of-jurisdiction. Only the hash and the block-slab Merkle roots leave the customer’s control, and the latter go to Hedera by design.

Greenfield customers (no front-end to preserve)

The framework applies but the framing shifts. With no existing system to preserve, the pitch is “substrate” (build your new system on top of us) rather than “underlay.” This uses the compose-with-Atoms path described above, not the deeper integration modes in the roadmap section.

Why hash-only still holds up across verticals

Every customer scenario in every vertical can use Mode A today for exactly what it’s good at: proving a record existed, unaltered, at a specific time, verifiably by a third party who trusts nothing about Tx-Rails or the customer. Independent content re-verification isn’t something any of Modes B/C/D are missing — it’s only structurally possible where two independent parties each submit a claim about the same event, and that’s Regime C’s bilateral settlement predicate, not a gap in the integration modes. Inline rejection is available now via the gateway-mediated reference implementation; explicit semantic-intent tagging (REVERSAL / CORRECTION / RESTATEMENT) is available now via the SDK / atomic dual-write reference implementation. Neither is available through Mode A itself, and neither is a packaged product yet:

Banking / FCA financial services, UK Social Housing, health supply-chain, defence: Mode A gives proof-of-existence and tamper-evidence for every event today. Balance sufficiency and KYC status are single-party claims — Tx-Rails has no independent fact to check them against, so this isn’t a gap any mode fills, it’s structurally out of reach for an underlay. Chain-of-custody agreement between two independent handlers is a genuinely multi-party check, and that’s Regime C’s shape (a bilateral predicate over independently-submitted claims), not something the integration modes need to add.
Frozen-vendor enterprise, greenfield builds, proof-of-existence regulatory regimes: Mode A is the right and sufficient answer as-is.

The Transaction Metadata Trace

Every transaction processed by Tx-Rails generates a Trace record under a fixed schema — the substrate ChubbyChecker’s cross-checks run against. In Mode A, only the identity/location-pointer and cryptographic-commitment fields are populated (tenant boundary, transaction id, block/slab position, the hash itself); the fields that would carry business content or semantic intent are, by design, empty, because Tx-Rails never receives that content under this mode.

The schema itself does not vary — every transaction across the platform produces a Trace of the same shape — which is what makes the contract auditable by a technical reviewer independent of which integration mode a given customer uses.

What this document is and is not

This document describes the integration pattern that’s actually built, and is explicit about what’s roadmap rather than reality. It’s deliberately silent on:

Specific protocol details (gRPC schemas, retry semantics, secret management)
The BFT consensus implementation (CometBFT / goldbftd)
The ChubbyChecker cross-check catalogue
The Hedera anchoring cadence and cost model
Per-vertical regulatory framings (covered in vertical-specific pitch documents)

For those, see `4-integration-modes.html` for the executive-summary version, `tx-rails-master-pitch.html` for the cross-vertical narrative and financials, and the `CLAUDE.md` at repo root for the BFT architecture summary.

Status

Aspect	State
Underlay philosophy	Canonical; lead positioning in all customer/investor conversations
Mode A (hash-only attestation)	Built and verified end-to-end against a real chain, and the only one of the four that is a packaged, customer-adoptable product. The other three now run and commit here too, but as reference implementations a customer’s own team adapts — so Mode A remains the only path a customer can simply adopt, which is a different claim from being the only path that exists.
SDK / atomic dual-write (Mode D)	Deployed in our own estate and committing through consensus — a change at the source produced a new attestation at block 760826, identical on two validators (idempotency-key-derived deterministic tx_id, RequType semantic-intent tagging, a reference outbox-relay implementation). Not preventative in this shipped form — the outbox pattern means the customer’s local write already happens first. Reference implementation for a customer’s own team to adapt, not a packaged SDK — no customer has been onboarded through it yet.
Gateway-mediated (Mode C)	Deployed in our own estate and committing through consensus — a change at the source produced a new attestation at block 760824, identical on two validators (`edge-gateway`: explicit route config, reuses org-gateway’s existing JWT auth, fail-closed inline rejection). The one of the three that’s genuinely preventative. Reference implementation, not a packaged product — no customer has been onboarded through it yet.
CDC observer (Mode B)	Deployed in our own estate and committing through consensus — a committed row in the customer-side database produced a new attestation at block 760822, identical on two validators (`cdc-observer`: real Postgres logical replication via `pglogrepl`, coarse service-account attribution, idempotency-key-derived tx_id). Forensic, not preventative — the customer’s write is already committed by the time this mode observes it. Reference implementation, not a packaged product — no customer has been onboarded through it yet.
Greenfield “substrate” framing	Available; use only when there’s no front-end to preserve
Anchor chain options	Two, both built and tested today: Hedera (default) and Ethereum. The Ethereum path is EVM-generic by RPC endpoint and chain ID alone — any EVM-compatible network, no code change, e.g. Elastos. A third, non-EVM chain is an extension of the same chain-selectable interface, not a rebuild. Reachable directly or, for callers that want a uniform interface regardless of which chain a deployment runs, via a gRPC bridge (`tophats.v1.AnchorService`).

FAQ — common customer-architect questions

Q1. Are your domain-specific actions completely redundant for a Mode A customer?

Short answer: Dormant for you, not redundant for the platform.

Tx-Rails ships with a large library of transaction-schema actions spanning many business domains (asset maintenance, banking, healthcare, housing, manufacturing, and more) — each the validation + persistence schema for a specific business event committed to the tx-rails BFT state machine. A Mode A customer invokes exactly one of them: the generic hash-attestation action. The rest are dormant for that customer’s day-to-day operations, but not removed from the platform, because:

The breadth is itself a pitch asset — it demonstrates platform maturity and the shape the substrate path can grow into.
They are the eventual upgrade path — all three roadmap modes now reachable via their reference implementations (Mode D’s outbox-relay, Mode C’s edge-gateway, Mode B’s cdc-observer), though none is a packaged product a customer can simply install yet.
Unused schemas have zero runtime cost — a validator that never receives a given action type never invokes its handler. The cost is container image size and codebase surface, not production compute or latency.

Q2. Is Kubernetes a requirement for us as a customer?

Short answer: No.

The tx-rails platform infrastructure itself runs on Kubernetes and LXD — that’s a deployment-side concern for the tx-rails operator, not the customer. Mode A asks the customer to add a hash-publish call to their commit path; this is a small library call, not an orchestration change. The customer’s existing infrastructure — mainframes, VMs, hosted SaaS, their own container platform — is unaffected.

The one forward-looking case where K8s becomes relevant on a customer’s side: if the customer later chooses to host their own tx-rails BFT validator or auditor node — analogous to a bank hosting its own SWIFT node rather than using a shared one. This is optional and not part of an initial deployment.

Q3. What user interfaces does Tx-Rails provide, and what stays on our side?

Short answer: Your existing front-ends remain unchanged. Tx-Rails provides only thin operator and verification UIs that have no incumbent.

For medium-to-large customers, the right working assumption is that Tx-Rails does not provide a customer-facing transaction front-end. The customer’s existing UIs remain in place; end-users never see Tx-Rails. What Tx-Rails does provide: an operations console (peer mesh health, validator status), a verification/evidence portal (retrieve and check inclusion proofs for a specific transaction — this is what `merkle-audit` and the artifact format it produces are for), and a trust-management UI for certificate issuance. Everything else stays on the customer’s side, in the UIs and workflows they already know.

That evidence portal can locate a proof two ways: by the transaction identifiers Tx-Rails already tracks internally, or directly from the transaction’s own content hash — useful when the party requesting verification (a regulator, opposing counsel) holds the disputed record itself but not the internal record Tx-Rails already keeps of it.

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