What a chain can hold
A chain on its own is only a ledger. What makes it useful is what can be assembled on top — and the brief for a platform is that those pieces arrive as parts of the platform, rather than every project rebuilding them from scratch.
The table below uses the same four labels as How to read this document. Read the label column before the description column — read it the other way round and the whole table sounds like a list of features already shipped.
| Component | What it is on a chain | Label |
|---|---|---|
| Identity | Who is who, carried across everything built on the network | GATE — the one identity half still has to be proved |
| Wallets | Standard wallets can hold and sign, with no special client | RUNNING |
| Smart contracts | Standard contracts, using tooling that already exists | RUNNING |
| Digital assets | Issued and moved under rules the chain itself enforces | RUNNING on the branch with protocol-level compliance |
| Payments | Settled on the chain, not beside it | RUNNING |
| Explorer | Every chain readable by anyone, without asking the operator | RUNNING |
| Operations | Signers, upgrades and monitoring through one surface | RUNNING |
| Your own rules | Purpose, economics and policy set per chain | RUNNING on the branch that can create many chains |
| Governance | Proposing and voting as a function of the chain, not a forum thread | RUNNING on one branch, LEFT BLANK on the other |
| Contribution records | Effort and participation recorded where they cannot be quietly rewritten | GATE — needs a recognition mechanism settled by vote |
| Data storage | Records living with the chain that vouches for them | GATE |
| Interoperability | Messages and value moving between chains in the network | GATE — no branch has a working route |
The most important sentence on this page is in the right-hand column
Count the label column and the real shape appears at once: what already runs is what any EVM chain can do, while what would make 9Chain different — shared identity, contribution records, interoperability — sits almost entirely under the GATE label. That is not an embarrassing admission; it is the correct map of an infrastructure project still in its testing stretch. But it has to be said here, because a twelve-item list without labels reads as twelve things already finished.
Figure 19 — The twelve components split into two columns by label. The right-hand column is where the project's actual problem sits.
Four steps from an idea to a chain that answers
| # | Step | Worth remembering |
|---|---|---|
| 1 | Define the chain | Chain identity, gas configuration, the initial allocation — written before anything runs, because genesis cannot be edited afterwards |
| 2 | Create it | One command, or one declaration. The platform builds the chain and registers it with the network |
| 3 | Connect to it | The chain comes up on its own endpoint; standard tooling connects as it would to any EVM chain |
| 4 | Operate it | Signers, upgrades and monitoring run through the same operating surface as everything else |
Steps two and four are where the two branches genuinely differ — one uses a chain factory driven from the platform chain itself, the other an external controller. Both were built to the same brief, and that is precisely what makes them comparable.
This document does not copy the commands for those four steps: commands change with each release, and the two branches have two different command sets — copying them guarantees being wrong about one. The original lives on each branch's own site.
In short: the list of what a chain can hold is a list of the brief, not a list of what has been delivered. The way to read it correctly is to count the label column — and once counted, the most interesting part of 9Chain is still on the far side of a gate.
→ Next: Who uses it, and who cannot yet — Who can enter, and who is still far from the door