We didn’t expect people to ask us about governance first. We expected them to ask about the names — which ones were available, how the pricing worked, whether they could use it for a website or a wallet. Those questions came. They still come. But before any of that, before the first address was registered, before the infrastructure was live, before anyone outside our team knew this project existed — we were sitting in a room answering questions that nobody outside that room was asking. Questions about what we were actually building, what responsibilities came with it, and what it would mean if we got any of it wrong.

This post is about that work. The invisible work. The kind that doesn’t make it into a press release or a product page, because it’s not a feature — it’s a foundation. If you’ve ever wondered what it actually takes to build something permanent, this is as honest an account as we know how to give.

What does it mean to build something that can’t be undone?

The word “permanent” is easy to say. We say it all the time, because it’s true — once an address is registered onchain, it’s recorded, it’s immutable, and it can’t be taken away by any registrar, any central authority, or any company including ours. That’s the point. That’s the whole point.

But when you sit with that word long enough, you start to feel its weight. Because permanence doesn’t only mean the good things are permanent. It means the mistakes are, too.

We spent a long time thinking about that before we opened the doors. If someone registers an address that turns out to be problematic — a word that causes harm, a name that belongs to someone else in a meaningful way, a string that becomes contentious after the fact — what happens? In a traditional domain system, there are mechanisms. Registrars can cancel. Registries can take back. ICANN has dispute resolution procedures. The system is built around the assumption that nothing is truly final, and that’s by design. A centralised authority always holds the master switch.

We don’t have a master switch. We chose not to have one, deliberately, because the entire promise of what we’re building rests on the idea that once you own something onchain, it is yours — not ours. Not the government’s. Not a registrar who decides your renewal is inconvenient. Yours. And that’s not a slogan. It’s a structural fact, and it comes with consequences.

So we had to answer a question that nobody was pressing us on: how do we handle the tension between true permanence and responsible stewardship? And we had to answer it before we issued a single address, not after.

The pre-registration problem nobody warned us about

When you’re launching a namespace tied to a real place — a state, a city, a globally recognised landmark — you inherit a set of pre-existing claims. Not legal claims, necessarily. Not formal claims. But moral ones. Reasonable ones. The kind that a functioning society would expect to be handled thoughtfully.

Who gets to register health.qld? Who should be allowed to hold police.brisbane? What about the name of a school that has existed for a hundred years, or a community organisation that’s been embedded in its neighbourhood for three generations — do they have a right to their name in this new namespace? And if they do, how do we protect that right before they even know this infrastructure exists?

These questions kept us up. Because here’s the thing: in a first-come, first-served system — which is how most domain systems work — whoever knows about the system first wins. Usually that’s the technologists, the speculators, the domain investors. The local surf club from Coolangatta doesn’t know there’s a new namespace called .gold-coast until someone’s already sitting on coolangatta.gold-coast and wants to sell it back to them. That’s not a failure of blockchain technology. That’s a failure of the humans who launched the system without thinking about who it was actually for.

We didn’t want to build that system. So before we opened registration, we had to think carefully about how to handle institutions, about what names warranted protection, about the difference between a name that clearly belongs to someone in any ethical sense and a name that’s simply valuable in a commercial sense.

We still don’t claim to have solved this perfectly. But we had to have the argument. We had to sit with the discomfort of it. We had to draw lines we knew would be imperfect, because the alternative — not drawing any lines — would have been worse.

What happens when the chain changes?

This is the question that technical people ask us sometimes, but almost never the general public. And it’s one of the most important questions in the entire project.

Blockchain infrastructure isn’t static. Networks upgrade. Consensus mechanisms change. Layer 2 solutions emerge and mature. Chains that seem robust today may be superseded by something better tomorrow — or may simply become less relevant, less supported, less economically viable. The history of technology is full of infrastructure that seemed permanent at the time and then quietly became archaeology.

We think deeply about this. Because when we say an address is permanent, we don’t mean it’s permanent on this version of this chain with these parameters forever — we mean the ownership record is permanent, the right is permanent, and the holder’s relationship to that address is permanent. The infrastructure layer beneath it is not immune to change, and pretending otherwise would be dishonest.

