There is a version of this project that nobody would have used.

It exists in our early notes, in the whiteboards we photographed and later deleted, in the conversations we had when we were still figuring out what we were actually building. That version was permanent, yes. It was technically correct. It was built on solid infrastructure that will genuinely outlast any company, any server, any renewal cycle. But it asked too much of the person on the other side. It asked them to understand things they had no reason to care about. It asked them to trust a process they couldn’t see and couldn’t verify without specialised knowledge. It was the kind of product that engineers admire and ordinary people abandon in the first thirty seconds.

We didn’t want to build that. And so we didn’t.

But the path from that version to the one we actually built — the one where permanence is real and the experience is genuinely simple — that path was not straightforward. It took longer than building either thing alone would have. It required us to hold two contradictory-seeming ideas in tension at the same time, for a long time, without letting go of either one. That tension is what this post is about.

The assumption we keep encountering

When people hear the word “permanent,” especially in the context of blockchain or onchain infrastructure, they tend to picture complexity. They picture seed phrases and wallet addresses and gas fees and browser extensions and a general atmosphere of things that could go wrong in ways that are hard to explain and harder to fix. They picture the early internet, but more technical. They picture something built for people who already know how it works.

That assumption is reasonable. It comes from experience. Most permanent, decentralised, onchain things have been complicated to use. Not because the people who built them didn’t care about usability, but because they were solving a different problem first — the infrastructure problem — and trusted that someone else would eventually solve the experience problem on top of it. That sequencing made sense in the early days of any technology. You build the foundation before you build the house.

But we didn’t want to be another foundation layer waiting for someone else to make it usable. We wanted to build the whole thing — the permanence and the experience — and we wanted those two things to feel like they belonged together, not like one was bolted onto the other.

The assumption that permanent means complicated isn’t just a perception problem. It’s a design challenge. And the only honest way to address it is to talk about what it actually took to design around it.

What permanence actually means

Before we can talk about simplicity, we have to be honest about what we mean by permanent.

Permanent does not mean “we promise not to turn it off.” It does not mean “we intend to keep the servers running.” It does not mean “as long as the company exists.” Those are not permanence. Those are intentions, and intentions are not infrastructure.

When we say permanent, we mean onchain. We mean that the record of ownership lives on a blockchain — a distributed ledger that no single entity controls, that requires no company to maintain, and that will continue to function as long as the network functions. We mean that what you own cannot be taken from you by a platform decision, a corporate acquisition, a server migration, or a business closure. We mean that the concept of expiry does not apply to what you’ve registered.

The six TLDs we’ve secured — .queensland, .qld, .brisbane, .surfersparadise, .gold-coast, and .brisbane2032 — are onchain addresses. They are not domain names in the traditional DNS sense, where a registrar issues you a licence to use something for a year and you pay again to continue. They are addresses that, once registered, belong to whoever holds the wallet that owns them. The blockchain is the registry. The blockchain is the authority. There is no intermediary whose continued existence is required for yours.

That is what we mean by permanent. And that definition has real technical weight behind it. It is not a marketing claim. It is a description of how the infrastructure works.

The first hard problem: permanence without permission

Building something that is genuinely permanent — not just long-lasting, but architecturally incapable of being revoked by any central party — required us to make decisions early that constrained everything that followed.

The most significant of those decisions was about custody. When you register an onchain address, who holds it? In the simplest technical implementation, the answer is: whoever controls the private key associated with the wallet that completed the registration. That is elegant and correct and also, for most people, completely inaccessible. The average person does not have a self-custody wallet. They do not want to manage a seed phrase. They should not have to learn what a seed phrase is in order to own a permanent address.

And yet if we custody addresses on behalf of users, we’ve introduced exactly the kind of intermediary that permanence is supposed to eliminate. If we hold it for you, then in some meaningful sense, the permanence is conditional on us. That is not what we want to build. That is not what we believe in.

The resolution to this tension is not simple, and it is not a single decision. It is a design philosophy that runs through every layer of the product. We think of it as: the permanence is in the infrastructure, the simplicity is in the experience. What that means in practice is that we build experiences that guide people toward genuine ownership — not toward a simplified version of ownership that we hold on their behalf.

That means onboarding that introduces the concept of a wallet without requiring people to already have one. It means abstracting away the complexity of key management without removing the reality of it. It means making the experience feel as simple as buying something online, while ensuring that what happens underneath that experience is genuinely, architecturally, permanently yours.

This is harder than it sounds. Every layer of simplicity we add on top requires that we not compromise the layer of permanence underneath. We have to test every design decision against a simple question: does this make the experience simpler, or does it make the permanence shallower? Those are not the same thing, and we cannot afford to confuse them.

The second hard problem: explaining what you own

The second challenge is conceptual, and in some ways it’s harder than the technical one.

