BANKS

________________________________________________________________________

You are welcome to refer to our Open Source Repository at

“https://bitbucket.org/itotcca/the-situation”

It’s a General-Purpose, Ultra-Secure Backend, protecting Databases with sophisticated Middleware, being developed with GO, Kubernetes (Juju / Charmed Kubernetes, with LXD for the audit tiers), and Bash scripting, on Ubuntu Linux 24.04. We add the Kademlia DHT Network with Absence of DNS (ADNS), full end-to-end IN-TRANSIT encryption (TLS 1.3, measured on the live gateways), and client-side AT-REST encryption that is built but switched on nowhere — no field is sealed in any running deployment today. The Middleware has been designed to provide for the highest level of Security, as demanded by Financial Institutions. It is, nevertheless, a completely General Solution – and the repository demonstrates that rather than merely claiming it, being designed for two (but unlimited in reality) very different member networks running on the same code. You need Data Security in these times of modern-day Storms that are always brewing, like intense low pressure systems; the Minder is brewing in a parallel but opposing way, like calming high pressure systems.

The position

We are not asking you to trust us. We are giving you a way to prove your own records to someone who does not trust you.

That is not a reassurance, it is a structural property. What follows is how it works, what it asks of you, and where the line between us falls:

We never receive your transaction content. Not encrypted, not redacted, not minimised — never sent. Your commit path publishes a cryptographic digest. There is no custody question to negotiate, because there is nothing in our custody to argue about.

You run your own nodes, inside your own legal entity — the same boundary as your regulatory licence and your data-residency obligations. The nodes holding your records are yours, operated by you, on infrastructure you control. We do not offer to run them for you, because the moment we did we would become a material service provider holding your records, and the rest of this page would stop being true.

And to prove your own records you need nothing from anybody else. Further down this page is a six-level model, and three of those levels — 0, 1 and 2 — are shared infrastructure that no single bank operates. None of them is required for Mode A, which remains the only mode we offer for onboarding. Modes B, C and D are implemented and running in our own development estate. Your own nodes, one hash per transaction and an anchor in a public ledger give you tamper-evident proof of your own records, on your own, today. The public ledger is the neutral third party: it is what a shared registry or a settlement tier would otherwise have to be, and it already exists, so the proof does not wait on an institution being founded.

Be clear about what that does not cover. Attestation is unilateral — you are proving that YOUR record existed unaltered, which holds whoever the counterparty was. Carrying a transaction to another member is a different function, and there levels 1 and 2 are load-bearing rather than optional: Level 1 establishes who is a member, and Level 2 carries interbank movement, domestic as well as cross-border. That is most of what a clearing bank does, and it is the roadmap rather than what is shipped. We separate the two because a reader who meets the shared levels first reasonably concludes this only works once everyone joins — and a reader told they are optional would conclude something equally wrong in the other direction.

What we ask of you at Mode A, which remains the only mode we offer for onboarding: one hash. Your commit path computes a cryptographic digest of the transaction and calls one endpoint. The hash algorithm is yours — SHA-256 by default, any length accepted. Everything else that lands — your tenant boundary, the transaction id, the block and slab position — is produced by the platform, not sourced by you, and arrives with no screen changes. There is no field-mapping programme at Mode A, and we will not quote you one for a product that does not need it.

What the ROADMAP modes would ask, stated separately so the two are never conflated. That you map your existing transaction data onto our published metadata specification, and create the fields you do not yet hold. Your systems compute one cryptographic digest across the record; your node publishes it. The record itself never leaves your estate — not encrypted, not redacted, not minimised. What crosses is that digest and your entnum — a raw, company-level registry identifier: not a person, not a name, and carrying no business meaning in itself. It is an identifier, not a pseudonym: it resolves to your institution against our registry, and we say so rather than call it opaque. This is an integration programme in your core systems, and we say so plainly rather than call it configuration.

