We want to start with something that sounds almost contradictory for a team that has spent years deep in blockchain infrastructure: we don’t think most people should ever have to think about blockchain.

Not for a second. Not during sign-up. Not when they claim their address. Not when they hand it to their kids one day. The technology should be doing its job so quietly, so completely, that it simply doesn’t register as technology at all. It should feel like filling in a form. It should feel like getting the keys to something that was always yours.

That’s the design philosophy we keep coming back to, the one we argue about in long calls and revisit every time we make a build decision. And it’s harder to get right than anything else we’ve tried.

The thing about blockchain that nobody talks about

There’s a version of blockchain thinking that fetishises the complexity. The wallets, the gas fees, the private keys, the seed phrases written on paper and stored in fireproof safes. The jargon. The rituals. The sense that to participate, you have to earn your place by first understanding a dozen things most people have never needed to understand before. There are communities built around that complexity, and we’re not dismissing them — they’ve built extraordinary things. But that world, as it stands, excludes almost everyone.

Poor UX design remains a critical bottleneck for broader adoption, and clunky interfaces with complex navigation actively deter everyday people from engaging with blockchain-based services. We didn’t need a report to tell us that. We just needed to watch someone try to claim something onchain for the first time. The moment they see the word “wallet”, the moment they’re asked to write down a seed phrase, the moment a transaction fee appears — the moment any of that happens — the experience has already failed. Not because those things are wrong. But because they’re not the point.

The point, for us, has always been the address. The thing a Queenslander can call theirs. The name they give their home in a digital landscape that’s going to matter more and more as time passes. Whether that address lives on a blockchain is, from the user’s perspective, a completely irrelevant detail. It’s like explaining the TCP/IP protocol to someone who just wants to send an email.

The question that has driven every decision we’ve made is this: how do we give people something real, something permanent, something genuinely owned — without making them learn anything they don’t want to learn?

What we mean when we say “invisible”

Invisible doesn’t mean hidden. It doesn’t mean we’re obscuring what we’ve built or pretending the technology isn’t there. It means we’ve done the work so thoroughly that the seams don’t show.

Think about how electricity works. You press a switch and light appears. The fact that there are generators, transmission lines, transformers, wiring hidden in your walls — none of that is your problem when you want to see in the dark. The infrastructure exists, it’s real, it’s doing something profound, but it knows its place. It doesn’t demand acknowledgment. It just works.

The complexity is not removed — it is abstracted. It lives beneath the surface, available to anyone who wants to look, invisible to anyone who does not. That’s the sentence we think about a lot. Because when you’re building on blockchain infrastructure, there’s a temptation to believe that the complexity is the product. It’s not. The complexity is the cost of building something that lasts. The product is permanence. The product is ownership. The product is a family in Brisbane having an address that belongs to them and no one else, forever.

Getting to “invisible” requires a particular kind of discipline. You have to be willing to do enormous amounts of work so that someone else never has to. You have to solve problems in the background that most people won’t ever know existed. You have to make decisions that will never earn you credit because, done correctly, they’ll never be noticed.

That’s the work we chose. And it shapes every line of what we build.

The honest reality of building for non-technical people

We want to be direct about what this actually requires, because it’s easy to say “we made it simple” and much harder to explain what simple costs.

Blockchain technology deals with constraints that don’t exist in traditional software: transactions are irreversible, wallet addresses are cryptographic strings of forty or more characters, and every action carries a real-time fee. Users can’t rely on “contact support” to undo a mistake. These aren’t minor inconveniences to smooth over. They’re structural realities of the technology. The immutability that makes a permanent address actually permanent is the same immutability that makes errors irreversible. The decentralisation that means no one can take your address away is the same decentralisation that means there’s no central authority to call if something goes wrong.

Building for ordinary people within those constraints requires a kind of translation that runs all the way through the product. You can’t just put a friendly interface on top of a hostile process and call it done. The friendly interface will crack under the weight of what’s underneath. Every edge case, every error state, every unusual configuration — they all have to be handled before they reach the person in front of the screen.