When someone registers a .queensland address, what have they got? They’ve got something that doesn’t fit neatly into any existing mental model. It’s not a domain name, exactly, because it doesn’t work the way domain names work. It’s not an NFT, exactly, even though it is a token on a blockchain. It’s not a username, because it doesn’t belong to a platform. It’s not a piece of land, even though the ownership metaphor is closer than most.

It is a permanent onchain address. It is, in the most literal sense, a location in a decentralised address space that belongs to you, that points to whatever you want it to point to, and that will continue to belong to you for as long as you choose to hold it.

The challenge of explaining this simply — without either oversimplifying it into something inaccurate or overcomplicating it with technical precision that loses people — is something we have spent an enormous amount of time on. We have written and rewritten explanations. We have watched people read those explanations and noted where they stop engaging. We have tried analogies and discarded most of them. We have tried being more technical and found that it intimidates people. We have tried being less technical and found that it doesn’t fully capture what makes this valuable.

The explanation we keep coming back to is the simplest one: you pay once, you own it forever, no one can take it from you.

That explanation is accurate. It is also, deliberately, not complete. It leaves out the mechanism — the blockchain, the token standard, the onchain registry — not because those things are unimportant, but because they are not the first thing a person needs to understand. The first thing a person needs to understand is the outcome: what they have, what it does, and what it doesn’t require of them after they’ve got it.

We built the product to match that explanation. The experience should be as simple as the three-sentence description of it.

Simplicity as a design constraint, not a design choice

There’s a tendency to think of simplicity as something you add at the end. You build the complicated thing, and then you hire designers to make it look simple. You write the technical documentation, and then you hire writers to make it readable. Simplicity, in this model, is a coat of paint.

That is not how we think about it. Simplicity, for us, is a constraint — something that operates at the level of architecture, not aesthetics. It is a requirement that shapes what we build, not a quality that we apply to what we’ve already built.

This distinction matters enormously in practice. A system designed for simplicity from the beginning makes different choices at every level than a system that has simplicity applied to it afterward. The pathway through a registration — the number of steps, the information required, the decisions asked of the user — is not something you can easily retrofit. It is structural. If you build a ten-step process and then try to make it feel like three steps, you have not built a simple process. You have built a complicated process with a simplified interface on top of it, and the complication will eventually surface.

We designed backward from the user’s experience. We started by asking: what should this feel like? And then we asked: what does the infrastructure need to do to make it feel that way without compromising the permanence?

That order of operations — experience first, infrastructure second — is unusual in this space. Most projects in the blockchain world build the infrastructure and then figure out the experience. There are good reasons for that. Infrastructure is the harder technical problem, and you can’t build the experience until the infrastructure exists. But there is a version of that sequencing where the infrastructure is built without reference to the experience, and the result is a product that works but is hard to use.

We tried to avoid that by holding both things in mind at the same time. The infrastructure had to be permanent. The experience had to be simple. And neither could be built without reference to the other.

What we had to resist

There are pressures, when you’re building something like this, that push you toward complexity. They are not malicious pressures. Most of them come from places of good intention. But they are pressures toward making things more complicated than they need to be, and resisting them is part of the work.

The first pressure is the temptation to show your work. When you’ve built something technically sophisticated, there is a natural impulse to make that sophistication visible. To surface the blockchain mechanics. To show the token standard. To explain the architecture. This impulse comes from pride in the craft, and it is not a bad impulse. But it is often the wrong choice for the user. The user does not need to see how the engine works to drive the car. Showing them the engine does not add to the value of what they’ve bought. It adds to the cognitive load of the experience.

We resisted this. The technical infrastructure is real and it is important, but it is not the product. The product is the address. The product is the permanence. The infrastructure is what makes those things possible, and it deserves to be understood by people who want to understand it — but it should not be required of people who simply want to use it.

The second pressure is the temptation to add features. Every time we identified something the system could do, there was a conversation about whether we should surface it. Most of those conversations ended with us not surfacing it, or deferring it. Features add complexity, and complexity is the enemy of the experience we’re trying to build. Every feature we add is a decision we’re asking the user to make, a piece of information they need to hold, a new way things can go wrong. We add features only when they are genuinely necessary — not because they’re technically possible, not because they’re impressive, but because the experience would be meaningfully worse without them.

The third pressure — and perhaps the most insidious — is the pressure to hedge. In a technical space, there is always an urge to qualify everything. To add caveats. To explain exceptions and edge cases and the conditions under which something might not work exactly as described. This comes from technical honesty, which is a value we hold. But there is a version of it that results in explanations so full of qualifications that the core message is lost.

We try to be precise without being exhaustive. We try to say what is true without saying everything that is true. That is a harder editorial discipline than it sounds, and we get it wrong sometimes. But it is the right goal.

