Executive Summary

Summarising, what you get is a system that enables automated trading using Smart Contracts that are enacted on a private network, and where, due to the ability to share information with supply/health partners, using asymmetric cryptography, and also due to all database clusters acting as Masters in replication procedures, a partner organisation can access the shared data on their own local server. Sharing may also be completely revoked.

You also get a comprehensive Enterprise Application that works on Mobile devices and provides all accounting as part of the package, where the database we use (PostgreSQL) has zero licence fees, yet we can offer a 99.999% uptime guarantee (with Enterprise DB Support), excluding any down time due to the perpetration of “external” fraud (which will be detected by ChubbyChecker within minutes) and the subsequent investigations. The accounts system can be interfaced in a READ-ONLY fashion to your broader system. Or you may choose to convert all accounting to our system – which is quite possible and will be cheaper, and more secure, in all likelihood, than your present systems. We have the detailed understanding of Accounting Systems necessary to have built a fully integrated system from the ground up – we do not need to “partner” with insecure vendors, relying as they do on inferior software.

In addition you receive an economical and very security-conscious system, incorporating our ChubbyChecker Ultimate Cross-Checking package, which fills the security gap inherent in stand-alone distributed systems that employ either Crash- or Byzantine Fault Tolerance, as well as all the normal security measures such as client-side end-to-end encryption, together with the absence of risk of Man-In-The-Middle and Denial-Of-Service attacks (with our use of libp2p/Kademlia, bypassing, as it does, the normal Domain Name System – DNS). The distributed nature of the system is what allows the operation of private-networked Smart Contracts, incorporating unlimited volumes of data per contract (and overall), and also it is what allows the secure sharing of information, as necessary, to enable business/health operations to function efficiently.

But what is the magnitude of the risk against which we are protecting? According to an independent analyst organisation (Analysis) there were 25,949,000 personal records compromised in the healthcare sector in 2023 alone.
“These are often called ’supply chain attacks.’ In fact, it is not just one
customer that can be attacked, but essentially every customer that uses
an (inferior) vendor’s services. Thus, a single vulnerability can threaten
many thousands of organizations, such as in the 2023 MOVEit attack where
already over 2,600 companies in more than 30 countries admitted to
being attacked, with more than 80 million individuals’ data being
compromised. In fact, 98% of organizations have a relationship with an
(inferior) vendor that experienced a data breach within the last two years.
In some studies, the number of data compromises due to supply chain
attacks in 2023 jumped 78% over 2022.”
Stuart Madnick – Harvard Business Review
The problem is no longer a case of “if” but now a case of “when” will your systems be attacked.

There are many vectors by which attacks may be mounted. Our use of kademlia avoids some, however, still, the most common and “fruitful” means of attack involve targeting individuals using Social Engineering. As an example of Social Engineering, the attackers may use knowledge gained in any fashion about an employee’s vulnerabilities, contacting that employee and using this knowledge to obtain the employee’s cooperation in an attack or in the exfiltration of information from your database. It is very important to have multiple offline data backups in place in the case of an attack, which may also arrive in the form of Ransomware. The basic process involves the attackers accessing your data and re-encrypting the data to prevent your access, then demanding a Ransom for decrypting the data. If you have a good back-up system, and your data is strongly encrypted, this is simply not a problem. Note that the backups need to be kept offline and thus inaccessible to an infiltrator online.

In the case of a Ransomware Hack,
where (typically Russian) attackers gain access to a company’s
online data, the simple strategy necessary to survive the
attack is to ensure the maintenance of regular
(eg. half-hourly) backup procedures which MUST store the
backed-up (and, naturally encrypted) data OFFLINE so that no
network connection is presented for Hackers to access backups.
Thus, armed with encrypted backups, (all data both in-transit
and at-rest must be encrypted, not just backups) a company
can ignore Ransom Demands in the event of a successful attack,
and simply restore business data from offline backups, then
carry on with business (losing not more than a day’s work).
Better than paying 100’s of 1,000’s or millions in Ransom
to regain decrypted data, originally stolen by Hackers.

Security 101 in Business