We think about a specific kind of person constantly during this process. Not a developer. Not someone who holds crypto or thinks about blockchain at all. Someone who owns their home, knows their suburb, cares about their community, and when they hear that there’s a permanent address in their name sitting on the internet — a .brisbane or a .queensland or a .surfersparadise — they feel something. They feel like it’s worth claiming. They shouldn’t need a tutorial. They shouldn’t need to understand anything except the fact that this thing exists, it’s theirs for a very small one-time cost, and the process of getting it should feel no more complicated than buying something from an online store.

That standard — that specific, demanding, ordinary-person standard — is the one we hold ourselves to. It’s harder than building for developers. Developers are patient. Developers understand error messages. Developers can read documentation and figure out what went wrong. Regular people have lives to get on with. They’ll give you one chance, maybe two, before they close the tab and never come back. The infrastructure has to earn that trust in seconds, not paragraphs.

Why we’re suspicious of crypto-native thinking

There’s a pattern in the blockchain world that we’ve come to recognise and actively resist. It’s the tendency to design products for people who are already believers — people who already have wallets, already understand gas, already know what “mint” means in this context. The reasoning is understandable: those people are the early adopters, they’re willing to tolerate friction, they’ll spread the word. Build for them first, figure out the mainstream later.

This creates what has been called a “GitHub problem” — tools optimised for developers but inaccessible to mainstream users, creating a design philosophy that prioritises crypto-native users over the broader public.

We made a different bet from the start. We built for the mainstream first. We built for Queensland families, for small business owners, for people who think of the internet as a place they use, not a technology they understand. We made that bet because we believe the value of permanent onchain addresses is not a crypto story. It’s a Queensland story. It’s about identity, community, belonging, and the quiet satisfaction of owning something real in a world where most of what we think we own online can be revoked at any moment.

The crypto-native path would have been easier in some ways. You can ship faster when you don’t have to abstract anything away. You can lean on existing wallets and existing mental models. You can assume your users will tolerate gas fees and confirmation delays and the occasional cryptic error message. But you lose the people you actually want to reach — the people for whom this thing could genuinely mean something.

There’s another reason we resist crypto-native thinking, and it’s more philosophical. If the goal is permanence — if we’re genuinely building something meant to last for decades — then we can’t afford to tie the experience to the current state of blockchain UX. Current blockchain UX is, in many respects, still being invented. Wallets work differently depending on which one you use. Gas mechanisms vary. Conventions around signing and confirming transactions are not standardised. If we build an experience that assumes familiarity with all of that, we’re building something that will feel dated the moment those conventions shift, and they will shift.

Despite blockchain technology’s revolutionary potential, many decentralised applications struggle with adoption due to poor user experience. The gap between blockchain’s technical complexity and user-friendly interfaces remains one of the industry’s biggest challenges. We’re not going to pretend otherwise or paper over it with optimism. We just think that gap is a design problem, not an inherent limitation. And design problems can be solved.

The architecture of abstraction

So what does the actual work of abstraction look like? What does it mean in practice to build a layer that sits between blockchain infrastructure and a Queensland family claiming their address?

It means thinking about every touchpoint in the journey and asking: what does this person actually need to know right now? And ruthlessly cutting everything else.

When someone claims a .brisbane address, they don’t need to know which blockchain that address lives on. They don’t need to know about smart contracts, or what a smart contract is, or why smart contracts make the ownership permanent rather than conditional. They don’t need to understand wallets in the traditional blockchain sense. They need to know the name they want, they need to know what it will cost them, and they need to know it’s theirs after that, forever, with no further charges.

Everything else — the contract execution, the onchain record, the immutable ledger entry — that happens in the background. It happens reliably, verifiably, permanently. But it happens beneath the surface. Chain abstraction of this kind allows users to access services without having to worry about the details of the underlying blockchain, such as transaction fees and blockchain interactions, providing a more intuitive and simplified user experience.

