In the late 20th century, computer scientists debated which communication protocols should power the internet. Known as the Protocol Wars, this era ended with TCP/IP becoming the standard for network communication.
The digital asset space has experienced its own version of the Protocol Wars. Over the past few years, we’ve learned a lot about distributed ledger technologies. While it’s unlikely that a single DLT will dominate, some standards have clearly emerged. The most notable of these is the Ethereum Virtual Machine (EVM), which we’ll come back to shortly.
At Hashgraph, these lessons have shaped how we think, and inspired the creation of our new offering: HashSphere.
Lesson 1: EVM is the Gold Standard
Let me begin with a bit of history, which will be familiar to many who have been in this space for a while. What follows is a brief account of what the Web3 community has often derisively called “The Bank Chains.”
Between 2015 and 2021, vendors backed by major banks launched “enterprise blockchains” or “private-permissioned” networks. These systems weren’t Web3 in the modern sense; they had no public tokens or open participation—but they did power a few high-profile projects. Meanwhile, Ethereum and the Enterprise Ethereum Alliance were becoming dominant in the Web3 ecosystem.
The industry framed the rivalry as “bankers in suits vs. developers in unicorn tees.” Ethereum led the way in smart contracts but was still based on Proof-of-Work, raising concerns about sustainability. There were doubts it could deliver on its roadmap and transition to Proof-of-Stake. At the same time, the banker-backed platforms were winning institutional contracts.
Traditional finance resisted the public blockchain model. Instead of embracing the full promise of digital assets, it selectively adopted aspects of the tech in closed, proprietary systems that maintained existing power structures.
But in the end, the Ethereum ecosystem won. It completed the shift to Proof-of-Stake and, through openness, collaboration, and a strong developer community, made the EVM the de facto standard for smart contracts. As EVM gained traction and scalability became more important, enterprises saw the downside of non-EVM chains. These systems created walled gardens, locking users into single-vendor ecosystems and isolating them from DeFi and broader network liquidity.
Today, most of the so-called “Bank Chains” have faded. A few have rebranded their private, permissioned networks as “public,” but they generally remain closed systems. Some still have a use-case: after all, you can still find Blu-ray discs if you look hard enough!
Lesson 2: Scale with Math, Not Gimmicks
If you wanted to convince the world that your protocol is the best, one common approach would be to claim it’s the fastest. In the blockchain space, that often means high Transactions Per Second (TPS) numbers. But these figures are frequently misleading.
Those of us focused on real-world solutions find these claims frustrating. TPS alone doesn’t tell you much. Before you can talk about performance, you have to answer harder questions:
How complex are my transactions? How much data needs to be shared? Which participants need to sign, and how many? Where are they located, and what’s the network latency? How long does finality take? I could go on…
But the point is, choosing a performant chain involves much more than a single number. But people prefer simplicity over nuance, which is why we keep seeing these eye-catching TPS claims. So how are these extraordinary numbers possible?
The truth is that some of these TPS claims are optimistic representations. Many are based on experimental setups that don’t necessarily reflect real-world conditions. A closer look at the technical details, often reveals that the numbers are achieved through methods that are selective or not fully representative of typical usage scenarios.
A few common tricks include…
- Running all nodes on a single server.
- Defining a “transaction” as something trivial, with no real signature or state change.
- Processing transactions “optimistically” without validating them.
There are many ways to inflate TPS numbers, but there are also more honest ways to achieve throughput.
High-powered hardware.
Some protocols use high-end hardware like GPUs or ASICs. This can be effective, but it creates a false impression of performance on standard infrastructure and limits access to those who can afford specialized equipment.
Purpose-built Programming Languages.
Other protocols create custom programming languages optimized for blockchain workloads. While that can help with speed, it raises concerns about security and adoption. Most large enterprises, especially in financial services, require mature, well-tested languages.
Math.
In my view, the most effective approach to scalability is the one taken by Dr. Leemon Baird—treating it as a math problem.
Starting from first principles, he calculated the theoretical performance limits of a network based on bandwidth, node count, and Byzantine Fault Tolerance. Then he designed a consensus algorithm, Hashgraph, to push as close to that limit as possible. What makes this approach so valuable is its practicality. As a practitioner, I can define my constraints, determine my requirements, and choose the infrastructure that meets them.
This is far more meaningful than running artificial tests meant only to produce flashy marketing claims with headline TPS numbers.
If the New Protocol Wars taught us anything, it’s that real scalability isn’t achieved with gimmicks. It’s earned through deep engineering and deliberate design.
Lesson 3: The Future Is Hybrid
When explaining Web3 to newcomers, I often avoid technical jargon and abstract theories. Instead, I talk about something familiar: banks.
Banks own the databases that hold our money. They control the transaction history and account states. They can freeze accounts, charge fees, and approve or deny transactions. Customers have little control beyond what the bank chooses to offer.
This imbalance of power is exactly what public blockchains aim to address. Imagine if your account data wasn’t owned by a bank, but maintained by a public, distributed network that no single party controlled.
But here’s where the conversation often hits a snag: privacy. A key feature of a bank account is that it’s private. The idea of financial data living on a public network raises understandable concerns. This has been one of the industry’s biggest challenges, still struggling to balance the openness of public networks with the need to protect sensitive data.
The clearest conclusion from the New Protocol Wars is that the future is not purely public or private. It is hybrid. While some use cases can thrive on a public chain, that is not always the case for highly regulated industries. In those cases, some data needs to remain private, and other information benefits from the transparency and interoperability of public networks. The two must work together, with value and data flowing securely between them.
Hello, HashSphere
The lessons from the New Protocol Wars have played a key role in shaping our thinking at Hashgraph.
We’ve seen that EVM compatibility is now a baseline requirement for interoperability. We’ve seen that scalability must come from rigorous, mathematically grounded design rather than inflated TPS figures. We’ve also come to understand that the industry’s future is about optionality, which in practice means hybrid models, where public and private networks work together.
These insights directly informed the development of HashSphere. Built using Hedera technology, HashSphere provides private, compliant deployments that will be fully compatible with the public Hedera network. It enables enterprises to begin building on Hedera while maintaining the flexibility to move value and data across environments, without vendor lock-in or walled gardens.
HashSphere is built on a simple principle: the future of distributed systems isn’t about choosing between public or private networks. It’s about uniting both to work in harmony.
To learn more or join the HashSphere beta program today, visit hashgraph.com/hashsphere.