And possibly a further ask, also not at Mode A, and one we do not yet know we need. We are determining whether the audit tier requires a Baseline: your metadata recorded before any processing, against which the post-processed metadata can be compared. If it does, you would be asked to provide a tamper-evident means of intercepting, generating and transmitting a minimal set of unprocessed — or public-key encrypted — metadata from your initial reception points at Levels 3 and 4. That is not the platform’s own interceptor: a Baseline has to be captured earlier, inside your estate, because a record taken by the system under audit cannot be an independent control on that system. We are running audits on test data to establish whether it is justified at all — whether there are faults a Baseline discovers that processing alone leaves invisible. Until that evidence exists this is a possible ask and not a requirement, and it belongs here beside the first ask rather than after the architecture is agreed.

The records are yours; the specification is ours. Which fields exist, how they are ordered and encoded, and how they are digested are IT/OT Chain & Cloud Australia’s design. That is not a proprietary flourish — it is the mechanism. A digest proves nothing unless every party computes it over the same fields in the same form. A fixed, published specification is what converts a private record into evidence a third party can verify: a party that does not trust you, and does not need to trust us.

One obligation is therefore yours alone. To prove a transaction later you must be able to recompute its digest, so the record must be retained in the specified form for as long as the proof may be needed. We cannot do it on your behalf, because we never hold it.

What we prove, and what we do not

Read this before the benefits. We prove that this record existed, unaltered, at this time, under this verified tenant. We do not prove the record was true. Content correctness is not something we can check — and where it is checkable at all, it requires two independent parties submitting claims about the same event, which is a different mechanism rather than a larger version of this one. Any vendor who tells you otherwise for a single submitter is selling you something that cannot exist.

Why this is worth something to you

Every time you must demonstrate that a record existed unaltered at a given time — to a regulator, an external auditor, a counterparty, a court — the demonstration currently rests on your own systems and your own auditors. You are inside your own evidence chain.

An anchored proof takes you out of it. The assertion stops being we say this is unchanged, and our auditors agree, and becomes arithmetic the other side can check for themselves. The value is precisely that it reduces what anyone has to take on your word.

What actually leaves your perimeter

A hash. Your entnum: a raw company-level registry identifier — not a person, not a name. A block and slab position. Consensus bookkeeping. None of it carries business meaning by construction.

We do not call the entnum opaque, because opacity is a property of who holds the value rather than of the value itself. It is meaningless to a passive observer and it resolves to your institution against our registry, which we hold. What bounds the exposure is that it is company-level and carries no business meaning — not that the number is unreadable.

The honest residual is traffic analysis: how many hashes, how often, in what bursts. We would rather raise that than have you find it. It is an engineering problem, not a disclosure problem — fixed-cadence, padded submission makes the hash stream independent of your real transaction volume, and it is the right thing to specify at deployment rather than discover later.

Who operates the audit tier

The auditor subsystem, ChubbyChecker, performs independent cross-checks and is what makes this more than a database with a hash column. Its independence must be from the validators. It need not be from your industry.

In banking a federation is one country and its members are that country’s banks, so the natural operator of the audit tier is a bankers’ association, a bank-funded mutual, or the regulator — not us. That is the intended model. It is not how the current demonstration estate is deployed, where auditors are co-resident with the workload they audit. Separation is a goal of the design and a deployment decision still to be made, not a property we are claiming today.

What is built, and what is not

Built, verified, and what you would be buying: hash-only attestation. One integration path. Your commit path adds a signed call carrying a verified tenant identity (your “entnum” to ITOTCCA); everything above (“a raw company-level registry identifier — not a person, not a name. A block and slab position”) follows from it.

Built as reference implementations, with no customer yet onboarded through any of them: a change-data-capture observer, an inline gateway that can refuse a request, and an outbox-based SDK relay. These are a real direction, adaptable by your team. They are not products you can install, and we will not pitch them as though they were.

Designed, not deployed: the data-visibility ladder — platform-key, customer-key and partner-key encryption of content. The field sealer exists in code and its schema exists in the database, and no record has been sealed in any running deployment. It matters only once a content-receiving path exists, which is why it is not on the critical path for this conversation.

