Sovereign by Default — Owning Identity

There is a word that gets used a lot in infrastructure conversations without anyone stopping to define it precisely: sovereign.

Governments say they want sovereign digital infrastructure. Procurement documents demand it. Tenders require vendors to attest to it. And then those same governments register their public-facing services on .gov.au, hosted on a CDN incorporated in Delaware, resolved through a registrar whose terms of service reserve the right to suspend accounts for policy violations, all running under a TLD whose ultimate authority traces back to a California nonprofit operating under US law.

That is not sovereignty. That is a lease with a very long payment history.

This article is about what sovereignty actually means when you apply it specifically to the identity layer of digital infrastructure — to naming. It is about the hidden dependencies baked into ordinary web infrastructure, what onchain naming removes, what it does not remove, and why we designed Queensland with sovereignty as a default property rather than a feature you configure later.

What “sovereign” means, concretely

Sovereignty, in the infrastructure sense, is not about being disconnected from the rest of the world. A sovereign nation uses the international banking system. It still participates in treaties. Sovereignty is specifically about the conditions under which your participation can be terminated or modified by someone else without your consent.

Applied to a naming and identity layer, sovereignty has four testable properties:

Control. The organisation that registered the name — and only that organisation — can update its records, transfer it, or retire it. No administrator at a third party can act on the name unilaterally.

Permanence. The name does not expire on a calendar that someone else manages. Renewal requirements enforced by a third party are a form of conditional tenure, not ownership.

Non-revocability. The name cannot be seized, suspended, or redirected by a court order served to a third party who then acts on it without the owner’s knowledge or consent. The registrar, registry, or hosting provider is not a proxy enforcement point.

Jurisdiction-independence. The authority that governs the name is not subject to the laws of a specific nation-state in a way that creates asymmetric risk for the name’s owner.

If your current infrastructure cannot pass all four of these tests, you are not operating a sovereign identity layer. You are a tenant.

The hidden dependency stack in “normal” web infrastructure

Most institutions operating web services today have no clear mental model of their actual dependency stack. They think about their domain name. They rarely think about the five or six distinct authorities that can unilaterally affect that domain name without their permission.

Here is what that stack actually looks like.

Layer 1: The registrar

When a legal order is issued, the domain registrar plays a central role in implementing the necessary changes to the domain’s settings — this can include locking the domain to prevent updates or transfers, altering its DNS records to redirect traffic, or suspending its use entirely.

This is not a hypothetical. Legislation relating to online copyright protection gives companies that operate registries or act as registrars little or no incentive to fight a government seizure of a customer’s domain name. The practical result is that in most cases, the safer course for these companies — to ensure they are not exposed to liability — is to comply with government requests to shut down websites under their control.

Your registrar is not your ally. It is a conduit for enforcement actions from whatever jurisdiction it operates in.

Layer 2: The registry

Above the registrar sits the registry: the organisation that manages the top-level domain itself. .com is managed by Verisign. .au is managed by auDA under Australian policy. Each registry has its own policies about what it will do under court order, government request, or policy change. You have no direct relationship with the registry. You have no contract with them. And they can act on your domain regardless.

Layer 3: ICANN policy

At the top of the DNS structure sits ICANN — not as a resolver, but as the coordinator of authority across the DNS ecosystem. ICANN defines who is authoritative over which parts of the DNS namespace and manages the root zone through IANA.

Critics argue that despite the IANA transition, the US retains significant de facto control over DNS through jurisdictional authority over ICANN and the registries that operate major TLDs. This is not a conspiracy theory. ICANN is prevented from contracting with domain registries or registrars in sanctioned countries, limiting their participation in the domain name economy. The policy levers exist. They have been pulled. The question is only whether they will be pulled in your direction.

Layer 4: The hosting jurisdiction

Even if your domain name survives all of the above, your actual content, your services, and your infrastructure live somewhere — in a data centre, on a cloud provider, inside a jurisdiction. Companies have been delegating the task of maintaining their authoritative nameserver records to third-party DNS providers, and this delegation has been increasing over the years, leading to a current scenario where DNS resolution is concentrated on a small number of large providers. Disruptions on DNS infrastructure providers — due to cyberattacks or sabotage — could lead to collateral damages to multiple DNS domains.

Every one of these layers is a point that someone else controls. When institutions discover this, the usual response is to call it “acceptable risk” or “industry standard.” That is true. It is the industry standard. It is also a design decision that can be changed.

What seizure actually looks like

When a domain is seized, the owner loses access to its WHOIS data, DNS settings, and all associated services, leading to complete loss of control. Services linked to the domain become unreachable. Email stops. Customer portals go dark. And in such cases, domain owners have found that legal recourse within the same jurisdiction is often ineffective, as courts may side with the government or refuse to hear the case altogether.

Rebuilding customer trust and search engine rankings after a domain loss is a long and difficult process, often requiring extensive marketing efforts and financial investment.

For a commercial entity this is a serious disruption. For a government or public institution — whose identity is its authority — it is a legitimacy crisis.