– – It should be obvious that Business Data is very valuable, and – the above simple strategy of
a. encrypting all data and –
b. regularly backing up data to offline locations, should be: –

Security 101 in Business.

– – Of course, after such an attack, the company needs to harden the security of their systems to prevent further successful attacks. –
Talk to us. ‘The Minders’.

– – While the additional problems relating to “insider jobs” are – partially preventable by our higher-level systems, by – combining our security with the use of AI-led supervision of users, excursions of behaviour to criminal activities, – from within, can be prevented (see the Elastic Company) by systems using AI. These systems get smarter as they work. –
Also consider the number of people who send passwords via email to themselves as a record, or to others to access their account in an “emergency”. If these emails are compromised in external third-party attacks outside your system, your system may become compromised by a malicious agent. This touches on the concept of an Attack Surface, meaning the myriad vulnerabilities any system may have.

Thus, there is a multitude of possible attack vectors threatening your system. Sealing it with the use of kademlia goes a long way towards total security. But there are many other practices that should be used to defend against Hacking, Hijacking and System Penetration. We can only offer advice to be vigilant and aware of the size of the threat, and to take appropriate counter measures (and there are many measures to take). As noted elsewhere our use of client side encryption will assist, as will the frequent, programmed running of Backup operations (stored offline) and our ChubbyChecker. Insider jobs via Social Engineering techniques and third-party breaches are still high on the list of threats. Education of all staff can help here, as can monitoring of database access patterns, and vigilance (automated with AI) against abnormal patterns of use. Also, the use of Artificial Intelligence in this monitoring can make a difference when it comes to detection of “insider jobs”. An AI system can be trained to recognise excursions from normal usage patterns, and its performance is actually enhanced over time as it gains “experience”.

 

—————————————————————————–

Tx-Rails
Sovereign Name Resolution
(optional ADNS)

Move the connection-trust decisions that matter off DNS and onto a Byzantine-fault-tolerant peer-identity mesh — without rewriting your applications, and without surrendering the parts of DNS that still work.

DNS is the load-bearing component of global digital trust, and it is structurally insecure. There is no authentication of names; DNSSEC adoption sits below 3% for end-user domains; cache-poisoning, registrar hijacking, BGP-leak attacks on authoritative servers, and dangling-CNAME subdomain takeover have produced an actuarial loss profile that every cyber-insurance underwriter now prices into your premium without ever calling it that. The largest providers — Cloudflare, Akamai, AWS Route 53, Google Public DNS — are single points of failure with a track record of cascading outages, and they sit within jurisdictions whose courts and intelligence services can compel changes to your name-resolution path. The economy has learned to live with this gap because the incremental cost of any one DNS-mediated incident is borne by someone who isn’t pricing it back into the system. That is the delusion.

Tx-Rails Sovereign Name Resolution displaces DNS for the connection paths where the actuarial cost has finally exceeded what’s tolerable: financial-settlement flows, audit-evidence channels, supply-chain provenance APIs, regulator-facing inspection endpoints, multi-party contract execution, and any client-to-server flow whose compromise has reputational, regulatory, or counterparty-trust consequence. DNS continues to serve everything else — your marketing site, your public-blog CDN, your developer-docs portal. Your applications do not need to be rewritten. The high-value flows route through a cryptographic peer-discovery substrate that has no single point of failure, no central registrar, no court-orderable trust path, and an independently-verifiable record of every connection accepted.

---

What we displace

DNS today resolves names to IPs without authenticating either end. Tx-Rails Sovereign Name Resolution replaces that with three layers, in order:

1. Cryptographic peer identity (libp2p peer-IDs)

Every endpoint — every server, every API, every audit node, every contract-execution surface — has a cryptographic peer-ID derived from its public key. Connecting to that peer-ID is provably connecting to the holder of that private key. There is no name-to-IP indirection that an attacker can poison; the name is the public key.

2. Kademlia DHT for peer location (with enterprise-CA gating)