Two things to make us demonstrate

Show me a proof I can check without you. We can, now: real Merkle roots on a public topic, readable through a public mirror node, decodable by your own people with no access to anything of ours. Today that runs against Hedera testnet; moving to a production anchor is a deployment choice, and an EVM (ie Ethereum instead of Hedera) path is built alongside it.

Show me what happens when it is compromised. Three different things happen, and they are worth keeping apart because only one of them is a decision we made.

At or below the Byzantine threshold f for the tier, the mesh keeps committing. That is the entire point of running 3f+1 nodes: correct operation while up to f of them are faulty or hostile. What happens is that your administrators are alerted, through an independent fan-out rather than through the compromised tier itself. Detection does not stop the system, deliberately — halting on detection would hand any single tampered node the power to stop your bank.

Above f, commits stop. We do not have to implement that and we take no credit for it: a quorum of 2f+1 is arithmetically unreachable once more than f nodes are compromised, so the mesh cannot finalise. The system does not choose to stop; it becomes unable to proceed, which is a stronger guarantee than a policy because there is no switch to disable.

Separately, a node that cannot trust its own storage halts itself rather than publish a result its peers would not reproduce. That is about determinism, not breach: one node’s bad minute must never become a permanent disagreement about what the chain says. This is the part we would most like your risk function to interrogate, because it is the one where a wrong engineering decision is invisible until it has already cost you the ledger.

TWO NETWORKS, ONE CODEBASE. The first worked example is BankNet: a federation is one country, its members are that country’s banks, and every member is a large institution capable of operating infrastructure. The second is a Social Housing Supply Network, where a federation is a trade or a profession – one each for carpenters, plumbers, electricians, wardrobe manufacturers and the rest, one each for the professional bodies of engineers, architects and town planners, and one for the housing providers themselves. The two differ in exactly one choice: what counts as a LIKE member. Banking federates by JURISDICTION; housing federates by TRADE OR PROFESSION. The platform already carries both axes without modification, because an identity claim records a sector and a country, and every transfer names its own federation and its counterparty’s.

We are not asking you to trust us. We are giving you a way to prove your own records to someone who doesn’t trust you. We prove that this record existed, unaltered, at this time, under this verified tenant. We do not prove the record was true. Content correctness is not something we can check, and where it’s checkable at all it needs two independent parties submitting claims about the same event — which is a different mechanism, not a bigger version of this one.
Although we hold metadata, and metadata allows inferences:

What lands is a raw company-level registry identifier, a hash, and a block position. No personal identifiers, no business meaning.

The residual is traffic analysis — volume and timing. This is engineerable: fixed-cadence, padded slab submission makes the hash stream independent of real transaction volume.

The auditor doesn’t have to be us. ChubbyChecker must be independent of the validators, not independent of the industry. In banking a federation is one country and its members are that country’s banks — so the natural auditor operator is the bankers’ association, a bank-funded mutual, or the regulator.

WHY THE SECOND EXAMPLE NETWORK MATTERS. Housing produces members that banking never does: a single-operator joinery, a sole-trader electrician, a one-person architectural practice. Such a member cannot run a cluster, cannot staff a committee and will never operate a node – and it must still be a member in good standing rather than a demoted client. That is the real test of the structure, and it is why Levels 3 to 5 are the member’s OWN estate whose depth varies by member: a bank fills them out substantially, while the joinery runs nothing at all and reaches the network through a shared, multi-tenant gateway. A design that requires every member to run infrastructure works for banks and fails for a one-person joinery. Two consequences follow, and both are treated further down this page. The trade body becomes the natural operator of its federation’s committee, because it already maintains a membership register with admission, standing and discipline – the institution that vouches for who belongs is the one running the mesh that records it. And the independent auditor carries more weight in housing than in banking, because there only the larger members can operate, and the independent witness is what makes a ledger run by the large acceptable to the small.

The aim is to reach a stage of development that an independent party – with sufficient knowledge, care and resources – can verify for themselves on a single machine, for example an Intel Core i9 workstation with 128 GB of RAM and 2 TB of SSD. The demo estate, “BankNet-Federations”, runs inside one virtual machine on that host.