So we had to build a philosophy around chain governance that nobody asked us to build. What are our obligations if the underlying network changes materially? What does migration look like? What are the conditions under which we would consider it necessary, and what are the conditions under which we’d consider it a betrayal of what we promised? Who gets to make that call, and how?

The honest answer is that some of these questions don’t have clean resolutions yet — not because we’ve avoided them, but because the industry itself is still working through them. But what we can say is that we’ve asked them, documented our thinking, and committed to a set of principles that place the interests of address holders above the convenience of any infrastructure provider, including ourselves.

We also think about redundancy differently from how most tech projects think about it. In a traditional web context, redundancy means backup servers, failover systems, data replication across regions. In an onchain context, redundancy is partly a property of the network itself — the distributed ledger is its own backup. But it’s also about the metadata around your ownership: can you prove what you own in a way that survives any single point of failure? Can the record of your ownership be reconstructed even in an adversarial environment? These are questions we’ve built into the architecture of our thinking, not just our code.

Here is a truth about building onchain infrastructure for a real jurisdiction: the legal landscape is genuinely, sincerely, uncomfortably unclear.

We’re not operating in a legal vacuum — we know that. What we built exists in the world, and the world has laws, and those laws apply to us whether or not they were written with blockchain namespaces in mind. But the specific question of what an onchain address is, legally, in the context of Australian property law, consumer protection law, intellectual property law, and the various state and federal frameworks that govern commerce in Queensland — those questions don’t have tidy precedents.

Is an onchain address a licence? A piece of property? A digital asset? A service? All of these classifications carry different implications for how it can be sold, how it can be inherited, how it interacts with estate law when someone dies, what happens if there’s a dispute about who holds the private key, and how our own obligations as the issuing entity are framed.

We spent time with these questions not because we had lawyers standing over us demanding answers, but because we thought it was the right thing to do. If we were going to tell someone that they own this address for life, and for the life of their children, and that they can pass it down — then we had to understand what that claim meant in a legal sense, not just a technical one.

The uncomfortable conclusion we reached is that the legal framework hasn’t caught up with the technology in most respects. That’s not unusual. It was true of email, of websites, of social media accounts, of NFTs more broadly. The law tends to catch up eventually, and when it does, it tends to look at what actually happened in practice and construct frameworks accordingly. So part of what we’re doing — whether we like it or not — is contributing to a body of practice that will eventually inform how courts and legislators think about these things.

That’s a strange thing to reckon with. But we’d rather reckon with it honestly than pretend it doesn’t exist.

What we’ve tried to do is structure our obligations and our documentation in a way that would be legible to a court even if no precedent exists — to make our representations clear, our limitations explicit, and our commitments stated in plain language rather than technical jargon. Not because we expect to be taken to court, but because doing things properly means doing them in a way that could survive scrutiny.

The question of who speaks for place

Queensland isn’t an abstract concept. It’s a real place with real people who have a relationship with its name, its identity, its character. The Gold Coast is real. Brisbane is real. Surfers Paradise is one of the most globally recognised place names in Australia. When we secured those TLDs — .gold-coast, .brisbane, .surfersparadise, .qld, .queensland, .brisbane2032 — we were securing the digital future of names that belong, in a deep and meaningful sense, to the people who live there.

That’s not a small thing.

We had to think very carefully about what it means to hold the TLD for a place. In the traditional web domain world, ccTLDs — the country-code top-level domains, like .au for Australia — are administered under frameworks that attempt to align governance with national interest. ICANN has policies. There are technical management bodies. The relationship between the TLD and the territory it represents is at least nominally accounted for.

In the onchain namespace, there’s no equivalent framework. The relationship between a onchain TLD and the place whose name it carries is entirely a function of the ethics and intentions of the people who secured it. There’s no external body requiring us to act in the interest of Queenslanders. There’s no governance structure mandating that we make these addresses accessible, affordable, or equitable.

We found that concerning. Not about ourselves — we know what our intentions are. But concerning as a structural matter, because good intentions aren’t a governance framework. They’re not enforceable. They don’t bind future decisions. And if the people currently running this project were replaced by people with different intentions, nothing in the underlying technical architecture would prevent a scenario where .queensland became a speculative asset rather than a public resource.