Peers find each other through a Kademlia distributed hash table that holds peer-ID → multiaddress records. Records are signed by their owners; the DHT is operated by the customer’s federation (and, where contracted, by ITOTCCA-operated co-validator nodes). Cross-jurisdiction discovery happens without depending on any third party’s DNS resolver. Combined with the wp-06 peer-identity verification layer, every routing-table entry is gated by a CA-signed cert that binds the peer-ID to the operator’s enterprise PKI — so a malicious peer publishing a poisoned record is rejected before it ever appears in a routing lookup.

3. Cert-pinned DoH for the bootstrap edge

The one place DNS is still needed is the initial discovery of the federation’s bootstrap peers. We solve that with wp-9A DoH (DNS-over-HTTPS) with SPKI cert-pinning: bootstrap-peer hostnames resolve via your nominated DoH provider, with the provider’s TLS public-key SHA-256 pinned in the client config. The result is a bootstrap path that is (a) encrypted in transit, (b) authenticated by cert-pinning (not by trust-on-first-use), and (c) verifiable against the federation’s published trust roots. From that one bootstrap, all subsequent peer discovery is over the BFT-consensused Kademlia overlay with zero further DNS dependence.

---

What we keep

We do not displace DNS for your public marketing properties, your CDN-fronted documentation, your developer portal, your blog, your image-hosting flows, your social-media login redirects, your office-network DNS, or any flow where the cost of a name-resolution incident is acceptable. DNS is fine for the things DNS is fine for. The pitch is not anti-DNS in principle; it is anti-DNS for the flows whose compromise has been quietly underwritten by your insurance premium for too long.

You also keep:

• Your applications unchanged on the wire. Three integration shapes are available — a libp2p SDK for native clients, a SOCKS5 / HTTPS-proxy shim for unmodified browsers + most legacy software, and a TUN-based virtual interface for fully transparent flows where the device supports it. Customers choose per-flow.
• Your load balancers, WAFs, CDNs at the DNS edge. Sovereign Name Resolution is in front of those for the flows it serves; the DNS-fronted flows continue through the existing stack.
• Your observability. Every peer-ID connection emits OpenTelemetry-compatible spans + ChubbyChecker audit events; existing SIEM / APM integrations consume them via the published collectors.
• Your IdP. SAML / OIDC redirects continue to land at DNS-resolved HTTPS endpoints; the connection to those endpoints, if it’s one of the high-value flows, runs over the cryptographic substrate.

 

---

Where it applies

This is the right substrate for any flow whose actuarial cost-of-compromise exceeds what current DNS-mediated trust can defend. Concrete examples across sectors:

• Defence + intelligence + sovereign: command-and-control APIs, classified-data exchange endpoints, multi-national-coalition information-sharing channels, anything that survives a hostile state-actor’s registrar-takeover capability.
• Critical national infrastructure (energy / water / transport / telco): ICS / SCADA management endpoints, emergency-mutual-aid coordination APIs, regulator-facing real-time disclosure feeds — the flows that NIS2, US CISA CIRCIA, the new Australian SoCI Act assurance regime are all sliding toward mandating verifiable transport for.
• Financial-settlement and central-bank flows: real-time gross settlement, cross-border payment-message rails, custody-record reconciliation. Where SWIFT bnPLUS, FedNow, and the various CBDC pilots are wrestling with how to authenticate counterparties without depending on commercial-DNS-mediated PKI.
• Healthcare under ransomware attrition: imaging / EHR / lab-result endpoints between hospital systems and across regional networks. The entry vector in the majority of post-2023 ransomware cases involves DNS-mediated phishing or watering-hole — closing the DNS surface for the flows that matter shrinks the attack surface materially.
• Sovereign-wealth + central-bank treasury: portfolio-management APIs, custodian reconciliation channels, regulatory disclosure rails. The CIOs of these organisations have been quietly looking for a DNS alternative for a decade; the technology is finally there.
• Building safety + construction post-Grenfell / Carillion: golden-thread evidence channels, certifier-to-regulator notification rails, retention-bond release endpoints. The trust failure that produced these regulatory regimes was the failure of the underlying records chain — and the records-chain substrate sits on DNS.
• Pharma supply-chain + cold-chain provenance: serialised-product traceability APIs, custody-of-evidence channels for cold-chain integrity, regulator-facing recall-execution flows. DSCSA / FMD compliance regimes assume verifiable transport that DNS cannot provide.
• Cross-jurisdictional supply chains generally: any flow where two organisations in different legal regimes need to exchange data without depending on a third country’s name-resolution sovereignty.

 