The geography of it

One thing that separates this project from generic onchain naming infrastructure is that it is specifically, deliberately, irreducibly Queensland.

This is not incidental. It is the whole idea.

The addresses we’ve secured are not abstract. They are .queensland and .qld and .brisbane and .surfersparadise and .gold-coast and .brisbane2032. They are named after places that exist, places that people love, places that carry identity and meaning and the weight of belonging somewhere. When someone registers a .brisbane address, they are not just acquiring a technical resource. They are planting a permanent flag in a digital address space and saying: this is mine, and it is Brisbane.

That specificity changes what permanence means. For a generic onchain address, permanence is a technical feature. For a .queensland address, permanence is also a statement about identity. You are not renting your connection to this place. You are not subscribing to it. You own it, in the same permanent, transferable, irrevocable way that you own anything that belongs to you.

We spent a long time thinking about why this geographic specificity matters, and we keep arriving at the same answer: because place is one of the most durable sources of identity that exists. People move countries. People change careers. People change beliefs, tastes, relationships. But the place where you grew up, the place where you feel at home, the place you think of when someone asks where you’re from — that tends to stick. It tends to be something people carry with them.

A permanent onchain address tied to that place is, in a small but real way, a permanent onchain expression of that identity. It is something you can own and keep and pass on, in the same way you might pass on anything that carries meaning.

That is a different kind of value than a domain name. And it is a different kind of value than a generic onchain identifier. The permanence of the infrastructure and the permanence of the identity reinforce each other.

Why the price is what it is

We set the starting price at five dollars. Paid once. No annual fees, ever.

We want to say something honest about why.

We could have priced this higher. In a pure market logic, the price of a permanent, non-renewable asset should reflect the lifetime value of what’s being purchased. A traditional domain name costs something in the range of ten to twenty dollars per year, and it never stops costing that. Over a decade, you’ve spent a hundred to two hundred dollars on something you still don’t own — you’ve just continued to licence. A permanent address, by that logic, is worth significantly more than five dollars.

We know this. We are not confused about the economics.

We priced it the way we did because we believe that the most important thing we can do right now is make genuine digital ownership accessible to the widest possible range of people. We believe that the value of this project increases with the number of people who participate in it — not in a speculative way, but in a real way. A digital address space is more meaningful when it is populated by real people with real connections to the place it represents. A .queensland address space full of Queenslanders is more valuable to every Queenslander than one owned by a small number of early adopters.

The five-dollar price is not a promotional tactic. It is a statement of intent. We want ordinary people to own this. We want the person who grew up on the Gold Coast and has never thought about blockchain infrastructure to be able to afford a permanent onchain address tied to that place, without having to understand the infrastructure to value it.

That means keeping the barrier as low as we can make it. And right now, that means five dollars.

What it means to build for permanence

Building for permanence changes how you think about almost everything.

It changes how you think about mistakes. When what you’re building is permanent, mistakes don’t have the same recoverable quality that they have in traditional software. You can patch a bug. You can update an interface. But you cannot un-register an address. You cannot re-architect the ownership model after the fact without breaking the guarantees you’ve made. This pushes us toward a kind of deliberateness — a slowness, even — that is unusual in a space that typically rewards speed. We move carefully because what we’re writing is hard to erase.

It changes how you think about trust. The whole point of onchain infrastructure is that it doesn’t require you to trust us. It requires you to trust the blockchain — a system that operates according to publicly verifiable rules and that is maintained by a distributed network of participants who have no special relationship with Queensland Foundation. Our role is to build on top of that infrastructure and to provide an experience that makes it accessible. But the trust that matters is not in us. It is in the system. And that is exactly how it should be.

It changes how you think about responsibility. When someone registers a .brisbane address, they own it. Not us. Them. That ownership is genuine — it is not contingent on our continued operation or our continued goodwill. And that means the act of helping someone register an address is not like selling them a subscription or issuing them a licence. It is closer to facilitating a transfer of something real. We take that seriously. We are not the custodians of what people own. They are.

It changes how you think about the future. Traditional software is built to be updated. Features are added, features are removed, interfaces change, terms of service change, the underlying infrastructure changes. Users adapt or they leave. With permanent onchain addresses, the ownership itself cannot be updated or revoked. What someone owns today, they own in twenty years. This means we have to build with a kind of temporal honesty — we have to be sure that what we’re offering is genuinely valuable for the long term, not just useful in the present context. We cannot deprecate an address. We cannot sunset the ownership model. What we build is what we’ve built, and it persists.

The combination no one talks about

There is a lot written about the difficulty of building permanent, decentralised infrastructure. There is a lot written about the difficulty of building simple, accessible consumer experiences. There is relatively little written about the difficulty of building both at the same time, in the same product, for the same users.