The technical layer also has to handle failure gracefully. One of the realities of working on any network infrastructure, blockchain or otherwise, is that things occasionally don’t go as expected. Transactions can take longer than anticipated. There can be moments of congestion. The difference between a product people trust and a product people abandon often comes down to how it behaves when something doesn’t go perfectly. Does it give a cryptic error code? Does it leave the user stranded, unsure whether their transaction went through or not? Or does it remain calm, provide reassurance, and handle the recovery quietly? We built for the third option. Every error state is handled. Every edge case has a path through. The user should never feel like they’ve lost something or broken something, even when the network is being difficult.

There’s also the question of language. The vocabulary of blockchain is opaque by design — not intentionally hostile, but developed by and for people who were building the infrastructure rather than using it. Words like “mint”, “hash”, “gas”, “wallet address”, “smart contract” — these are perfectly sensible words in context, and we use them ourselves all the time. But they don’t belong in the experience we’re building for Queensland families. The language we use has to meet people where they are. An address is an address. Claiming it is claiming it. Owning it is owning it. The permanence is explained not in technical terms but in human ones: you paid once, you own it, no one can take it from you, it doesn’t expire.

On permanence as a design principle

Permanence is the heart of what we’ve built, and it shapes the infrastructure decisions in ways that aren’t immediately obvious from the outside.

When we say a Queensland address is permanent, we mean something specific and technical: the ownership record lives on a blockchain, it’s immutable, and it doesn’t depend on any company continuing to operate or any server continuing to run. It’s not a subscription that quietly lapses. It’s not a lease from a registrar who can revoke it. It’s an onchain record, and as long as the chain exists, the record exists.

But permanence as an experience — permanence as something a person can feel and trust — requires more than just the technical substrate. It requires that the claiming process itself feels conclusive. When someone claims their address, they need to feel the finality of it. There shouldn’t be a nagging sense of “is this really done?” There shouldn’t be renewal reminders arriving in their email in twelve months. There shouldn’t be any mechanism that re-introduces uncertainty. Done means done. Owned means owned.

This has implications for how we communicate about the product, but it also has implications for how the infrastructure is designed. Every layer — every piece of the stack between the blockchain and the person in front of the screen — has to be built with the same understanding of permanence that the chain itself embodies. If we introduce ephemeral elements into the system, we undermine the thing we’re building. The stack has to be as committed to permanence as the chain.

This is actually one of the places where building on blockchain infrastructure makes the design easier in a meaningful way, even if it makes the engineering harder. Because the permanent record doesn’t depend on us. We’re not the custodians of those addresses. We built the process by which they come into being, but once they’re onchain, they exist independently of us. That’s an extraordinary design constraint to work within — extraordinary because it demands rigour, but also because it means we can make a promise to Queenslanders that very few platforms can make: this thing will outlast us.

The comparison that keeps coming up

When we talk about invisible infrastructure, people often bring up the internet itself. The domain name system. The way anyone can type a name into a browser without knowing anything about IP addresses or DNS resolution. The way the whole complexity of routing packets around the globe disappears behind a single text field.

That analogy is useful, and we think about it a lot. The internet’s domain name system simplifies user experience by turning machine-readable IDs into names that people can actually read and understand. That work of translation — from technical address to human name — is exactly what made the web accessible to everyone, not just to the engineers who built it.

But there’s an important difference between traditional domain names and what we’re building. Traditional domain names are leased, not owned. You pay for them annually. The registrar holds the underlying record. ICANN sets the rules. Traditional domain name systems are managed by centralised authorities that oversee the registration and resolution process, and this centralisation can lead to vulnerabilities including censorship and single points of failure.

What we’re building has that same quality of human-readability — an address that looks like a place, that means something to the person who holds it, that they can give to their children and to strangers and put on their business — but underneath, the ownership structure is completely different. Onchain naming services operate on blockchain technology, distributing control among network participants, ensuring that no single entity has overarching control and providing greater resilience against failures, aligning with the principles of user sovereignty inherent in blockchain ecosystems.