So we had to build a set of commitments that go beyond good intentions. We had to articulate, as clearly as we could, what we believe the relationship between this project and the people of Queensland should look like — not in marketing language, but in operational language. What are the pricing commitments that ensure accessibility? What are the protections that prevent a land-grab by well-resourced actors at the expense of individuals? What is the governance philosophy that would apply if we ever had to make a decision that affected the namespace as a whole?

These aren’t questions anyone was demanding we answer publicly. But we couldn’t build responsibly without answering them privately first.

The problem with “forever” in a business model

There’s an economic tension baked into what we’ve built, and we want to be honest about it.

When you sell something once and promise it lasts forever, you are, by definition, not collecting recurring revenue from it. This is wonderful for the person who buys it. It is a real challenge for any organisation that needs to remain operational over time. And if the organisation that issued the permanent address ceases to exist — if the team disbands, if the entity winds up — then what exactly happens to the permanence that was promised?

The blockchain answers part of this question. If an address is onchain, it exists independent of the entity that issued it. The token is in your wallet. The record is in the ledger. If Queensland Foundation as an organisation ceased to operate tomorrow, your address would still exist. You would still hold it. It couldn’t be taken from you.

But the organisation’s services — resolution, nameserver support, the ability to point your address at a website, the human layer that supports the technical one — those things are not automatically immortal just because the ledger is. And this is a genuine responsibility we carry.

We’ve had to think very carefully about what we’re committed to provide over time, and what the economic model is that sustains those commitments. A one-time payment at the point of sale doesn’t fund operations in perpetuity unless the volume of new registrations remains sufficient to cover costs, or unless there are other economic activities that support the infrastructure. We’re not going to pretend this is a solved problem, because it isn’t one. It’s a design challenge that any onchain infrastructure project with a lifetime ownership model has to grapple with.

What we can say is that we’ve built our thinking around this principle: the durability of your ownership must not depend on our commercial success. The record is onchain. That’s the guarantee. Everything else — the services we provide, the tooling we build, the human support we offer — those are things we aim to sustain, and they’re things we work to make economically viable, but they are not the asset you bought. The asset you bought is on the ledger. That doesn’t go away.

The identity question, which is actually a dignity question

When we talk about digital identity, we’re used to talking about it in technical terms: wallet addresses, ENS records, human-readable names for payment routing, profile data, verifiable credentials. That’s all real and important.

But we kept coming back to a different framing. Not what is a digital identity for, technically — but what does it mean to a person to own their name, in their place, permanently?

There’s a reason surnames became important as societies formalised. There’s a reason addresses matter. Not just as routing mechanisms, but as statements of belonging. When you have an address, you have a place. You can be found. You can be reached. You exist within a system that acknowledges you.

Digital identity has never quite worked like that. You have a username that a platform can revoke. You have an email address hosted by a company that can shut down. You have a domain name that you have to remember to renew every year, and if you forget — or if you fall ill, or if your credit card details change, or if you’re going through something difficult — the domain expires and someone else can take it. The internet has never really offered people a permanent home. It’s offered them a series of temporary addresses at increasingly centralized landlords.

What we set out to build was different. Not just technically different, but philosophically different. An address that is yours in the same way your name is yours. Something that can be passed down. Something that reflects where you’re from, not just what product you’re currently using.

And when you frame it that way, a whole set of questions come up that never appear in a technical specification. What does it mean for a first-generation Queenslander to have smith.queensland? Not just the functionality of it — but the meaning of it. What does it mean for a family to hold a name in a namespace that reflects their home, and to hold it in perpetuity? Is that a trivial thing? We don’t think so. We think that’s actually quite profound, and the profundity of it increases our sense of responsibility for getting this right.

We had to ask ourselves: are we treating this with the seriousness it deserves? Are we building infrastructure that honours the weight of what it represents, or are we building a product and wrapping it in nice language? The difference matters. It changes how you make decisions when the easy path and the right path diverge.

The institutional claims problem

Some names in any namespace are not just personally significant. They’re institutionally significant. They’re names that entities — hospitals, councils, universities, emergency services — have been using in the public consciousness for decades. Names that people associate with safety, with authority, with trust.

Ambulance.qld. Police.brisbane. University names. Hospital networks. The State Government itself.

We had to think about these very carefully. Because there are two failure modes, and they pull in opposite directions.