ANCHORING: across the consensus levels sits the merkle-funnel, which combines the roles previously carried by the separate “tophats” and “aggregator” nodes, now replaced by a single “PowerFunnel”. It compounds each mesh’s metadata-based Merkle roots, and writes them to a Hedera Consensus Service topic, where anyone can read it back from a public mirror node and check it against the chain. It is a shared witness service rather than a level of its own, one of whose uses is in cross-border transactions.

THE AUDITORS: ChubbyChecker is paired one-to-one with each mesh it audits, and runs at every level except 0 and 5. The validators serve their block data to it; it independently re-derives and cross-checks what they claim. These are the components that back the Byzantine Fault Tolerant meshes, RAISING AN ALERT when it detects the number of Faulty nodes in the mesh to have exceeded f. It does not halt the platform: a human triages, because a false positive that stopped a customer’s operations would cost more than the breach it guessed at. The ChubbyChecker auditing meshes are themselves operated on their own BFT mesh arrangements. You need to be aware that this overall structure is designed in 2 independent parts –
The Kademlia Overlay for connecting clients (including employees) to the system

The above 6 levels (in particular levels 3 and 4) constituting a complete Metadata generation (the workload, ie: your company identifier/a metadata transaction record hash – then, computed by ITOTCCA, a Block position in its Slab/a Slab position in the database-node blockchain) and analysis (ChubbyChecker – the Auditor) System
In 2, we are in the process of determining whether the Auditor requires a Baseline of received metadata, that would be recorded before any system processing, against which it could compare post-processed metadata. As such, a Bank would be asked to provide a tamper-evident system to intercept, generate and transmit a minimal set of unprocessed/Public Key Encrypted metadata from the very initial reception points (at levels 3 and 4) owned by a member. The data transmitted for auditing is not legally, strategically or commercially sensitive. ITOTCCA is at the stage of running audits on test data to look for evidence that this Baseline is actually justified – ie are there occasions of discovery of faults invisible during or after processing without a Baseline.

DEMO SCALE VERSUS TARGET SCALE: every consensus tier in the published demo – Level 1 (the registry), Level 2 (gov-reg and gov-comm), Level 3 (the member’s own node), Level 4 (the overseer) and the anchoring tier – is deployed at 4 VALIDATOR NODES. Four is 3f+1 with f=1: the smallest true Byzantine fault-tolerant mesh, tolerating one faulty or dishonest node. It is not a simulation or a single-node mock, but the same consensus engine, ABCI applications and charms as the target system, at the smallest honest size that fits on one workstation.
In production, the member-class at Level 3 runs 7, 10 or 13 NODES (depending on members’ perception of Blast Radius), the overseers (Executive layer 4) offers the same choice, tolerating f=2,3 or 4, with level 2 offering n=10 or 13, according to members’ perception of BLAST RADIUS – ie – how much depends on that mesh being right – rather than the value of what flows through it. Level 1 (Registry) is defined at n=13. In general, going from 4 to 7, 10 or 13 is a deployment parameter, not a different codebase. The 10 or 13 at levels 1 and 2 are rotating COMMITTEES drawn from the membership, not one node per member: a federation of forty banks still runs 10 or 13, and membership grows freely while the committee does not. At demo scale that distinction is invisible, which is exactly why it is worth stating before anyone infers a ceiling of a dozen participants. The meshes are deployed as juju charms onto Kubernetes. To accompany this Backend/Middleware, a cut-back BankNet FrontEnd is being developed on the Ionic Platform.

________________________________________________________________________

Secure Bank Operations

banking-network

One Structure, Many Networks

Six levels: three belonging to the member, which are enough to prove that member’s own records, and three shared, which carry transactions between members. Banking and social housing differ in exactly one choice.

The shape

Levels 3, 4 and 5 are the MEMBER’S OWN ESTATE, and they come first because attestation — proving your own records — needs nothing above them. Their depth varies by member, and for a small member they shrink to almost nothing.

