The position in one page

One difference decides everything else, and it is not the architecture.

The levels, their numbering and their meaning are identical to the banking page. What differs is which parts carry the weight, and the difference is large enough that a housing reader handed the banking version is misled. Banking federates by JURISDICTION, every member is a large institution, and cross-federation work is a minority of traffic. Social housing federates by TRADE OR PROFESSION, most members can operate nothing, and cross-federation work is nearly all of it.

Four levels swap significance as a result. Level 3 is usually nothing rather than a cluster. Level 2 is the hot path rather than an edge case. Level 1 is the least foreign part of the model rather than a new institution to found. Level 0 is the least relevant rather than the most exotic.

The banking headline is true here and much less useful. You can prove your own records alone, today, with nothing from anybody else — that holds in housing exactly as it does in banking. But almost every housing transaction is with another member in another federation, and carrying a transaction TO another member is a different function. The shared levels are not a roadmap item here; they are most of the job.

What you own proves your own records; the shared layers carry what goes to others. For most housing members the owned estate is almost nothing, and almost every transaction crosses. Both of those are the whole test of whether a structure can be adopted by the small as well as the large.

What one member can prove alone today

Three facts, and then the reason they are not enough here.

Your own nodes, your own edge, one hash, one anchor. Levels 3 and 4 are your nodes, level 5 is your edge, one cryptographic digest per transaction, and an anchor in a public ledger. Nothing else, and nobody else’s agreement. This is Mode A, which remains the only mode we offer for onboarding.

The public ledger is the neutral third party. It is what levels 1 and 2 would otherwise have to be, and it already exists — so the proof does not wait on an institution being founded, negotiated or funded.

Attestation is unilateral, and that is the limit. It holds whoever the counterparty was, which is exactly why it needs nobody’s agreement. But a provider buying from a carpenter is a cross-federation transaction, and in social housing almost every transaction is one. Mode A proves your own records and does not carry a transaction to another member.

The six levels

Three the member owns, three shared. The numbering says where a level sits in the network, NOT what rests on what: 3, 4 and 5 do not depend on 0, 1 and 2.

Levels 0, 1 and 2 are operated by no single member. Level 1 is BUILT — deployed at n=4 and committing; levels 0 and 2 are not yet usable. That is a statement about delivery and never about importance, and the three do not share one answer: Level 0 is not deployed at all, while Level 2 IS deployed and committing but has its gates unarmed and no regime rules defined, so nothing is evaluated. In housing Level 2 is simultaneously the hot path and the part not yet usable, which is the whole of what this page has to say.

What crosses at levels 3 and 4

Stated here because a reader who is not told will assume the opposite, and that misreading surfaces late, in security review, after the architecture has been agreed.

Both levels are the member’s own machines running the member’s own code. ITOTCCA operates nothing inside them and reads no transaction content. The only thing that leaves is TRANSMITTED METADATA, emitted by member-owned code: an entnum, and a hash of the metadata transaction-trace record. No balances, no counterparties, no payloads — and a hash is not reversible into the transaction it came from.

The metadata is the member’s data; its design and specification are ITOTCCA’s. Which fields exist, how the trace record is formed, and how it is hashed. Ownership of the data and authorship of the schema are different questions, and answering only the first reads as though the schema came with it.

Which shared levels your mode can use

Which of the three shared levels a transaction can actually use is decided by the MODE, because they do not all need the same thing from you.

Mode A needs none of them, and Mode A remains the only mode we offer for onboarding. Everything a member does WITH another member runs through here — for a clearing bank most of its business, for a social housing provider nearly all of it. That is the sentence worth reading twice before costing an integration.

The ladder and Level 2 pull against each other

Stated plainly rather than left to be discovered in a security review.

YOURS. At rungs 1 and 2 — plaintext, or the platform’s own key — we can read, so Level 2 evaluates FULLY. At rungs 3 and 4 — your key, or a named partner’s — we cannot, so Level 2 records THAT something crossed but never WHAT, and its regime function degrades to bookkeeping. A real trade, and yours to make.

NOT YOURS, and running the two together hides it. On ANY rung Level 2 ALSO needs its gates ARMED and regime rules DEFINED. Neither exists, both are OURS, and no rung you pick supplies either. At rung 1 — where everything actually runs today — Level 2 would read fully and still does nothing. So it is not a choice between them today: at every rung, Level 2 does nothing, and in housing Level 2 is the hot path. The ladder is not why; we are.

Keyed commitments are what would dissolve it. A key-holder proves a value matches what was committed without revealing the value, so a claim about a transaction can be verified without the transaction being seen. That layer is implemented across the relevant tiers and switched on in none of them — no commitments have been written in any running deployment.

So today you can have the upper rungs of the ladder, or Level 2 doing its job. Not both. The mechanism that would give you both is built and armed nowhere.

What counts as “like”

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.

A federation must be big enough to staff a committee. Amalgamate small trades until it is — the floor is set by n, not by the trade. Amalgamation here means only what this software system needs; it implies nothing about the trades themselves.

n is the size of a rotating COMMITTEE drawn from the membership, not the member count. A federation of forty members still runs 7, 10 or 13 nodes. 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.

Most housing members cannot operate anything. That is what forces membership and operation apart, and it is a better argument for the rotating committee than node-count economics ever was. The guild structure supplies the answer: a trade body already maintains a membership register, so it is the natural operator of its federation’s committee.

Sector-scoped federations keep buyers and sellers apart. If providers and merchants shared one pool the committee would be drawn overwhelmingly from providers, since they are the members able to operate — the parties who OWE money operating the ledger that records what they owe. Byzantine fault tolerance does not answer that: it protects against a MINORITY of bad actors and offers nothing against a majority with aligned incentives.

A residual remains, and is worth saying 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 independent witness is what makes a ledger run by the large acceptable to the small.

What housing depends on that is not usable yet

For banking these are roadmap items, because banking’s cross-federation traffic is a minority. For housing they are the main road, so they are stated here rather than found in month three.

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