The first failure mode is that we reserve nothing, and a speculative actor registers these names before the institutions do, and now those institutions either have to pay a premium to acquire their own name in this namespace or simply not participate. That’s a bad outcome. It undermines the legitimacy of the namespace and creates exactly the kind of land-grab dynamic that makes new digital infrastructure feel extractive rather than generous.

The second failure mode is that we reserve too much, in ways that are opaque or self-serving. We hold names that institutions haven’t asked for and may never want, creating an appearance of stewardship that is actually just inventory. That’s also a bad outcome. It’s a different kind of bad — more subtle, but still a betrayal of the principle that this namespace is for Queenslanders, not for the entity managing it.

Threading that needle required us to think about categories rather than specific names. What kinds of names fall into the category of “clearly belongs to a recognised institution in any ethical sense”? What criteria do we use? Who decides, and by what process? And how do we document that process in a way that’s transparent rather than arbitrary?

We don’t claim our answers here are perfect. We’ve tried to protect what clearly needs protecting, to remain conservative about the extent of those protections, and to be honest about the fact that this is a judgement call rather than a bright line. Judgement calls can be wrong. We’ve tried to make ours defensible, and we’ve tried to err on the side of the public interest.

What we talk about when we talk about stewardship

At some point in all of this deliberation, we realised that the word we kept returning to was stewardship.

We’re not just building a product. We’re not just operating a registration service. We’re the current custodians of a set of names that are tied to a real place and real people, and custodianship carries obligations that product development doesn’t.

A product can be deprecated. A feature can be removed. A company can pivot, and users can find alternatives. But you can’t deprecate the name of a city. You can’t pivot away from Queensland. The names we’ve built this infrastructure around will still matter to people in fifty years, in ways we can’t predict and in contexts we can’t fully imagine. And we will be, in some way, responsible for the condition in which we’ve kept the namespace when those future uses arrive.

That’s a genuinely unusual thing to sit with as builders. Most technology projects don’t require you to think in those timescales. You build something, you iterate, you respond to the market. The feedback loop is measured in weeks or months. But when you secure a TLD for a place, and you promise permanence, and the place itself will exist long after any current product cycle — the feedback loop is measured in decades. Maybe longer.

This doesn’t paralyse us. We’re not making every decision as if we’re writing a constitution. But it does change the texture of our deliberation. It makes us slower, in some ways. More careful about commitments. More honest about uncertainty. More resistant to the temptation to optimise for what looks good now at the expense of what will hold up over time.

The things we still don’t know

We want to end this honestly, which means ending it with the things we haven’t resolved.

We don’t know exactly how the legal landscape around onchain ownership will develop in Australia. We have views. We’ve thought carefully. But the courts haven’t spoken clearly, the legislators haven’t moved definitively, and the relationship between onchain property and traditional property law is still being written in real time.

We don’t know what blockchain infrastructure will look like in twenty years. We believe the chain we’re building on is robust. We believe in its longevity. But we hold that belief with appropriate humility, because the history of technology doesn’t reward certainty about specific platforms.

We don’t know whether the institutions we’ve tried to protect will ever come to us and say thank you, or whether they’ll be indifferent, or whether they’ll object to aspects of how we’ve handled things. We’ve acted in good faith. Good faith doesn’t guarantee good reception.

We don’t know all the edge cases. Someone will come to us eventually with a situation we haven’t thought of, and we’ll have to apply our principles to something genuinely novel and difficult. We’ll try to get it right. We might not. And in a namespace where mistakes are permanent, that’s something we carry.

What we do know is that we asked the questions. We sat with the discomfort. We built slowly, in some areas, because slow and right is better than fast and wrong when you’re building things that can’t be undone.

That’s the invisible work. Most of it will never be visible. Most of it shouldn’t need to be — because the goal of invisible foundational work is precisely that nobody notices it. You don’t notice good plumbing until it fails. You don’t notice responsible governance until it’s absent. You don’t notice that someone thought carefully about permanence until someone else builds something that didn’t think about it at all, and you can see the difference.

We’ve tried to build something that holds up when nobody’s watching it. Something that serves the people whose names are in it, long after the current team has moved on and the current conversations have been forgotten. Something worthy of the place it’s named after.

That’s the obligation we accepted when we secured these TLDs. We didn’t fully understand the weight of it at the time. We do now. And we’d make the same choice again.