Levels 0, 1 and 2 are the SHARED NETWORK, operated by no single member. They carry transactions BETWEEN members: Level 1 establishes who is a member, and Level 2 carries interbank movement, domestic as well as cross-border. For that function they are load-bearing, not optional — and in social housing, where almost every transaction crosses, Level 2 is the hot path rather than an edge case.

The numbering says where a level sits, NOT what depends on what. 3, 4 and 5 do not rest on 0, 1 and 2. The order is a map of the network, not a build sequence and not a dependency chain — and reading it as one is the single most common misunderstanding of this diagram.

That is the whole test. A structure that requires every member to run infrastructure works for banks and fails for a one-person joinery.

An earlier draft of this document drew all six as peer layers. That was wrong, and it hid the only property that decides whether a network can be adopted by the small as well as the large.

The member’s own estate

Level 3 — the member’s own node

A bank runs a substantial internal cluster. A one-person joinery runs nothing at all and reaches the network through a shared gateway. Both are members in good standing.

The mesh boundary, where a member has one, is the LEGAL ENTITY — the unit of liability, of regulatory licence and of data-residency obligation.

LEVEL 4 — topology enclosing scope: THE MEMBER’S EXECUTIVE LAYER. This is the overseer, and it is a CONSENSUS TIER IN ITS OWN RIGHT: its own validators, its own quorum, its own paired auditor mesh, running inside one member’s estate. It composes and enforces business processes WITHIN one member’s tower (if choosing Integration Mode B, C or D) – the exact counterpart to Level 2, which coordinates and regulates transactions BETWEEN towers. Like Level 3, it is sized by BLAST RADIUS: 4 nodes in the published demo, 7, 10 or 13 in production.

WHAT IS SCOPE RATHER THAN TOPOLOGY IS THE STRUCTURE INSIDE IT. Regions, divisions, products and branch networks appear as tenancy SCOPES carried by that mesh, deliberately not as BFT consensus layers of their own. An org chart reorganises – annually, in banking – and modelling it as consensus would make each reorganisation a consensus migration: the most volatile structure in the business placed in the least changeable part of the system. The overseer carries those scopes as data, and that is precisely what keeps them out of the topology. So Level 4 IS a real mesh; the org chart inside it is not. That is why a reorganisation is a data change at Level 4 rather than a redeployment of it.

Level 5 — the edge, stateless

Branches, agencies, ATMs, kiosks, point-of-sale, employees and other users for a bank; site tablets and merchant terminals for a supplier.

A point-of-sale terminal has a customer standing at it. A mesh committing in about a second cannot authorise that, and at national volume cannot begin to. This is a category problem, not a tuning problem, and no reading of this structure should suggest Level 5 asks Level 3 before it answers.

So the edge produces CLAIMS and the mesh produces FACTS. A terminal authorises locally against a signed envelope of limits, emits a signed intent, and the transaction is reconciled afterwards — compensated if it proves inadmissible. A compromised terminal can forge a claim; it cannot forge a fact.

The consequence runs back through the whole design: automatic compensation is the NORMAL path for a meaningful share of edge traffic, not an exception handler bolted on at the end.

The shared network — what carries a transaction to another member

These three are numbered first and described last, and that is deliberate: the numbers say where a level sits, not what rests on what. What they are NOT is a nice-to-have. Mode A — proving your own records — needs none of them, and it remains the only mode we offer for onboarding. Everything a member does WITH another member runs through here, which for a clearing bank is most of its business and for a social housing provider is nearly all of it.

Level 0 — cross-border, stateless

A protocol plane, not a deployment. No nodes run here.