What onchain naming actually removes

Decentralised naming services like ENS operate on blockchain technology, distributing control among network participants. ENS maps human-readable names to Ethereum addresses and other resources using smart contracts, ensuring that no single entity has overarching control.

The important shift here is not “decentralisation” as an ideology. It is the specific removal of each intermediary layer described above.

Unlike the conventional DNS system where domain ownership depends on continued payments to centralised registrars and compliance with government regulations, onchain names are owned cryptographically and cannot be seized, censored, or revoked by external authorities once properly secured.

These naming systems are operated outside of the global Domain Name System, and because they are not part of the global DNS, blockchain name systems are able to choose any names they want, without asking permission of any other organisation.

The registrar layer disappears. The registry is the protocol itself, governed by code and open governance rather than a corporate entity subject to any single jurisdiction’s courts. The ICANN dependency disappears. The hosting jurisdiction dependency shifts: it does not disappear entirely, but it is no longer a single point of failure for identity.

Decentralised domain technologies are increasingly being explored as a way to prevent the need for domain restoration in the first place. Blockchain-based domains, which operate outside of the traditional DNS system, offer a level of resilience against seizures by ensuring that no single authority has the power to take down a domain.

For a public institution, this matters in a specific way. The institution’s identity — its name, its addresses, its published records — should be as durable as its legal mandate. If the legal mandate survives a change of government, a geopolitical dispute, or a policy shift at a US nonprofit, the identity layer should too.

The honest limits — a builder’s account

I am not going to oversell this. There are real trade-offs, and institutions considering onchain naming need to understand them before they commit.

Key management is the hardest problem

Sovereignty secured by a private key is only as sovereign as the organisation’s ability to manage that key securely across time. Most public sector organisations do not have mature key management practices. A lost private key is not a support ticket — it is permanent loss of control over whatever that key governed. Key ceremony design, multi-signature governance, hardware security modules, and succession planning are all prerequisites for this model to work, and they take institutional effort that is currently underestimated.

Resolver support is still uneven

Modern systems increasingly rely on offchain data to scale resolution. ENS’s CCIP-Read standard formalises this pattern by allowing resolvers to fetch external data while retaining onchain verification. This reduces gas costs and enables dynamic records but introduces new attack surfaces. If offchain endpoints are unavailable or manipulated, resolution can fail even when ownership remains intact.

The practical consequence is that onchain names are not universally resolvable in standard browsers today without configuration or a gateway. This is a real usability gap for public-facing services. It is narrowing, but it has not closed.

UX maturity is improving but not finished

Blockchain UX is still harder than it should be. Users struggle with seed phrases, chain switching, token approvals, bridging, gas fees, failed transactions, and signing messages they do not understand. Public sector employees are not blockchain-native. Tooling designed for individual crypto users does not map cleanly to institutional workflows. This is solvable with good product design, but it does not solve itself.

Governance risk does not disappear, it changes shape

Durable identity systems require coordination, interoperability, and careful stewardship of shared infrastructure. Onchain naming systems are governed by DAOs or similar mechanisms. A single governance decision can alter the technological trajectory of a protocol that processes millions of name lookup requests daily. The governance risk is different from the jurisdictional risk of traditional DNS — it is more transparent, more auditable, and harder for any single state actor to capture — but it is not zero.

Why we built Queensland sovereign by default

When we designed Queensland, the identity architecture decision was made early and deliberately: Queensland names are onchain from the start, not as a configuration option, not as a premium tier, not as something institutions opt into after the fact.

The reason is simple: sovereignty is not an add-on. Once an institution has established its identity on traditional DNS — has published that domain in documents, in legislation, in public-facing systems — migrating off it is an extremely expensive and disruptive process. The path of least resistance is to keep the old infrastructure and add the new layer alongside it, which means the old dependencies remain, and the sovereignty properties of the new layer are never fully realised.

Building a namespace people can rely on across wallets, applications, exchanges, and the traditional web is far more difficult than simply issuing names. We had to make the decision at the architecture level, before institutions were locked into legacy patterns, because after the fact it is too late.

The Queensland identity layer gives institutions control over their own records. It does not expire on a third party’s renewal calendar. It is not subject to suspension by a registrar complying with a court order served in a foreign jurisdiction. The authority structure is explicit, auditable, and independent of any single nation-state’s policy framework.

That is what sovereignty means, concretely. Not disconnection. Not ideological purity. Control, permanence, non-revocability, and jurisdiction-independence — tested against the actual dependency stack of the infrastructure you are operating.

Analysing digital sovereignty is crucial because it ensures a country’s autonomy, control, and security over its digital infrastructure. Efforts to quantify dependency on external providers are required to uncover possible sovereignty risks for nations and their critical infrastructures — including healthcare, banking, and education sectors.

A government that cannot answer the question “who can take our name away from us, and under what conditions?” is not operating sovereign infrastructure. It is operating infrastructure where nobody has asked that question yet.

We asked it first. Then we built the answer in.