Open questions and concerns
This page gathers every weak point in one place rather than scattering them where they are hard to add up: what actually runs, what is still open, and the hardest questions a careful reader will ask. If you read only one page of this document to decide whether to trust the project, read this one.
What is proven, what is open
This section places evidence next to gaps in the same table, so nobody has to join two lists together. In terms of the four labels from Before you read: the first table is RUNNING, the second is what is still PROPOSED or LEFT BLANK.
Actually run, and repeatable
| Experiment | What it proves |
|---|---|
| Raising, operating, then deliberately tearing down a public chain that ran continuously for over a week | The platform produces chains that live, and can take them down; both directions have run |
| A two-validator cluster splitting power: switch off the customer node and the chain halts, switch it back and it recovers | The network's life depends on enough parties co-signing, exactly as designed. This is a test of mechanism, not evidence of decentralisation: while the nodes are raised and keyed by one party, "no single party controls it" remains a gate, not a description |
| A four-validator cluster: kill one and it continues, kill two and it halts, restart and it recovers | The consensus threshold behaves exactly as theory says |
| An upgrade across two versions, with a migration that changed real on-chain data | The on-chain upgrade path works |
| A compliance action requiring multiple signatures: missing one signature is rejected | The multi-signature mechanism is enforced, and the model requires three key sets at three separate addresses — but a period actually declaring all three is a gate not yet passed, checkable by reading the genesis file. Handing those three to three real groups of people, each share on its own device, is the gate of the Real assets level |
| End-to-end disaster recovery: back up, delete, restore, and the node continues without rebuilding the chain | There is a path back to life after an incident |
| A genesis package built with the real engine, through the full set of gates, then actually started | Genesis is not a draft |
| A constitution frozen by a hash published before engraving | The on-chain text matches the published text, and anyone can hash it again to check |
Still open, and why
| Problem | Its nature |
|---|---|
| Maturity of the EVM base | The base is still pre-stable. Mitigated by pinning versions, keeping load low, and leaving an upgrade path. This is the largest technical risk |
| Sequential execution | The virtual machine processes sequentially; enough for low permissioned load, not enough at scale |
| From organisations to individuals | The three self-service gates under The chain-producing machine, each needing a different infrastructure layer |
| Shared identity | Needs a published identity scheme, not just a compliance module |
| Interoperability with outside networks | The bridge and border gate are specified and built, but opening the first live interoperability channel is a gate not yet passed. Until a channel lives, interoperability is a design tested in the lab, not a capability in service |
| How token shares are received | Deliberately left blank, awaiting a vote |
| Distribution across failure domains | Real fault tolerance comes from the number of independent machines, and multi-party trust from the number of independent parties running nodes. Those are different things, and both require removing some infrastructure constraints first |
| Advanced privacy | Encrypted mempool, trusted execution environments, zero-knowledge proofs; not needed at this stage |
| Independent audit | Self-review does not substitute for a third party's assessment |
| Legal framework | Jurisdiction and legal entity determine the whole licensing regime |
Figure 21 — Strong evidence always comes with its own limits.
The right-hand list is long on purpose. An infrastructure project without such a list either has not gone deep enough to meet problems, or is hiding them.
In short: strong evidence is evidence accompanied by its own limits.
Counter-arguments
This section keeps only the questions the earlier pages do not answer, rather than repeating what has been said.
If it is permissioned, in what sense is it a blockchain? The better question is who needs to distrust whom. Within a consortium, the parties do not trust one another even though they all know each other; there, immutability, auditability and multi-party mechanisms keep their full value. Besides, permissioned is only a parameter: switch it off and the chain behaves like an ordinary public EVM chain.
The network has been rebuilt several times — why trust it? Because that is an announced design rather than a hidden incident. What deserves to be demanded of an infrastructure project is not "never rebuilt", but that every rebuild is announced in advance and verifiable. A project that has never rebuilt its network may simply be one that never dared to correct a foundational mistake.
What if the company behind it disappears? That is exactly the test the scaffolding commitment aims at, and this document does not pretend to have passed it. The honest measure is the question: how many tasks still require an administrative key? If that number goes down, the commitment is real; if it stands still, it is only words.
Who is accountable when a customer chain does something wrong? The platform runs chains; issuers issue assets and carry their own licences. That boundary is deliberate, not an evasion. But it only stands once written into contracts and confirmed by lawyers in the right jurisdiction, and that work is not finished.
It calls itself community-owned, but has the community decided anything? Nothing yet, and this document says so plainly in Before you read: not one line here has been through a vote. So the right question is not "what has the community decided" — for a project without an official network the answer is always nothing — but "what can the community change, and which door is blocking". Both have written answers: the four labels say what can change, and the three doors still owed in Conclusion say what is blocking and who must open it. A project calling itself community-owned that cannot list its closed doors is the suspicious one.
If the community can change almost everything, what keeps the project from being steered elsewhere? This document's old answer was the engraved list: the four zeros blocking the doors an aspiring captor must pass. The current constitution reduces the engraved list to three blocks and one rule, so the honest answer now is different, and has three checkable layers: each period's genesis file is an immutable record — to find out whether anyone allocated themselves a share, read it rather than listen · every change must win a public on-chain vote, with no shortcut · and the threshold that no party holds more than a third of voting power — but that threshold is a gate the project itself has not passed, not a layer already in place. In short: the minimal constitution trades the comfort of an engraved line for something larger — those who come later are not bound by those who came first — and the price is that all the weight falls on the voting mechanism, exactly where Nine roles says the project is still in debt.
Why does the project talk about its own limits so much? Because in an industry where nearly every document claims to win on every axis, a specific list of limitations is the cheapest signal a liar does not want to imitate. A careful reader will use that very list to check us.
In short: several questions above are answered by pointing at where you can check for yourself, rather than by an assertion. That is deliberate.