This is why nothing sits above a national federation. Banking data is domestic by law, so a supranational tier either sees what the law forbids or sees nothing — and a layer with no state and no nodes can hold no authority in any case. Cross-border movement is a saga between sovereign peers, each retaining its own data — forward steps with compensating actions, NOT a two-phase commit. The distinction is the whole reason it works: a two-phase commit needs a coordinator, and between sovereign peers there is no coordinator either side would accept. A saga needs none. Regime C carries it as RegisterAgreement → SubmitIntent → RecordIntentReceipt → RecordCommitment, each intent holding its own compensating step; the counterparty genuinely co-signs, its signing key registered in the bilateral agreement; and the shared ordering comes from the public ledger, which neither party operates. It is built and has been driven end to end against real Hedera testnet credentials. It is DISARMED on the current meshes — enable_regime_c is unset — and it needs Mode B or deeper, because a digest cannot be regime-checked.

A component may SPEAK Level 0 while SITTING lower down: gov-api carries the cross-border regime from Level 2. Participating in a protocol above yourself is ordinary. Being ruled by a tier above you is not, and that is the distinction the earlier pyramid framing lost.

Level 1 — the registry, the federation roll

Who is a member, in which federation, and with what standing. This is the registry, and it is a consensus tier in its own right rather than a database beside the network.

A FEDERATION IS A SET OF LIKE MEMBERS. That is the whole definition, and everything domain-specific is the choice of what counts as alike.

Membership and OPERATION are different things. A member is a party with standing; an operator is a member currently serving on the committee. In banking those sets nearly coincide. In social housing they diverge sharply, and the structure must survive that.

Level 2 — gov-reg and gov-comm

What may cross BETWEEN federations, under which regime, and the record that it did.

This is not routing. Calling it routing invites someone to optimise away the hop that carries the obligation. Regulation attaches to the COMPANY and overrides routing derived from geography: once a company is regulated it always transacts via gov-reg.

Level 2 belongs to NEITHER SIDE of a trade, and that neutrality is the point rather than a convenience. When the two parties sit in different federations, the tier that settles between them must not be one of them.

The earlier draft carried a “Level 2.5” for domestic interbank movement. A half-level is a sign a model has been patched rather than designed, and it is gone: what it described is what Level 2 does.

What counts as “like” — the one domain-specific choice

Banking federates by JURISDICTION. A federation is one country, and its members are that country’s banks.

Social housing federates by TRADE OR PROFESSION. One federation each for carpenters, plumbers, electricians, wardrobe manufacturers and the rest; one each for the professional associations — engineers, architects, town planners — and one for the housing providers themselves. Small trades amalgamate.

The platform already carries both axes without change: an identity claim records a sector and a country, and every transfer names its own federation and its counterparty’s.

A federation must be large enough to staff a committee. Amalgamate small trades until it is — the floor is set by n, not by the trade.

How many nodes, and what the number means

Every mesh is sized 3f+1, and the rung is chosen by BLAST RADIUS — how much depends on that mesh being right — rather than by the value of what flows through it: 13 tolerates f=4, 10 tolerates f=3, and 7 tolerates f=2.

n is the size of a rotating COMMITTEE drawn from the membership. It is not the number of participants.

n is also the number of nodes (7, 10 or 13) in the mesh.

A federation of forty banks still runs 7, 10 or 13 nodes, operated by a rotating subset of its members. Membership grows freely; the committee does not. Without this the design appears to hit a ceiling at a dozen participants and to require members demoted to clients, which was never the intent.

The roster and the authority that changes it are consensus.validator_set and consensus.rotation_approver. Both exist in code; neither has yet run, so committee rotation is designed and not operating.

Who operates a federation

In banking, any member could: the banks of a country are homogeneous in capability, and the committee is a rota among equals.

In social housing they are not. Most members cannot operate anything — which is what forces membership and operation apart, and is a better argument for the rotating committee than node-count economics ever was.

The guild structure supplies the answer. A trade body or professional association ALREADY maintains a membership register, with admission, standing and discipline. It is therefore the natural operator of its federation’s committee: the institution that vouches for who belongs is the one running the mesh that records it.

Why the federations are sector-scoped, and not one pool

If providers and merchants shared a single federation, the committee would be drawn overwhelmingly from providers — they are the members able to operate. The parties who OWE money would be operating the ledger that records what they owe.

