Sovereign chains
Sovereign chains are the core use of 9Chain — what the whole platform exists to do. A sovereign chain is not a contract deployed onto a shared network: it is a chain of its own, with its own genesis, its own signing set and its own rules, operated with exactly the same tooling as every other chain on the platform.
| A sovereign chain has | What that means |
|---|---|
| Its own signing set | You decide who validates. A chain can be open, or limited to a named group of operators |
| Its own access policy | Who may transact, deploy or hold — enforced by the chain itself, not by an application sitting on top |
| Its own economics | Each chain carries its own gas configuration, so running it does not depend on another chain's fee market |
| Shared tooling | Explorer, endpoints and operations work the same on every chain — one way of working, many chains |
🔴 And this has to be said first, before anything else in this part: only ONE of the two branches can create chains on request. The other is a single chain and cannot produce more. That means the flagship capability of the whole platform runs on only one of the two foundations — and which foundation wins the vote for the official network is still open. If the branch that cannot create chains wins, this capability has to be rebuilt on that foundation. That is a real risk, it belongs in Risks and open questions, and this document states it at the top of the part rather than the bottom.
⚠️ One more boundary, smaller but easily missed: self-service is not open. During this phase chains are provisioned by the team, and the write side of the console is sealed at the edge on purpose. There is no button here that pretends otherwise. The three gates that must be passed before chain creation becomes genuine self-service are set out below.
Three parts, one path.
Figure 18 — AI proposes, a human approves, the machine executes.
The console is where a chain is declared: name, currency unit, EVM identifier, validator count, and the switches. The AI layer takes a sentence of description and returns a structured blueprint with reasons and warnings. The operator takes the declaration and raises a real chain.
That order is the invariant part of the design. The blueprint carries reasons and warnings precisely so the approver has grounds to refuse; a proposal that does not state its own weaknesses cannot be approved, only believed or disbelieved. A system that lets AI raise infrastructure with the approval step removed is not bolder, it is merely unauditable.
The AI path is optional and may be absent: when the service is not configured, the interface says so clearly and the manual form works as usual. Alongside it comes a disclosure rule: anything not yet genuinely wired carries an illustrative label, and the label is only removed after end-to-end verification, not before.
Three gates of "self-service"
The phrase is used loosely in this industry, so here it is split into three levels with explicit conditions.
| Gate | Meaning | Requires |
|---|---|---|
| Per organisation | The operating team raises chains for customers on request | Operator and console suffice |
| Self-service with accounts | Outsiders raise their own chains | User accounts, and a requirement that every chain has an owner instead of a shared write permission |
| Per individual | Any person, one sentence, one chain | Additionally: cheap enough, and shared identity becomes a product |
In short: AI here is not a feature bolted on. It is the cheapest way to bring designing a chain below the threshold that requires an infrastructure engineer — without losing the person who is accountable.
In this part
| Page | What it answers |
|---|---|
| What a chain can hold | Twelve components, and each one's label |
| Who uses it, and who cannot yet | Who can enter, and who is still far from the door |
→ Next: What a chain can hold — Twelve components, and each one's label