The reason, we think, is that most projects don’t try to do both. They pick one and excel at it, and they trust that the other will be solved by someone else, somewhere else, later. That is a reasonable division of labour for an industry. It is not the product we wanted to build.

The tension between permanence and simplicity is real. Permanence, done correctly, involves technical decisions that add friction. Self-custody introduces responsibility. Onchain transactions require gas, require wallets, require an understanding of irreversibility that traditional software transactions do not. None of these things are simple. All of them are necessary.

Simplicity, done correctly, requires removing or abstracting everything that isn’t necessary for the user to understand. It requires hiding complexity, smoothing friction, making things feel light and fast and obvious. This is at odds with surfaces that require careful decision-making. It is at odds with the weight that permanent decisions should carry.

The resolution we’ve arrived at is not a compromise between these things. It is a layering of them. The infrastructure is permanent and complex. The experience is simple. The permanent complexity lives underneath the simple surface, doing its work invisibly, so that the person on the other side can focus on what they actually care about: owning something real, something tied to a place they love, something that will still be theirs in decades.

That is the product we set out to build. It is the product we are building. The difficulty of it is not something we hide or minimise. It is something we think about every day, because the day we stop thinking about it is probably the day we start making the wrong kind of trade-offs.

The philosophy we keep returning to

We have a phrase we use internally, often enough that it has become something close to a mantra: the permanence is in the infrastructure, the simplicity is in the experience.

It sounds like a slogan. It is also, genuinely, the principle that has guided every significant decision we’ve made.

When we are tempted to add technical complexity to the user-facing experience because it would be more honest about what’s happening underneath, we return to this phrase. The experience does not need to be complex. The infrastructure is complex. That is its job.

When we are tempted to simplify the infrastructure in ways that would make the experience easier to build, we return to this phrase. The infrastructure must be permanent. That is its job. We cannot trade permanence for convenience in the layers that matter.

When we are trying to explain what we’ve built to someone who has never heard of us, we return to this phrase. It is a way of saying: we know these things seem like they shouldn’t go together. We built them to go together. That is the whole project.

What we believe about the people who will use this

We believe that most people do not want to understand blockchain infrastructure. They should not have to. The value of a permanent onchain address does not require any understanding of how onchain addresses work, any more than the value of owning a piece of land requires an understanding of the land registry system that records the ownership.

We believe that most people do understand the concept of owning something permanently. They understand the difference between owning and renting. They understand the value of something that doesn’t expire. They understand that paying once and never paying again is a different kind of deal from paying annually for the rest of your life. These are not sophisticated concepts. They are deeply intuitive ones.

We believe that the people who will value this most are not necessarily the people who know the most about blockchain. They are the people who feel something about the places these addresses represent. They are the Queenslanders, the Brisbanites, the people who grew up on the Gold Coast or in Surfers Paradise, the people who think of these places as home. They are the people for whom a .queensland address means something beyond its technical properties.

These are the people we are building for. And we believe they deserve something that works simply, even if it is built on something that is technically extraordinary.

Why we think this matters beyond Queensland

Queensland is the context. The principles are not.

What we are building — permanent onchain geographic identity infrastructure that is genuinely simple to use — is, as far as we can tell, a new kind of thing. Not in the sense that no one has thought of it, but in the sense that no one has built the full stack of it: the permanent infrastructure, the geographic specificity, and the simple experience, all together, for a real place and real people.

If we build it well here, the approach is replicable. Not by us, necessarily, but by anyone who wants to build something like this for another place. The philosophy is portable. The principle — that permanence belongs in the infrastructure and simplicity belongs in the experience — applies anywhere this kind of project might be built.

We think this is an important idea. Not important in a grand, world-changing sense, though we are not indifferent to large possibilities. Important in a specific sense: there is a way to build permanent digital infrastructure that does not require the people who use it to become technically sophisticated. There is a way to honour the full weight of what “permanent” means — architecturally, not just rhetorically — without making the experience of owning something permanent feel like a technical challenge.

That way exists. We know it exists because we are building it.

What we ask of the people who find us

We do not ask much. We ask that people take the concept seriously — not the technology, but the concept. The concept of owning a digital address permanently, the way you might own anything permanently, with no one’s permission required to maintain it.

We ask that people give the experience an honest look. Not a look informed by what blockchain products have typically felt like, not a look filtered through the complexity of past experiences in this space. A fresh look, at a thing that is new.

We ask that people think about what it would mean to plant a permanent flag in a digital address space tied to the place they are from, or the place they love, or the place they are building something in.

And we ask that people trust — provisionally, as one always should with something new — that permanent and simple are not opposites. That the difficulty of combining them is real, that we have done the work, and that what they are looking at is the result of that work: something that lasts, without making them think twice about whether it will.

That is what we built. That is what we believe in. And that is why permanent does not mean complicated.