In The Future of Finance Isn’t on the Web, we explored a contradiction at the heart of modern blockchain infrastructure.
Blockchain technology has accomplished something remarkable. It allows ownership, settlement, and computation to exist without requiring a central authority to determine what is true. Two people who have never met, living on opposite sides of the world, can transact without asking a bank, payment processor, government, or technology company to maintain the ledger between them. The rules are enforced by the network itself, and ownership is established through cryptography rather than institutional permission.
Yet the applications built on top of these systems are still largely accessed through infrastructure designed around an entirely different philosophy.
A decentralized exchange might operate through immutable smart contracts distributed across thousands of nodes, but the website used to reach it still has a domain name. That domain has to be resolved. The server it points toward has to establish its identity. A secure connection has to be negotiated. Along the way, users depend on DNS providers, certificate authorities, browsers, hosting companies, and other pieces of infrastructure that exist outside the blockchain.
The blockchain may not require us to trust an intermediary, but the road we take to reach it often does.
Our previous article examined why this matters. But it deliberately left a more difficult question unanswered:
If the Web was not designed for decentralized systems, what would infrastructure that was actually designed for them look like?
Our answer is Rubicon.
Rubicon is an attempt to take the trust model that makes blockchain possible and extend it to the way applications find, identify, authenticate, and communicate with one another.
It begins with a simple problem: Before you can interact with a decentralized application, your computer first has to find it.
A Blockchain Application Still Has to Find You
Imagine building a truly decentralized application.
No company controls it. No administrator can rewrite its rules or shut it down. Its smart contracts are immutable, its transactions are verified by a distributed network, and thousands of independent computers around the world maintain copies of the blockchain it runs on.
There is no central server that determines what is true and no institution that users need to trust for the application to function.
Now imagine someone wants to use it. What do they type into their browser?
That simple question exposes an awkward problem for decentralized applications.
The blockchain might be decentralized, but the path we use to reach it often isn’t.
First, you type a human-readable name. That name has to be translated into a location your computer can actually connect to.
Once your computer reaches that location, it needs some way of determining that the computer on the other end really belongs to the service you intended to visit.
Only after establishing that identity can the two computers create a secure connection and begin communicating.
Two of the most important are the Domain Name System (DNS) and the Web Public Key Infrastructure (Web PKI).
DNS helps your computer determine where a service is located. Web PKI helps determine whether the service your computer found should be trusted as the legitimate owner of that identity.
But unlike blockchain, they were designed around the assumption of delegated trust.
Your computer does not independently know where a website is or which cryptographic identity belongs to it. Instead, it relies on other organizations to provide and verify that information.
For a decentralized application, this creates a contradiction.
We can build a financial system specifically designed so that no central party can determine ownership, rewrite the ledger, or decide which transactions are legitimate, only to require users to pass through several layers of trusted infrastructure before they can reach it.
This means that before a user ever reaches the decentralized system, they have already passed through systems of delegated trust.
How the Web Knows Who You’re Talking To
To understand the problem, it helps to look at what actually happens when you visit a website.
Suppose you want to visit example.com
You know the name, but your computer cannot reach another computer using a name like that. It needs to know where on the Internet the service can actually be found.
This is where the Domain Name System (DNS) comes in.
The simplest way to think about DNS is as the Internet’s phone book. You know the name of the person you want to call, and the phone book tells you their number. In much the same way, your computer knows the name example.com, and DNS helps it find the numerical Internet address associated with that name.
Finding the address creates another problem: how does your computer know that the server it reaches really belongs to the service you intended to visit?
The Web solves this problem through digital certificates.
When your browser establishes a secure HTTPS connection, the website presents a certificate containing information that allows your browser to authenticate the site’s identity and establish encrypted communication.
But that immediately raises another question: Why should your computer trust the certificate?
This is where Certificate Authorities, or CAs, enter the picture.
Your browser and operating system come with a collection of trusted organizations whose job is to vouch for identities on the Web. These organizations can issue or validate certificates establishing that a particular cryptographic key belongs to a particular domain.
In simplified terms, a Certificate Authority is telling your browser:
“Yes, this cryptographic identity belongs to example.com.”
This creates a chain of trust. Your browser and operating system trust a collection of Certificate Authorities, which in turn attest to the cryptographic identities of websites.
It is easy to criticize this arrangement from the perspective of blockchain, but it is important to understand why it exists.
This architecture solved an extraordinarily difficult problem: how do billions of ordinary people securely communicate with computers they have never encountered before?
Two computers with no previous relationship can locate one another, authenticate the service, and establish encrypted communication within moments.
This system helped make the modern Internet accessible to billions of people.
The important question here is how it establishes trust.
The Web solves the problem through delegated trust.
For the Web, delegated trust was a practical solution to an enormously complicated problem.
But blockchain gives us another possible answer.
If we can establish ownership without asking a central organization to vouch for it, could we use the same principle to establish identity on the Internet?
Blockchain Changed the Identity Problem
The Web’s approach to identity makes sense because of the problem it was originally designed to solve.
Two computers encounter one another with no previous relationship. One claims to represent a particular service. The other needs some way to determine whether that claim is legitimate.
The Web solves this by asking: Who can verify that this cryptographic key belongs to this service?
As we have seen, Certificate Authorities provide that verification. They create a trusted link between a name and the cryptographic identity presented by the server.
But blockchain gives us another way to approach the problem.
Instead of asking: Who can verify this identity?
We ask: Who controls this identity?
A blockchain already provides the ingredients needed to establish ownership without an intermediary: a globally shared state, cryptographic ownership, a verifiable history of changes, and consensus over which version of that state is current. Most importantly, it allows the owner of a cryptographic key to modify that state without asking anyone else for permission.
We already rely on this model every time someone sends cryptocurrency. The network does not ask a bank who owns the coins. It verifies that the person spending them controls the appropriate cryptographic keys.
Possession of the appropriate private key allows them to produce a signature that the network can independently verify. The authority to act comes from cryptographic ownership rather than an institution vouching for the person exercising it.
Rubicon turns network identity into a form of cryptographically controlled state.
Introducing Rubicon
Rubicon is a standard for publishing and resolving network services directly through blockchain state. Rather than building decentralized applications on top of the Web’s existing system of names, certificates, and trusted intermediaries, Rubicon uses the blockchain itself as the foundation for discovering and authenticating services.
A service begins by registering its identity on Gajumaru.
In simple terms, a Rubicon lookup can answer several questions at once:
- Where is this service?
- How should my computer communicate with it?
- What cryptographic identity should the service possess?
- How should a secure connection be established?
Under the traditional Web model, different parts of this process are delegated to different systems and organizations. DNS helps determine where to go. Certificate Authorities help establish who you have reached. Other protocols then negotiate how the two computers will securely communicate.
Rubicon attempts to bring those pieces together through the authority of cryptographic ownership.
The owner controls the information associated with that identity directly. If the service moves, changes its cryptographic keys, or changes how it accepts connections, the owner can update that information on-chain.
There is no DNS administrator who needs to change the record on your behalf. There is no Certificate Authority that needs to approve your cryptographic identity. And there is no third party whose attestation is required to establish that the service belongs to you.
The authority comes from the same place that authority comes from elsewhere in a blockchain system: control of the cryptographic keys associated with the on-chain identity.
Rubicon therefore isn’t simply an attempt to put DNS records on a blockchain. The larger goal is to make blockchain state the starting point for establishing communication itself.
Once your computer resolves a Rubicon identity, it doesn’t just know where to go. It knows where to go, who it should find there, and how to begin talking to them securely.
One Lookup Instead of a Chain of Trust
A conventional DNS lookup primarily answers a simple question: Where is it?
You provide a name, and DNS helps your computer determine an address associated with it. But knowing an address is not the same thing as knowing a service.
It still has to establish a connection to the destination. It needs to determine what is on the other end. It needs to authenticate the service’s identity. The two computers need to establish how they will communicate securely. Only after those steps have taken place can the application begin exchanging the information the user actually wanted to send.
This distinction is fundamental to Rubicon as you shouldn’t look up a computer’s address. You should look up a service.
An address merely tells your computer where to send traffic. A service has an identity, a location, cryptographic keys, supported methods of communication, and other information necessary to actually interact with it.
A simplified connection might begin with your computer asking where a domain is located. It receives an answer. It then establishes a network connection to that destination. The server and client exchange additional information to establish a secure connection and determine how they will communicate. The server presents its identity, and your computer verifies that identity through the Web’s certificate infrastructure.
Modern protocols have become very good at making this process fast, and connections can often be reused rather than established from scratch. But when a new connection does need to be established, every sequential exchange matters.
This is particularly noticeable over long distances.
If two computers are separated by 100 milliseconds of network latency, every additional round trip adds time before useful application traffic can begin flowing. TCP itself requires a connection handshake. Establishing encryption and authenticating the service can require additional communication. Depending on the protocols being used, more negotiation may follow.
More importantly, all of this back and forth exists because the client begins with remarkably little information.
Rubicon approaches the problem from the opposite direction.
Instead of beginning with an address and discovering everything else afterward, Rubicon resolves the service itself.
A single Rubicon lookup is able to return the information necessary to begin communicating with that service.
The answer is not simply: “Here is where it is.”
It is closer to: “Here is where it is. This is the cryptographic identity you should expect to find there. This is how it accepts connections. And this is the information necessary to establish one securely.”
This disentangles location from identity.
An IP address is not an identity. Addresses can change. Routes across the Internet can change. Traffic can be misdirected or intercepted. Simply reaching the address you were given should not, by itself, establish that you have reached the correct service.
With Rubicon, the client already knows the cryptographic identity it expects before it connects.
Reaching the destination therefore does not establish trust.
Proving possession of the cryptographic identity published by the service does.
Rubicon uses the Noise Protocol Framework to establish the encrypted connection that follows. Noise is a modern framework for establishing secure communication between computers, but the cryptographic details are less important here than the architectural difference.
In simplified terms, the conventional process is closer to:
Look up the name. -> Receive a location. -> Establish a connection. -> Discover and authenticate the service. -> Negotiate secure communication. -> Begin communicating.
Rubicon attempts to collapse much of that process into:
Resolve the service. -> Receive its location, identity, and connection information together. -> Establish the authenticated encrypted connection. -> Begin communicating.
It can also reduce the amount of negotiation required before useful traffic begins flowing. If both sides already know how the connection should be established, there is less reason to spend additional round trips discovering that information after they meet.
The purpose of the lookup is to provide the information necessary to avoid much of that sequence in the first place.
Existing Applications Don’t Have to Disappear
Rubicon does not replace the Internet. It operates over it. The objective is not to build another Internet, but to use the Internet without inheriting the Web’s trust model.
Existing protocols can therefore be carried through a Rubicon connection. HTTP can travel over Rubicon. So can other protocols used by applications, games, servers, and network services.
The application does not necessarily need to care how the connection underneath it was discovered or authenticated.
A service could continue speaking a protocol it already understands while Rubicon handles the layers beneath it: finding the service, establishing its identity, authenticating the connection, and creating a secure channel between the two computers.
Rubicon is not trying to replace every protocol on the Internet. It is trying to replace the trust infrastructure required to reach them.
A developer should not have to redesign an entire application simply because they want to use blockchain-native identity. Existing software could gradually gain support for Rubicon while continuing to operate through conventional Internet infrastructure.
A service might initially be accessible through both a conventional domain name and a Rubicon identity. Applications could support traditional connections alongside Rubicon connections. Developers could experiment with the system without abandoning the infrastructure their users already depend on.
Rubicon does not need to anticipate every protocol, network architecture, or application that might exist decades from now. The initial objective is much narrower:
- First-party naming.
- First-party identity.
- Secure communication.
- Simple transport over existing Internet infrastructure such as TCP and UDP.
Rubicon should not attempt to freeze those choices into the network. Instead, the identity itself can describe how a service currently expects to communicate. As the technology changes, the information associated with that identity can change with it.
Keep what already works. Replace the layers of delegated trust that decentralized systems no longer need. And allow everything else to evolve on top of it.
Privacy Becomes an Architectural Property
Consider again what happens when you visit a website.
Before your computer can connect to a service, it often needs to ask another computer where that service is located. In a conventional DNS lookup, that means sending the name you are looking for to a resolver.
That request reveals something surprisingly valuable: Intent.
You have not connected to the service yet. You have not sent it a message, logged into an account, or exchanged any application data. But simply asking how to find it can reveal something about what you are trying to do.
Taken together, these requests can indicate which websites someone visits, which applications they use, which online services their devices communicate with, and when those interactions occur.
Encryption does not necessarily solve this problem because the information can be exposed before the encrypted connection has even been established.
A Gajumaru node already maintains the blockchain state necessary to independently verify the network. If Rubicon identities are part of that state, the information required to resolve them can exist locally as well.
Your computer does not necessarily need to ask a third-party resolver “Where is this service?”
It can look at the state it already possesses as it already knows.
The goal, however, is not anonymity. Rubicon does not make a computer invisible.
Communication still has to travel across physical networks. Depending on how a connection is made, network operators may still observe IP addresses. Traffic volume and timing can reveal patterns. A compromised computer can undermine even the strongest network protocol, and no cryptographic system can prevent someone with control of an endpoint from seeing what happens on that endpoint.
Those are separate problems.
It cannot eliminate every form of metadata, nor is that the claim.
Its objective is more specific:
Rubicon attempts to eliminate metadata exposure where that exposure exists only because of architectural decisions inherited from the Web.
Privacy, in that sense, is not an additional feature. It is a consequence of needing fewer intermediaries in the first place.
Censorship Becomes More Difficult, Not Impossible
Removing intermediaries has another important consequence: it changes how a service can be censored.
The modern Web contains several convenient points of control between a user and the service they are trying to reach.
A domain name can be seized or redirected. DNS providers can be ordered to stop resolving a name. Certificates can be revoked or refused. Hosting providers can terminate accounts. Infrastructure companies can decide that they no longer want to provide service to a particular customer.
The application itself may be decentralized while its identity remains dependent on organizations that are not.
Rubicon removes several of these intermediary control points.
If a Rubicon identity exists as part of blockchain state, its owner does not need the continuing permission of a domain registrar, DNS provider, or Certificate Authority to maintain that identity.
The owner controls it cryptographically.
This does not however make censorship impossible.
A government could still attempt to block the IP addresses associated with a service. An Internet service provider could filter network traffic. A sufficiently powerful network operator could attempt to identify and interfere with certain kinds of connections. Servers can still be seized. Computers can still be compromised. Software can still contain vulnerabilities.
What Rubicon changes is where intervention has to occur.
Today, interfering with access to a service can sometimes be accomplished by targeting an intermediary that sits above the underlying network. Rather than preventing two computers from communicating, it may be enough to prevent one of them from learning where the other is, remove the name users know it by, or interfere with the infrastructure used to authenticate it.
Rubicon attempts to remove those points wherever blockchain state can perform the same function without them.
If the name exists on-chain, removing it requires interfering with the blockchain rather than a registrar.
If the information needed to resolve that name already exists locally, blocking a DNS provider does not prevent the lookup.
If the service’s cryptographic identity is established on-chain, removing or coercing a Certificate Authority does not change that identity.
Rubicon does not make censorship impossible. It changes what censorship requires.
Instead of censorship occurring quietly through an intermediary most users never knew they depended upon, interference increasingly has to occur closer to the network itself.
Beyond Websites
It would be easy to look at Rubicon and think of it primarily as a way to build decentralized websites.
Rubicon is better understood as a networking standard, because there is nothing inherently “Web” about the problem it is trying to solve.
At its most basic level, Rubicon is concerned with a simple sequence:
Name -> Identity -> Location -> Secure Connection
The service on the other end could be a blockchain application. It could be an API used by other software. It could be a game server, an SSH server, a messaging platform, a video stream, a financial service, or another blockchain node.
It could just as easily be a type of application that does not exist yet.
- What service am I trying to reach?
- Where can I find it?
- How do I know that I found the right one?
- How can we communicate securely?
There is no reason HTTP has to disappear simply because DNS or Web PKI are no longer being used to establish the connection. If two applications already understand HTTP, they can continue speaking HTTP.
A game does not need Rubicon to understand how its multiplayer protocol works. Rubicon only needs to help the player find the correct server, authenticate its identity, and establish the connection.
Rubicon provides the introduction. What the two computers say to each other afterward is up to them.
Rather than asking how to build a better decentralized website, it asks:
How should two computers that have never encountered each other find one another, establish who they are, and begin communicating without relying on a trusted intermediary?
It is an attempt to provide decentralized applications with something more fundamental: a blockchain-native way for computers to find each other, authenticate each other, and communicate securely across the Internet.
Crossing the Rubicon
Blockchain’s most important innovation was never simply cryptocurrency.
Bitcoin demonstrated something much broader: certain forms of trust that had historically been delegated to institutions could instead be established through cryptography, consensus, and a shared record that anyone could independently verify.
We first applied that idea to money.
If ownership could be established cryptographically, transferring value no longer required a bank to maintain the authoritative ledger.
Then came computation.
Smart contracts allowed not only ownership, but rules and agreements themselves to be executed by decentralized networks. Applications could exist without a central operator possessing the authority to rewrite their underlying logic.
There is an irony however in building an application specifically so that no company controls it, only to depend on companies to tell users where that application is and who they should trust when they arrive.
The Internet is the global network that allows computers around the world to communicate. The Web is one collection of technologies we built on top of that network to help those computers find one another, establish identity, create trust, and exchange information.
Those technologies were designed for another era and they are no longer the only tools available to us.
Blockchain gives us another primitive: globally verifiable ownership without a central authority.
Rubicon explores what happens when we take that primitive seriously outside the boundaries of the blockchain itself.
We do not need to discard the Internet. We need to reconsider what we build on top of it.
The previous generation of blockchain technology focused on decentralizing what happens after a user reaches an application.
Rubicon attempts to decentralize how they reach it in the first place.
This is the point of no return that we intend to cross.