The challenge is making that difference legible to ordinary people without explaining blockchain. The story we tell is simple: you own it, forever, because it lives on a permanent record that no one controls. That’s the whole explanation. Everything technical underneath that sentence is the infrastructure doing its job invisibly.

What we got wrong, and what we learned

We’d be telling a dishonest story if we pretended the invisible-infrastructure philosophy came fully formed. It didn’t. We made assumptions early on that turned out to be wrong, and working out why they were wrong taught us most of what we know about this problem.

The first assumption was that simplifying the interface was sufficient. If we stripped out the jargon and made the steps clear, people would be comfortable. What we discovered is that the interface is only part of the challenge. The experience of claiming something onchain carries weight even when you’ve hidden all the technical mechanics. There’s a moment in any onchain transaction — however abstracted — where something real is happening. A permanent record is being created. Money is changing hands. And people feel that weight, even when they can’t name what’s causing it.

That feeling, it turns out, is not something you eliminate. It’s something you honour. The experience needs to be serious enough to match the seriousness of what’s happening. It should feel like a small ceremony. Not technically intimidating — never that — but not trivially lightweight either. There’s a dignity to permanence that the experience needs to reflect.

The second thing we got wrong was underestimating how much trust has to be built before someone is willing to proceed. In the blockchain space, there’s a lot of scepticism — some of it very well earned — and ordinary people who have no particular knowledge of the field still carry a residual caution about anything that sounds like it might involve crypto. We had to think carefully about how to address that without leaning into blockchain language that would either alienate or confuse.

The answer we came to is one of the more important things we’ve learned: you build trust through simplicity and transparency, not through assurance. You don’t build trust by saying “don’t worry, this is safe.” You build trust by making the process so clear, so comprehensible, so obviously fair that worry doesn’t arise. Every piece of friction removed is a piece of anxiety removed. Every ambiguity resolved before the user encounters it is a barrier cleared. Trust isn’t a feature you add. It’s what remains when you’ve removed everything that undermines it.

The people who will never think about any of this

There’s a family somewhere in Queensland — let’s say in the western suburbs of Brisbane, or on the southern end of the Gold Coast, or in a house near the coast with a view of the water — who will one day claim an address. Maybe it’s the name of their family. Maybe it’s the name of their street combined with their suburb. Maybe it’s something that means something to them and no one else. They’ll spend five dollars. They’ll spend ten minutes. They’ll finish, close their browser, and think very little about the process, because the process was unremarkable.

They’ll think about the address, though. They’ll tell people about it. They’ll think of it as theirs. They’ll feel something about the fact that it belongs to them and will keep belonging to them without any more effort or expense. That feeling has nothing to do with blockchain. It has nothing to do with smart contracts or immutability or decentralised record-keeping. It has to do with ownership, and identity, and the particular quiet satisfaction of having something that is genuinely and permanently yours.

That family is who we’re building for. They’re the test that every decision has to pass. Not “is this technically correct” — though it must be. Not “is this consistent with blockchain best practices” — though it should be. But: would this confuse that family? Would it make them hesitate? Would it require them to know something they don’t want to know?

If the answer to any of those questions is yes, we’re not done yet.

For Web3 to go mainstream, it needs to stop looking like a niche experiment and start feeling like a practical tool. We agree with that completely. And we’d add one thing: it needs to stop asking people to care about the infrastructure. The infrastructure is not the point. What the infrastructure makes possible — that’s the point.

The deeper reason this philosophy matters

We want to be honest about why we care so much about invisible infrastructure, beyond the practical goal of making the product accessible. There’s something more fundamental at stake.

Blockchain technology has been treated, in much of its short history, as a destination in itself. The technology is the story. The token is the product. The mechanism is what people are meant to admire. We’ve never believed that. We believe blockchain is a means to an end, and the end — in our case — is a particular kind of permanent, sovereign digital ownership that wasn’t possible before.

