A Case Study in Institutional Control
Sui’s outage was framed as proof of safety. In reality, it showed how quickly a small, coordinated group can halt and restart the network. This article breaks down why safety and trustlessness are not the same thing.
There’s a strange sense of déjà vu when a network stalls, the foundation steps in, validators coordinate an upgrade, and the whole thing is framed as proof that the system worked exactly as intended. The language is always reassuring. Safety was preserved. Funds were never at risk. The architecture did what it was designed to do. Thank you for your patience.
If you’ve been around long enough, you recognise the pattern instantly. And if you’ve been reading this publication for long enough, you’ll know we’ve already walked this road.
Back in May last year, we published an article breaking down Sui’s validator set. Not at the headline level, not by counting nodes, but by looking at who actually runs the network. The institutions behind the validators. The capital requirements. The infrastructure overlap. The quiet reality that a small number of well-funded entities were operating multiple validators each, effectively shaping the network while marketing it as decentralised. At the time, that analysis was uncomfortable for some. Today, it feels almost prophetic.
Veritya Thalassa
This week’s six-hour network stall didn’t expose anything new. It simply made visible what was already there.
Sui’s outage was caused by an internal divergence in consensus processing. A bug. Edge cases happen. No serious observer claims otherwise. The important part is not the bug. It is what happened next.
The network stopped. Not slowed. Not degraded. It stalled. For hours.
And the only way it came back was through human coordination. Engineers identified the issue. A fix was implemented. Validators upgraded in concert. Consensus resumed. Normal service was restored.
This is the part we are repeatedly told to interpret as a success story. Safety over liveness. Better to halt than to finalise inconsistent state. At a narrow technical level, that is true.
But trustlessness is not a narrow technical property. It is a systems property. It asks a different question entirely. Who did the network depend on, in that moment, to function at all.
There is a quiet sleight of hand in how these incidents are explained. Safety and trustlessness are treated as interchangeable. They are not. A system can be safe and still be centrally controlled. A system can protect funds and still rely on a small group of actors to decide when it lives and when it moves. Banks do this every day.
The trustless ideal is not simply that funds are not lost. It is that no one is required to step in, coordinate, instruct, and guide the system back to life. The protocol itself is supposed to be the authority.
When a blockchain halts globally and waits for humans to intervene, what you are looking at is not autonomous infrastructure. You are looking at managed infrastructure.
Sui’s validator requirements are not an accident. They are a design choice. Running a validator on Sui requires serious capital. Not hobbyist capital. Not small operator capital. Multi-million-dollar backing, enterprise-grade hardware, serious bandwidth, and ongoing operational expenditure that immediately excludes independent actors.
This shapes the network long before any outage occurs. It ensures that validators are institutions, funds, and professional operators, often running multiple validators each, often sharing infrastructure providers, often moving in lockstep because their incentives are aligned. You do not need explicit collusion for this to matter. Structural alignment is enough.
When something goes wrong, coordination is not difficult. It is expected. That is not decentralisation in the trustless sense. It is institutional consensus wrapped in blockchain terminology.
One phrase from the official post-mortem deserves particular scrutiny. Validators “elected to upgrade” in order to restore the network. This sounds voluntary. It sounds decentralised. It sounds like governance.
In reality, it describes a false choice. Either upgrade, or the chain remains dead. That is not governance. It is operational necessity enforced by downtime. In a genuinely decentralised system, upgrades are contentious, slow, optional, and often resisted. Here, they were immediate, coordinated, and effectively mandatory.
Again, this is not a moral judgment. It is a factual observation about where authority actually sits.
This is not the first time Sui has experienced a major disruption. It is unlikely to be the last. And it will not be unique to Sui. As more high-throughput, institution-run chains push performance to the limit while narrowing validator participation, we will see this pattern repeat. Complex systems fail at the edges. When they do, the social layer steps in. Core teams lead. Validators comply. Users are reassured.
Each time, the marketing language will say the same thing. The architecture worked. Safety was preserved.
Each time, the trustless reality will say something else. The system stopped, and a small group restarted it.
For investors, this matters because risk is not just about bugs. It is about who ultimately controls outcomes. A chain that can be halted and restarted through coordinated action by a small group is a chain whose guarantees are social, not cryptographic.
For users, this matters because censorship resistance and neutrality are not abstract ideals. They depend on independence. On diversity. On the inability of any group, however well-intentioned they may be, to impose its will during moments of stress.
For the broader ecosystem, this matters because words are being stretched beyond recognition. Decentralisation is being reduced to throughput charts. Trustlessness is being replaced with safety narratives. And the original promise of crypto is quietly diluted in the process.
The truth is, we don’t need to attack these systems. We don’t need to exaggerate. We don’t need to speculate. They expose themselves. Every outage. Every coordinated upgrade. Every carefully worded post-mortem is a reminder of how these networks actually function under pressure.
Our role is not to shout. It is to document. To lay the mechanics bare so people can see, clearly and without spin, what they are participating in. If you are comfortable with institution-run infrastructure, that is a choice. But it should be an informed one. Calling it trustless does not make it so.
This is ultimately why we exist at the Zero Trust Network, and why we will keep returning to these conversations even when they are uncomfortable or unfashionable. What we promote, and what we will continue to push into the wider crypto community, is the idea that there is only one foundation worth building on if this space is to mean anything at all. That foundation is trustless infrastructure running immutable code.
From both an investor’s perspective and a developer’s perspective, this is not a philosophical preference. It is a practical necessity. A system either stands on its own, or it depends on people. Once it depends on people, no matter how well intentioned they may be, the guarantees are no longer cryptographic. They are social. At that point you are no longer interacting with a protocol. You are exposed to an organisation.
This approach does not make things easy. It does the opposite. It demands discipline at the design stage, restraint during development, and patience before deployment. It removes the comfort of knowing that something can be fixed later if it breaks, and replaces it with a far harder standard, which is that once something is deployed, it should be right, and it should run without permission, intervention, or coordination. That is not a popular standard, but it is the only one that scales without quietly reintroducing trust through the back door.
This is the mindset we are trying to re-establish. Not through slogans or ideology, but by creating shared understanding and clear reference points. By documenting how systems actually behave under stress. By showing where control exists, how it manifests, and who ultimately holds it when something goes wrong.
You cannot meaningfully describe a network as decentralised when a small number of institutions operate multiple validators and shape outcomes through coordination. You cannot meaningfully describe a system as trustless when it can be halted, upgraded, and restarted through collective action by a narrow group. And you cannot meaningfully describe code as immutable when funds can be paused, frozen, or clawed back, even if those actions are applauded at the time by users who believe they are being protected rather than controlled.
Veritya Thalassa
Our role is not to persuade people what to think. It is to make the mechanics visible so that people can decide with full information. If someone is comfortable with institution-led infrastructure, that is a choice. What we object to is that choice being presented as something else.
As this industry grows, the pressure to compromise on these foundations will only increase. We will continue to document those compromises, explain their implications, and build mindshare around the idea that trustless, immutable infrastructure is not an optional feature or a nice-to-have. It is the core of what crypto was supposed to be.
That is the work we are doing, and that is the work we will keep doing as this network grows in scope, depth, and reach.
V.
Coming Soon: The Privacy Index
Alongside the Trustless Index, we are building the Privacy Index to examine how private blockchain systems really are in practice. It will assess wallets, protocols, and networks against clear, verifiable standards, looking beyond claims and marketing to understand what data is exposed, who can see it, and under what conditions. The framework is in active development and will be released soon.