---

Why this is becoming inevitable, not optional

Cyber-insurance is repricing DNS-mediated risk. Premiums for organisations that cannot demonstrate transport-layer integrity beyond DNSSEC have risen 30-50% year on year since 2022. Carriers are increasingly excluding DNS-mediated phishing and registrar-hijacking losses from baseline coverage; they appear as priced add-ons or aren’t covered at all.

Regulatory framing is shifting from “use DNSSEC” to “demonstrate end-to-end name-resolution integrity.” NIS2 (EU), CIRCIA (US), Australia’s SoCI Act amendments, the UK NCSC’s draft 2026 guidance, the EU Cyber Resilience Act — all four are moving away from prescribing DNSSEC (which they know is barely deployed) and toward attestation requirements that DNSSEC-on-paper cannot satisfy.

Sovereign jurisdictions are quietly reconsidering root-server dependence. The discussion isn’t held in public, but it’s held. A name-resolution path that terminates in US-controlled root servers, with TLS roots controlled by US-incorporated certificate authorities, has been quietly identified as a strategic exposure by Five Eyes-adjacent allies, EU member states, and BRICS-aligned governments alike.

Ransomware actuarial data has shifted. Post-2023, the share of ransomware entry vectors involving DNS-mediated phishing or DNS-mediated watering-hole has crossed 70% by most major IR firms’ published numbers. The DNS surface is now the dominant attack surface, full stop, and security teams know it.

Quantum-readiness mandates are landing. NIST FIPS-203 / 204 / 205, EU PQC migration timelines, Australia’s PQC roadmap — all assume that the underlying transport substrate supports trust-anchor migration. DNS-as-trust-anchor does not; cryptographic-peer-ID-as-trust-anchor does, and the migration path is straightforward.

---

Architecture, briefly

• Bootstrap edge — cert-pinned DoH resolves the federation’s bootstrap multi-addresses (wp-9A). One DNS dependency, hardened to the limit DNS can be hardened.
• Peer discovery — Kademlia DHT operated by the customer’s federation + ITOTCCA-co-validator nodes (wp-9B). Peer-ID-keyed; no name indirection.
• Connection establishment — libp2p with Noise authenticated handshake, gated by wp-06 enterprise-CA peer-identity verification. Every successful connection is provably between two parties whose certs trace to the customer’s PKI root.
• Audit trail — every connection-accept, every connection-reject, every cert-rotation is committed to the ChubbyChecker BFT audit mesh and periodically anchored to a public DLT (Hedera) for jurisdiction-independent verifiability.

 

The customer-facing surface is one of three:

• libp2p SDK for native applications that can be modified or rebuilt
• Local SOCKS5 / HTTPS-proxy daemon for unmodified browsers + most legacy software (proxy config or HTTPS_PROXY env var)
• TUN virtual interface for fully transparent flows where the OS supports it

 

---

Indicative pricing

Pricing is per-pyramid + per-federation, calibrated against your deployment Shape (see [federation-trust-model.md](../federation-trust-model.md)). Sovereign Name Resolution is included in the base platform subscription; what changes per tier is the number of federations + cross-jurisdictional peer co-validator nodes operated on your behalf:

 

Customer profile	Typical deployment	Indicative A$ / year
Single-organisation, single-jurisdiction	1 pyramid, 1-2 federations (Shape 1)	50k – 150k
Multi-organisation or multi-jurisdiction federation	1-2 pyramids, 3-5 federations (Shape 2 grouped)	250k – 700k
Sovereign / supranational / critical-national-infrastructure	3-5 pyramids, 5-10 federations (Shape 2 or 3 sovereign)	1M – 3M

The pricing is calibrated against breach-cost avoidance, not against feature count. Engagements typically begin with a customer-led estimate of the actuarial cost of their current DNS-mediated risk surface — cyber-insurance premium attributable to DNS-mediated phishing / registrar-hijack / cache-poisoning vectors, SOC FTE attributable to DNS-incident remediation, and lost-contract opportunity attributable to procurement-RFP supply-chain integrity questions you cannot currently answer. The subscription is sized below that number.