Byzantine fault tolerance does not answer that. It protects against a MINORITY of bad actors; it offers nothing against a majority with aligned incentives.

Sector-scoped federations remove the conflict by construction. Each committee is drawn from its own like members, and the cross-side transaction settles at Level 2, which belongs to neither.

A residual remains and should be said plainly: within one trade, members still vary enormously, and only the larger will operate. That is tolerable where operators and non-operators are the same KIND of party — and it is exactly where the independent auditor stops being optional.

The auditors

The auditor subsystem is ChubbyChecker. There is no such thing as a SuperChecker; the name appears nowhere in the codebase.

Each auditor tier is paired one-to-one with the mesh it audits, and that pairing is a correctness property rather than a sizing preference: a weaker auditor caps the assurance you can claim at the auditor’s own fault tolerance, and lets an adversary silence the audit more cheaply than the workload.

Checkers run at every level except 0 and 5, which hold no state to cross-check.

In social housing the auditor carries more weight than in banking, because there only the large can operate. The independent witness is what makes a ledger run by the large acceptable to the small.

Be precise about what separation buys. Not sharing the Kubernetes failure domain is real. Not sharing a failure domain is not: in the current deployment auditors sit on the same host as the workload they audit. Separation is a goal of the design, not a description of today.

The consensus engine

CometBFT 1.0.1, built from this estate’s own fork and shipped as the binary goldbftd. An earlier draft said “Zerotrust Tendermint packages”: Tendermint is the engine’s former name, and “Zerotrust packages” names nothing that exists here.

The fork kept the upstream module path, github.com/cometbft/cometbft, so every import reads as stock CometBFT and is not.

Where the two networks genuinely differ

Federation axis: jurisdiction for banking, trade or profession for housing.

Who can operate: any member in banking; in housing, the trade body and the larger members.

Cross-federation traffic: a minority in banking, where most movement is within a jurisdiction. Almost ALL of it in housing — a provider buying from a carpenter crosses every time. Level 2 is therefore housing’s hot path, with sizing consequences a banking-shaped ladder does not anticipate.

The edge tier: CONTAINMENT in banking, where one owner has many devices and the mesh must be protected from that owner’s estate. DELEGATION in housing, where many owners have one device each and none will run a concentrator — so the gateway must be multi-tenant and operated by the network. That is different engineering, not different configuration.

Everything else is shared: the consensus engine, the ABCI application pattern, the auditor tier, anchoring, the registry, field-level commitments, cert-pinned name resolution, and the claims-versus-facts model at the edge.

What is built, and what is designed

This document describes a design and should not be read as a description of a running system.

Built and running: the consensus engine, the ABCI pattern, the auditor tier, anchoring to a public ledger, and the registry. Built but not operating: committee rotation. Designed and not built: the Level 0 cross-border protocol, and the Level 5 envelope-and-reconcile model.

Corrections carried in this revision

Against the ORIGINAL text: Level 1 named two different layers; “5-tier” contradicted the six levels then listed; the stateless international layer was drawn as the peak; “Zerotrust Tendermint packages” is CometBFT; “SuperCheckers” do not exist; “Level 3 consists of 7 Voting BFT Supernodes” is a ladder chosen by blast radius, with n a committee size; regions and divisions are tenancy, not layers; and 29 countries does not imply 29 federations under the regulated/unregulated split.

Against the FIRST re-issue, which described six peer levels: levels 0–2 are the shared network and 3–5 are the member’s own estate; Level 1 is the registry; Level 2 is the two gov arms, which retires the half-level 2.5; and the federation axis is named as the single domain-specific choice.

Added in this revision: why sector-scoped federations prevent a buyer-operated ledger, why a trade body is the natural operator of its committee, and the rule that a federation’s minimum size is set by the committee rather than by the trade.

BankNet uses …

Tx-Rails is based on a combination of
the original Byzantine Fault Tolerant
Tendermint Project (no mining)
supervised by ITOTCCA’s own ChubbyChecker

Secure-Client-Connections-with-DHT-Integration-97 Download

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