The moment that technology becomes the story, you’ve lost. You’ve turned a tool into a religion, and tools that become religions serve the believers and exclude everyone else. Queensland is not a crypto community. It’s a place. It’s four and a half million people living real lives in a state they’re proud of, with suburbs and beaches and cities they identify with. Our job is to give those people something that uses the most durable, uncensorable, permanent record-keeping infrastructure available — and to make sure they never need to think about what that infrastructure is.

That discipline — building something serious enough to be permanent and simple enough to be for everyone — is the hardest thing we’ve done. It requires holding two things in mind simultaneously: the full technical weight of what’s underneath, and the complete indifference to that weight that the person in front of the screen is entitled to feel.

Even the most revolutionary projects will struggle to gain traction without intuitive interfaces that make complex technology accessible to average users. We’ve seen that play out, over and over, across the blockchain space. Brilliant engineers building extraordinary infrastructure that almost no one uses, because the experience demands a degree of technical literacy that most people don’t have and shouldn’t be required to develop.

We don’t want to add to that pile. We want to build the kind of thing where the technology recedes so completely that the people using it can’t tell you what it runs on — only that it works, that it’s theirs, and that it’s not going anywhere.

What “invisible” demands from the people building it

Here’s the thing about invisible infrastructure that we think is worth naming clearly: it requires the people who build it to be genuinely uninterested in credit.

The most visible part of what we do is the surface. The interface, the language, the design decisions that people encounter when they claim an address. That gets seen. But the work that makes the whole thing trustworthy — the infrastructure architecture, the error handling, the abstraction layer, the decisions made to ensure that onchain transactions happen reliably and that edge cases are covered and that the person claiming an address in five years will have the same experience as the person claiming one today — that work is invisible by design.

There’s a certain personality type that builds blockchain infrastructure to be admired for building blockchain infrastructure. The complexity is part of the product. The jargon signals sophistication. The technical depth is something to gesture at. We understand the impulse. We have the same impulse sometimes. But it runs directly counter to what we’re trying to build.

What we’re trying to build is something that, if we do it correctly, will make us completely unremarkable to the people using it. They won’t think about us. They won’t think about the stack. They’ll think about their address, their name, their family’s digital home in Queensland. That’s the outcome. It’s not a particularly glamorous aspiration from a technical standpoint. But it’s the right one.

It’s the backend protocols — the invisible infrastructure — that keep things functional, secure, and scalable. The people who understand that truth deeply, who’ve internalised it as a design ethic rather than just an engineering fact, are the ones who end up building things that last. Things that ordinary people can actually use. Things that don’t require a glossary.

A note on trust, and what we’re asking

There’s one more dimension of this philosophy that we think deserves to be named. When we say the infrastructure should be invisible, we’re also acknowledging something about the relationship between us and the people who claim addresses through what we’ve built.

They can’t see the blockchain record. Not because it isn’t there — it is, it’s public, it’s verifiable — but because we’ve built an experience in which they don’t need to look for it. They trust that it’s there because the experience says it’s there, and because the experience is honest and clear and doesn’t ask them to understand things they don’t want to understand.

That trust is something we take seriously. It’s not trust in us, exactly. The record isn’t held by us. The permanence doesn’t depend on us. But the experience through which they came to own their address was built by us, and in that experience, we made a promise — implicitly, through design, through language, through every choice made about what to show and what to abstract away.

The promise is: this is real, this is yours, and we’ve done the work so you don’t have to. That promise has to be kept every time, in every edge case, for every person who walks through the experience and comes out the other side holding something permanent. Invisible infrastructure isn’t just a design philosophy. It’s an ethical commitment. It says: we trust you enough to build something genuinely good, and we’re willing to do the hard, uncelebrated work to make sure you never have to think about how we did it.

That’s the standard we set ourselves. And it’s the one we’ll keep returning to, every time we make a decision, every time we argue about a design choice, every time we ask whether we’re building for the right person.

The answer, every time, is: the Queensland family who pays five dollars and walks away with something permanent, and thinks nothing of the infrastructure that made it possible.

That’s the goal. That’s always been the goal. And we think it’s worth whatever it takes to get there.