Excluded: integration work by your IT team (your engineers, against our published SDK + SOCKS5 / TUN reference daemons) and any sovereign infrastructure you elect to host in-house vs on ITOTCCA-operated co-validator nodes. Pilot deployments use a separate timeboxed model (3-month parallel-run, walk-away clause — terms on request).

---

What we’d ask of you to start

Identify one flow whose compromise would be unacceptable — typically a regulator-facing endpoint, a counterparty-trust-bearing API, or a multi-party settlement channel. Move that one flow onto the Sovereign Name Resolution substrate via the integration shape that best fits (SDK / SOCKS5 / TUN). Keep DNS for everything else. At the end of the pilot you have:

• A verifiable connection-acceptance log for that flow’s complete history, signed by your federation, anchored to a public DLT
• A measurable reduction in the DNS-mediated attack surface for the flow that mattered most
• A concrete cyber-insurance conversation about whether the carrier will reprice the reduced-DNS-dependency posture
• A reference architecture you can extend to additional flows at the pace your operational appetite supports

 

We then have a real conversation about what that’s worth on your next NIS2 / SoCI / CIRCIA assurance audit, your next ransomware-readiness drill, your next cyber-insurance renewal, your next sovereign-wealth tender, or your next coalition-information-sharing agreement.

See the companion documents on this website for the audit-capture and business-process layers that consume the verifiable-transport substrate Sovereign Name Resolution provides.

Contact: john@itotchaincloud.com.au

Underlay! Underlay!

The underlay concept is to give you a Byzantine-fault-tolerant audit and ledger platform that sits **underneath** your existing systems. It binds tamper-evident chain-of-custody, automated compliance evidence, and independently verifiable proof, to the workflows you already run — without forcing your staff or customers to change a single screen. Australian-built, Australian-owned, deployable as sovereign infrastructure in your jurisdiction.

We are not a blockchain replacing your ERP. We are the integrity substrate that makes the records in your ERP — and your supplier’s ERP, your regulator’s report, your insurer’s claim — provably the same record, provably untampered, provably backed by independent witnesses.

How it works

Every transaction passes through a multi-layer Byzantine-fault-tolerant consensus mesh, with each layer mirrored by an **independent auditor mesh** (ChubbyChecker) that performs 129 cross-checks per transaction and per block. Every 24 blocks, a Merkle root is anchored to the **Hedera public distributed ledger** — giving you tamper-evidence verifiable from outside your own jurisdiction. The auditor’s trust root is mathematically independent of the workload’s; a compromise of one side cannot lie about the other. *This is the load-bearing safety property.*

 

In order to achieve this, there are 31 Metadata Fields that we require from you, encrypted with our Public Key, and sent to our Metadata Stores. They are shown at 31 Metadata fields

How you integrate (without rewriting anything)

Four modes, pick the one that fits how much change your IT team can absorb:

Tx-Rails — Four Integration Modes

The honest underlay story: 30 of 31 metadata fields land with zero changes to your data-entry screens. The 31st — semantic intent beyond CRUD — is opt-in per high-value flow. Pick the integration mode per workflow, not per organisation.

Every customer who hears the “tx-rails sits underneath your existing stack” pitch eventually asks the same question: if you don’t change my screens, how do you know who did what, why, and which transaction this row corresponds to? The answer is that 31 metadata fields per transaction describe the full audit context — and depending on which of four integration modes you choose for a given workflow (a variable choice between workflows), between 22 and all 31 of those fields land without screen changes.

The four modes trade integration invasiveness for metadata fidelity. Most customers run all four simultaneously, choosing per-flow based on what the audit consequence of that flow actually is.

---

The four modes

Mode	What customer does	Metadata fidelity	Use case
A. Hash-only	Nothing; tx-rails computes row-hash from CDC	22 / 31 fields, no semantic intent	Low-stakes flows where the audit just needs “this row existed at time T”
B. CDC observation	Adds Debezium / equivalent to their DB; nothing in the app	25–27 / 31 (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
C. Gateway-mediated	Routes API traffic through the tx-rails gateway; app unchanged	30 / 31 (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
D. SDK / atomic dual-write	App calls tx-rails alongside its own DB write	31 / 31 with explicit semantic intent	The very-high-value flows where the customer wants explicit REVERSAL / CORRECTION / RESTATEMENT tagging

---

What lands automatically (Modes A + B already)

22 of the 31 metadata fields are derived from infrastructure context — no customer code, no screen change, no integration work beyond pointing tx-rails at the customer’s database:

federationId, counterFederationId, entnum (from JWT), counterEntnum, txId, sector, counterSector, pyramid, counterPyramid, country, counterCountry, database, schema, table, recordId (from INSERT…RETURNING), hash (computed), clientNodeId, txSignStr, blockId, slabId, blockHeight, merkleRootHex, opCodeExec, opCodeCommit.

Mode B picks up another 3: reqType at the CRUD level (CREATE / UPDATE / DELETE comes free from CDC) and int64Amounts / int32Exponents (already in the row content).

Mode C picks up userId and roleId deterministically (they’re in the JWT that hits the gateway), plus tightens reqType from “CRUD level” to “semantic level” by inferring intent from HTTP path + verb.

Mode D adds the last field — explicit semantic-intent tagging for REVERSAL vs CORRECTION vs RESTATEMENT, where the application code has knowledge that no inference layer can reconstruct.

---

Choosing the right mode per flow

The decision is straightforward: how much does an unfaithful audit trail of this flow actually cost?

• • • A customer profile-edit screen on a public-facing app → Mode A. The audit needs to prove the change happened; semantic intent is unimportant.
    • An ERP master-data update with an audit_log table → Mode B. CDC sees the operation; the existing audit columns supply user + role.
    • A regulator-facing inspection-result submission → Mode C. JWT-derived attribution + semantic-intent inference; no app change required.
    • A multi-party settlement with REVERSAL semantics under FCA / APRA / Building Safety Act scrutiny → Mode D. Explicit, programmatic, defensible.

Customers typically deploy a mix: Mode A across the bulk of mid-traffic operational flows, Mode B for the master-data domain, Mode C across the public API surface where they own the gateway, and Mode D only for the small number of flows where an audit query in 10 years’ time will be unanswerable without explicit intent tagging.

---

What the four-mode story means for the underlay pitch

The pitch elsewhere in this site — IIoT, smart-contracts, sovereign-name-resolution — says “we sit underneath your existing stack.” That is true with caveats: it is unambiguously true for Modes A and B (which between them cover ~80% of typical customer surface area); it is mostly true for Mode C (a gateway-edge change is invisible to the application but visible to the network team); it is partially true for Mode D (a deliberate, scoped change to the application code for the high-fidelity flows).

We do not pretend Mode D is invisible. We do pretend nothing. The customer’s CFO and CIO choose which mode lives where, based on what an audit miss on that flow would cost in cyber-insurance premium, regulator fines, counterparty trust, or reputational damage.

Contact: john@itotchaincloud.com.au

(Edge cases — bulk data, air-gapped operation, data sovereignty preservation — are covered in [`underlay-integration-patterns.md`](./underlay-integration-patterns.md).)

What you get

• A regulator-ready audit trail**, automated, per-transaction, with cryptographic proof.
• Independent witness across every layer**, so an internal-fraud or operator-compromise scenario is detectable, not silently catastrophic.
• Sovereign hosting in your jurisdiction**, with cross-jurisdictional verifiability when you need it.
• No replacement of the systems your staff actually use.** The platform is invisible in normal operation; you call on it when you need to prove something.

 

___________________________________________________________

The Underlay! System is completely compatible with our Sovereign Name Resolution Overlay. Your traditional Systems reside above the Underlay and, if appropriate, also beneath the Overlay.

Australian Computer Society

IT/OT CHAIN & CLOUD AUSTRALIA PTY LTD

 

 

Honor Non Honores

Ut Filiae Lucis Ambulate

 

ADNS – Near-Absence of DNS –
Enterprise System (if Chosen)