# 9Chain Documentation
**A ledger of your own, and a shared network so those ledgers can trust one another — something only a few have ever had, now open to anyone.**
*This document is written in the permanent tense: it describes design, mechanisms, and the gates a network must pass. It is not a snapshot. Every live measurement lives in “Check the network yourself”.*
## Summary
Ever since people learned to keep records, every society has built a ledger — and for all those centuries the ledger has belonged to **someone else**. **9Chain makes having a ledger of your own something anyone can reach**: an institution, a community, or a single person. In the technology of one era, that ledger takes the shape of **a blockchain of its own**.
So what is being built is not a ledger, but **the machine that produces them**: you declare one in words, and the infrastructure raises it, keeps it alive, and takes it down when its work is done. Every ledger born this way carries two things that an old-style corporate ledger does not have and a public ledger will not give: **rules enforced inside the consensus mechanism itself** rather than in a contract running on top of it, and **a controlled, public economic exit**. The specific implementation — an operator that raises chains automatically, a console to drive it, an AI layer that turns a description into a working blueprint — is the method **of one era**, not a definition: when the technology changes, the method changes; those three jobs do not.
The shape of the whole system is therefore **multi-chain**: many private chains, and one shared network so they can trust each other. That shared network is 9Chain itself, a public blockchain with the native token LOVE9.
The unusual claim sits here: if everyone needs a chain in order to work alongside AI, chains become abundant, and the scarce thing is no longer one more chain — it is **a verifiable identity that works across all of them**. LOVE9 proposes a total supply of 81 billion, with no allocation to the team, no allocation to investment funds, no premine, and no sale to anyone.
Two self-limiting sentences, placed right here. What this document claims is architecture and mechanism, **not operating scale**. And every economic number is **an opening proposal for the community to vote on**, not a commitment — the project's own constitution says so.
And a third sentence, the most important one for a first-time reader: **everything in this document was built and proposed by the founding group** — not one line has been through a community vote. They stay **open**: anything not marked ENGRAVED can be changed through public argument and then a vote, and **no line is engraved before mainnet** — the project passes through three testnet periods first, each one a chance to put this very document to the test and correct it. [*Before you read*](/en/before-you-read) defines the four labels used consistently throughout; [*Taking part, and the doors still owed*](/en/taking-part-and-the-doors-still-owed) explains how to take part — and lists the doors still closed.
### Four ways to read this, depending on who you are
The document has **four parts**, ordered along one line of reasoning: why it exists → what it promises → how it is built → who is inside → money and power → checking it yourself and taking part. You do not need to read all of it, and you should not read it front to back if you arrived with a specific question.
| You are | Read in this order |
|---|---|
| **New here, with fifteen minutes** | This page → [*Nine missions*](/en/nine-missions) → [*Check the network yourself*](/en/check-the-network-yourself) |
| **An organisation evaluating it** | [*Context*](/en/context) → [*The 9Chain platform*](/en/the-9chain-platform) → [*Applications and users*](/en/applications-and-users) → [*Open questions and concerns*](/en/open-questions-and-concerns) |
| **An operator or a developer** | [*The 9Chain platform*](/en/the-9chain-platform) → [*Operations and governance*](/en/operations-and-governance) → [*FAQ*](/en/faq) |
| **A sceptic** | [*Before you read*](/en/before-you-read) → [*Open questions and concerns*](/en/open-questions-and-concerns) → [*Check the network yourself*](/en/check-the-network-yourself) → [*Taking part, and the doors still owed*](/en/taking-part-and-the-doors-still-owed) |
The fourth path is the one we **hope** you take. An infrastructure document is only worth reading on if it survives the harshest reader, and the four pages on that path are the four that name what the project still lacks.
> **In short:** what 9Chain builds is not a blockchain, but **the right to keep your own ledger** — something every generation before had to ask someone else to hold. The entire value of that promise rests on the fact that every sentence above can be checked.
## Learn 9Chain
This part answers two questions: **what 9Chain is**, and **why it is built this way rather than another way**. It does not teach you what to run or what to call — those belong to [*Network and nodes*](/en/network-and-nodes) and [*Build on 9Chain*](/en/build-on-9chain).
The ten pages below follow a deliberate order, and that order is itself a statement of attitude: **evidence comes before invitation**. You meet the reading rules before the content, the problem before the solution, and the project's weak points before the invitation to join. A document arranged the other way round — invite first, confess later — reads far more pleasantly, and that is exactly why it should not be arranged that way.
| Page | Answers which question | Read it when you want to |
|---|---|---|
| *[*Before you read*](/en/before-you-read)* | How should this document be read? | Know which sentences are locked and which can still change |
| *[*Context*](/en/context)* | Why does the world need another network? | Check whether the problem is real |
| *[*Nine missions*](/en/nine-missions)* | What does this project actually want? | Understand the part that survives changes in technology |
| *[*The 9Chain platform*](/en/the-9chain-platform)* | How is it built? | See architecture, consensus, compliance, fault tolerance |
| *[*Applications and users*](/en/applications-and-users)* | Who uses it, and who cannot yet? | Find your own place in it |
| *[*LOVE9 economics*](/en/love9-economics)* | Where do tokens come from and go? | Examine the part most easily overstated |
| *[*Nine roles*](/en/nine-roles)* | Who may do what, and who checks whom? | Understand how power is divided |
| *[*Operations and governance*](/en/operations-and-governance)* | Who holds the keys, who can change the rules? | Assess centralisation risk |
| *[*Open questions and concerns*](/en/open-questions-and-concerns)* | Where is it still weak? | Read the counter-arguments, including the project's own |
| *[*Taking part, and the doors still owed*](/en/taking-part-and-the-doors-still-owed)* | How do I take part? | Learn which doors are open and which are still owed |
```mermaid
flowchart LR
A["How to read
four labels"] --> B["Problem
and context"]
B --> C["Design
and mechanism"]
C --> D["Weak points
and rebuttals"]
D --> E["Invitation
and doors still owed"]
```
*Figure 1 — The reading path: each step stands on the one before it, and the invitation comes last.*
A note on tense. This entire part is written in the **permanent tense**: it describes design, mechanisms, and the gates a network must pass. It deliberately contains no live number — no block height, no network identity, no count of machines running. If you want to know how the network stands at the moment you are reading, that is the job of [*Network and nodes*](/en/network-and-nodes), and the answer there is read straight from the network rather than taken from this page.
> **In short:** the *Learn* part says what the project **intends to do and how**; to find out **how far it has actually got**, do not read here — read where you can check for yourself.
## Before you read
Every foundational document has one sentence it usually leaves out: **who wrote it.**
### Everything you read here was proposed by the founding group
The architecture, the compliance mechanism, the nine roles, every economic number, even the way nine missions are divided into three sets — all of it was built and proposed by the **founding group**. **Not one line in this document has been through a community vote.**
Saying that is necessary. Without it, a reader will assume this is *the truth of the system*. It is not. It is **what one group of people chose**, written down so that others can read it, argue with it, and change it.
A small group has to begin, because something must exist before there is anything to discuss. The difference between **beginning** and **owning** lies in exactly one place: whether the group that began will let others change it, how far they may change it, and until when.
### Four labels, used consistently throughout
From here on, everything this document mentions belongs to exactly **one of four states**. Reading a claim without reading its label is the easiest way to mistake a proposal for a commitment.
| Label | Meaning | Who can change it | Example in this document |
|---|---|---|---|
| **ENGRAVED** | Locked permanently in the constitution, never put to a vote | **No one** — including the founding group | The three memorial blocks that open the ledger, and one meta-rule: *everything else belongs to the community to decide together* — see [*LOVE9 economics*](/en/love9-economics) |
| **RUNNING** | Actually built, and verifiable by outsiders | Changed by building something better | The eight experiments in [*Open questions and concerns*](/en/open-questions-and-concerns) |
| **PROPOSED** | Drafted by the founding group, awaiting the community | **The community**, through argument and then a vote | Total supply of 81 billion · the release rhythm · the nine roles · the validator ceiling · the three operating modes |
| **LEFT BLANK** | Deliberately undecided, the space kept empty | No one has decided, so the space is still open | How an individual receives their share · the three open questions in [*Nine roles*](/en/nine-roles) |
**The shortened reading rule: anything not marked ENGRAVED can be changed.** And the ENGRAVED list is short **on purpose** — with a long engraved list, "the community decides" is only a figure of speech.
```mermaid
flowchart LR
P["PROPOSED
drafted by founders"] --> R["PUBLIC ARGUMENT
anyone may object"]
R --> G["MANDATORY GATE
voting power must leave
the project's hands FIRST"]
G --> B{"Vote with
a real quorum"}
B -- "rejected" --> P
B -- "passed" --> K["Into the genesis of
the official network"]
K --> KH["OPENING RECORD
immutable as a record,
still changeable as a rule"]
```
*Figure 2 — The path of a decision. The gate in the middle is where the project blocks itself: see Nine roles.*
### Nine steps, and only one that engraves
9Chain's roadmap has **nine steps** — and it is the roadmap of **the project itself**, not an abridged version made for outsiders.
| Step | What happens | Does anything get engraved permanently |
|---|---|---|
| **1** | Release the **demo testnets** and the systems around them | **No** |
| **2** | Release the **community platform** and run the **virtual 9Chain Node** — where an ordinary person can stand inside the network before needing validator hardware | **No** |
| **3** | Release the **community voting mechanism** | **No** |
| **4** | Run **Testnet 1** officially — first block **19/08/2026**, **Block Adam 09/09/2026** | **No** |
| **5** | Run **Testnet 2** officially | **No** |
| **6** | Run **Testnet 3** officially | **No** |
| **7** | **Conclude the community votes** | **No — but this is when the window closes** |
| **8** | Official **mainnet** launch | **Yes — and only here** |
| **9** | **Full decentralisation** | **Nothing further engraved — this is when the scaffolding comes down** |
The backbone of those nine steps is still **four periods**: **Testnet 1 → Testnet 2 → Testnet 3 → Mainnet** (mainnet is also called *the official network*; the two words mean the same thing). The first three steps are the run-up to Testnet 1 — the period of trial builds and of making a place for the community to stand; the middle three are the three test periods; the last three are **close the window, engrave, then let go**.
Two places in this order deserve a closer reading than the rest.
**Step 3 comes before step 4.** The voting mechanism must exist **before** the three test periods begin, because otherwise the phrase *"the community votes"* across those periods is only a figure of speech: every decision would be settled before anyone could cast a ballot. This ordering is a commitment, not a scheduling detail.
**Step 9 comes after step 8.** This is where this roadmap differs from most others: **the day the official network launches is not the finish line.** At the moment of engraving, power is still more concentrated than it ought to be — saying otherwise would be a lie. Full decentralisation is therefore a step that comes **afterwards**, and it is the only step that does not end with a launch event: it is done when **no task requires an administrative key any more**, and that is a countable number (see *The commitment to remove the scaffolding* in [*Operations and governance*](/en/operations-and-governance)).
*Which step things stand at is a live fact, so it is not written here — how to read it for yourself is in "Check the network yourself".*
This is the most important thing to carry into the rest of the document: **not one line here is engraved before mainnet.** The three testnet periods exist precisely so that what is written here can be tested, argued with, and corrected — by community vote, with **almost no clause off the table**. The single exception is the core, reduced to its minimum: **the three memorial blocks** that open the ledger, and the rule itself that *everything else is decided by the community together* (see [*LOVE9 economics*](/en/love9-economics)).
#### Mainnet = Testnet 1 + Testnet 2 + Testnet 3 + Mainnet
The three test periods **are not thrown away when the next one begins**. Their history — who did what, who contributed what, who was verified how — is **preserved and attached to the shared ledger of mainnet**. Mainnet is therefore not a ledger opening on a blank page, but **the sum of all four periods**.
> ⚠️ **HISTORY is preserved, not a balance promised.** The *inherited genesis* principle stands intact: **no period promises a one-for-one balance**. What testnet contribution history converts into — or whether it converts at all — is marked **LEFT BLANK**, and mainnet is where the community votes on it. Anyone telling you that running a testnet will **certainly** convert into tokens is putting words in the project's mouth — nobody has decided that.
There is one more boundary to state fully, because it is easily read as something it is not. **A test period can be wiped and rebuilt from scratch** — that is exactly what the three testnet periods exist to do. When it happens, balances, addresses, contracts and block history of the abandoned build **do not flow into the next one**; do not build anything that depends on a test network living forever. The inheritance promise takes effect **from the genesis of mainnet**.
Preservation only means something if outsiders can check it, so the rule that comes with it is a countable action: **before a network is rebuilt, a complete copy of the old ledger and its hash are published.** Anyone can download it, hash it again, and reconcile what happened — even long after that network has stopped running. What carries over is **a published contribution record with its hash**, not a balance.
### The window that is still open, and when it closes
Changing a proposal is **cheap** while it is still words. It gets more expensive once it becomes code. And it is **all but unchangeable once it enters the genesis of mainnet** — a wrong genesis cannot be patched, it can only be rebuilt as a whole network.
So the most valuable stretch in the whole life of this project is the one **from now until mainnet**: the stretch where a stranger's question can still change the design. The three testnet periods are three times that window is reopened.
The window closes at **the genesis of mainnet**, not at the genesis of a testnet — and a genesis should only happen after passing the gates in [*Check the network yourself*](/en/check-the-network-yourself). Within the nine steps, the closing point has a clear name: **step 7, concluding the votes** — after that comes engraving. Put another way, **the window stays open exactly as wide as the remaining distance to level four** — and you can measure that distance yourself, without asking anyone.
### Three things the founding group binds itself to
**Never ratify anything permanent with its own votes.** Distributing voting power to the point where the project loses its veto must come before any ratification of anything permanent. The full reasoning is in [*Nine roles*](/en/nine-roles) — the most candid page in this document.
**State what does not work yet right beside what does**, in the same table, so that nobody has to join two separate lists together.
**Measure the promise to withdraw with a countable number:** how many tasks still require an administrative key. If that number goes down, the promise is real; if it stands still, the promise is only words.
> **In short:** a project that calls itself *community-owned* must answer two questions, not one: **what can the community change**, and **what can no one change any more**. The four labels above answer both — and you should hold that same table up against every new thing we say.
## Context
Three questions must be answered before any talk of design: is the demand real, why have existing approaches not solved it, and when should you **not** choose 9Chain. This page answers all three, in that order.
### Market demand
> **About the numbers on this page.** They are **quotations from outside sources**, with links and measurement dates — they are not measurements of the 9Chain network. Market figures change over time; here they show the **shape and direction** of demand, not a permanent state. Different sources measure differently, so where they disagree the document gives the range.
#### Real capital has moved on-chain, and it is growing fast
| Indicator | Value | Source · measured |
|---|---|---|
| Tokenised real-world assets, tradable on-chain (excluding stablecoins) | about **33.5 billion USD** | [RWA.xyz / Canton](https://www.canton.network/blog/state-of-rwa-tokenization-2026) · early 7/2026 |
| Same indicator, one year earlier | about **11.8 – 14.1 billion USD** | as above · mid-2025 |
| Assets committed to tokenisation but **not yet freely tradable** | about **345 billion USD** | as above · early 7/2026 |
| Stablecoins in circulation | about **287 – 313 billion USD** (depending on source) | [StableCoin.com](https://stablecoin.com/market-cap/) · [DefiLlama via Reap](https://reap.global/blog/stablecoin-statistics-2026) · 8/2026 |
| Stablecoin concentration | the two largest account for **89%** | [Reap](https://reap.global/blog/stablecoin-statistics-2026) · 2026 |
The most striking number in the table is not 33.5 billion, it is **345 billion**. The gap between the first two rows and the third says one thing: most of the assets committed to going on-chain **have not got anywhere**. They are held somewhere between an intention and a tradable ledger.
```mermaid
xychart-beta
title "Real-world assets on-chain, excluding stablecoins (billion USD)"
x-axis ["mid-2025", "3/2026", "5/2026", "7/2026", "committed,
not tradable"]
y-axis "billion USD" 0 --> 360
bar [13, 25.4, 31.4, 33.5, 345]
```
*Figure 3 — The last bar is not the same kind of thing as the first four: it is the portion committed but not yet freely tradable. That gap is the problem.*
#### The law is clear, but clear one region at a time
The two largest regulatory frameworks are both in force, and **they do not recognise each other**.
| Framework | Status | Source |
|---|---|---|
| MiCA (EU) | Fully applicable across all 27 member states from 12/2024; issuers must be licensed before 1/7/2026 | [KuCoin Research](https://www.kucoin.com/blog/en-stablecoin-regulation-updates-2026-genius-act-mica-enforcement-global-compliance-trends) |
| GENIUS Act (US) | Signed into law 18/7/2025 (Public Law 119-27); only licensed institutions may issue payment stablecoins | [Eco](https://eco.com/support/en/articles/15282223-what-is-the-genius-act-us-stablecoin-law-explained-for-2026) |
| Mutual recognition between the two | **None.** A licence on one side does not work on the other | [Orochi](https://orochi.network/blog/2026-stablecoin-regulatory-expectations-the-future-of-global-payments) |
This matters more than it looks. Clear rules give institutions the confidence to step in, but **rules that are clear region by region** mean compliance obligations differ between markets, and no single licence covers them all. An organisation serving several markets must enforce **several different bodies of law on the same infrastructure**, and prove it to each regulator separately.
Enforcement at the application layer cannot meet that requirement, because the application layer can be bypassed. That is why where you place the compliance gate becomes an architectural question rather than a feature question.
#### Large institutions have moved, and they moved on private infrastructure
The notable point is not *that* large institutions took part, but **how** they took part.
| Event | Scale | Source |
|---|---|---|
| BlackRock tokenises part of its European money-market fund range, running on JPMorgan's blockchain | **311 billion USD** in range value | [Decrypt](https://decrypt.co/374894/blackrock-tokenizes-311b-of-european-money-market-funds-with-jp-morgans-kinexys) · 8/2026 |
| Cumulative transaction volume on JPMorgan's blockchain platform | over **1.5 trillion USD** | [Spark Research](https://www.spark.money/research/tradfi-defi-convergence-2026) · 2026 |
They did not put those sums on a public chain. They built private infrastructure, or used another institution's. That is the strongest market evidence for this document's claim: **at institutional scale, demand for a controlled private chain has already been paid for; it is not a hypothesis.**
But it also exposes the other half of the problem. Only a very small number of organisations in the world are large enough to build such a platform themselves. Everyone else — mid-sized funds, asset issuers, fintechs, and eventually individuals — needs **the same capability without the same budget**.
#### The second half: AI agents have nowhere to be accountable
At the same time, a new kind of user is appearing far faster.
| Indicator | Value | Source |
|---|---|---|
| AI agents forecast to exist by 2028 | **1.3 billion** | IDC, via [Microsoft](https://www.digitalapplied.com/blog/ai-agent-adoption-2026-enterprise-data-points) |
| Share of enterprise applications embedding task-specific agents, forecast end of 2026 | **40%** (from under 5% in 2025) | Gartner, via [Accelirate](https://www.accelirate.com/agentic-ai-statistics-2026/) |
| Organisations treating an AI agent as **an entity with its own identity** | only **21.9%** | [Strata](https://www.strata.io/blog/agentic-identity/the-ai-agent-identity-crisis-new-research-reveals-a-governance-gap/) |
| Organisations authenticating agents with **static API keys** | **44%** | as above |
| Organisations using **shared service accounts** for agents | **35%** | as above |
| Organisations running autonomous AI without real-time visibility of what agents do and who answers for it | nearly **80%** | [Help Net Security](https://www.helpnetsecurity.com/2026/06/16/delinea-securing-machine-identities-and-agentic-ai/) |
```mermaid
flowchart LR
A["1.3 billion agents
forecast by 2028"] --> B{"Does the agent have
its own auditable identity?"}
B -- "21.9%" --> C["Yes"]
B -- "the rest" --> D["Static API keys · 44%
shared accounts · 35%"]
D --> E["Nearly 80% of organisations
cannot say what an agent did
or who answers for it"]
```
*Figure 4 — The number of agents is growing far faster than the ability to hold them accountable.*
Read that table the other way round: when an agent signs a transaction with a **shared API key**, nobody afterwards can answer the question *who did this*. Not for lack of logs, but because **the identity was merged away at the start**. A log can only record what the system was able to tell apart.
That is why "where does an agent remember, sign, and answer for itself" is not a philosophical question. It is a measured infrastructure gap, and it grows with the number of agents.
> **In short:** the demand here is not "one more blockchain". It is **somewhere private, connectable, and accountable at once** — and a way to have it without an investment bank's budget.
### The problem, and three ways round it
An organisation wanting to step into that space has only three routes, and all three fail in their own way.
| Route | What you get | What you lose |
|---|---|---|
| Old-style enterprise chain | Privacy and control | Cut off from public liquidity |
| Public chain | Liquidity and composability | Every transaction exposed; compliance only at the application layer |
| A database | Simple, cheap, familiar | No multi-party auditable immutability |
#### The first route has been tried, and it collapsed
This is not speculation. The two largest platforms that tried exactly this approach have both shut down, and both were strong in every respect but one.
| Platform | Behind it | Outcome | Source |
|---|---|---|---|
| TradeLens | Maersk and IBM, launched 2018, running on Hyperledger Fabric | Discontinuation announced 11/2022; access closed **31/3/2023**. Stated reason: it did not reach the industry-wide collaboration required, nor the commercial viability to stand alone | [Maersk](https://www.maersk.com/news/articles/2022/11/29/maersk-and-ibm-to-discontinue-tradelens) · [The Register](https://www.theregister.com/2022/11/30/ibm_and_maersk_tradelens_shutdown/) |
| we.trade | A joint venture of **12 European banks** and IBM, licensed for use by 16 banks across 15 countries | Ran out of cash, could not raise more, entered insolvency in **2022** | [GTR](https://www.gtreview.com/news/top-stories/we-trade-calls-it-quits-after-running-out-of-cash/) · [Ledger Insights](https://www.ledgerinsights.com/hsbc-socgen-ibm-backed-blockchain-company-we-trade-starts-insolvency-procedure/) |
Both had working technology, large names behind them, and early members. What they did not have was **a reason for the twentieth party to join after the tenth had joined**. A closed network is worth only as many members as it has, and the cost of convincing the next one never falls.
That is death by isolation, and it has a name of its own: **the value of the network is capped by the network's own boundary.**
#### The second route forces a choice between liquidity and secrecy
A public chain gives liquidity, but forces an organisation to expose its books to competitors. And it pushes the whole compliance obligation up to the application layer, where one carelessly written contract is enough to slip through — while, as *Market demand* showed, that obligation now **differs by jurisdiction** and must be proven to each regulator.
#### The third route is often the right one, and this document says so plainly
If your problem is one party's internal data, use a database. It is cheaper, faster, and your team already knows how to run it. A blockchain only repays its cost when several parties who do not fully trust each other need interoperability and auditable immutability.
#### The diagnosis
The problem is not "not fast enough". It is: **there is nowhere that is private inside, openable outward under control, and able to enforce compliance at a layer applications cannot reach — while being cheap enough for an ordinary organisation to have one.**
That last clause is the one usually forgotten. The two institutions in *Market demand* solved the first three clauses by building it themselves. That proves the problem is solvable, and at the same time proves that this way of solving it **is available only to a very few**.
```mermaid
flowchart TB
G["The gap
private inside · controlled opening outward
compliance beneath the application layer"]
G --> A["Compliance becomes a property
of the protocol"]
G --> B["Privacy and interoperability
coexist"]
G --> C["A chain becomes something
that can be produced"]
A --> R["A chain drops from an infrastructure project
to a reviewable declaration"]
B --> R
C --> R
```
*Figure 5 — Three contributions, all leading to one result.*
Those three contributions are:
1. **Compliance is a property of the protocol, not of a contract.** Allowlists, roles and KYC references live in a consensus module, enforced across five independent layers.
2. **Privacy and interoperability coexist.** The internal ledger stays private; only selected assets bridge outward, through a gated bridge.
3. **A chain becomes something that can be produced.** The whole lifecycle — key generation, genesis assembly, deployment, self-healing, teardown — is encoded as a loop that keeps returning the system to its declared state.
> **In short:** the question is not "which chain is faster", but **who is allowed to have a chain at all** — and whether it can connect to the rest of the world.
### Compared with the alternatives
Set the axes first, rank afterwards. Four decisive axes: are internal transactions private from outsiders; can it connect to public liquidity; what buys its security; and at which layer is compliance enforced.
| System | Private inside | Connects publicly | Security bought with | Compliance at layer |
|---|---|---|---|---|
| 9Chain | Yes | Yes | Identity, contracts, multiple parties | **Protocol** |
| Old-style enterprise chain | Yes | Very limited | Identity | Application |
| Token-secured appchain | Depends on configuration | Yes | Token value | Application |
| Rollup | No | Yes | Inherited from the layer below | Application |
| Plain Cosmos appchain | Depends | Yes | Staked tokens | Application |
```mermaid
quadrantChart
title Internal privacy and public interoperability
x-axis "Isolated" --> "Interoperable"
y-axis "Transactions exposed" --> "Private inside"
quadrant-1 "Private and interoperable"
quadrant-2 "Private but isolated"
quadrant-3 "Exposed and isolated"
quadrant-4 "Exposed but interoperable"
"9Chain": [0.78, 0.82]
"Old enterprise chain": [0.18, 0.85]
"Token appchain": [0.75, 0.45]
"Rollup": [0.85, 0.14]
"Cosmos appchain": [0.72, 0.4]
```
*Figure 6 — 9Chain aims at the top-right corner: private inside, interoperable outward under control.*
This table needs reading correctly. 9Chain does not win every cell, and does not try to. It aims at **the intersection of all four at once**, and that is a genuinely narrow niche rather than the whole market.
And one more thing must be said that the table has no column to score: **an identity shared across chains**. That is the axis 9Chain aims at most — and also the axis the project **has not finished proving**, because the shared identity scheme is still on the open list. We did not add that column, because adding a column and scoring yourself highly on unfinished work makes it an advertisement rather than a comparison. The argument is in [*The 9Chain platform*](/en/the-9chain-platform), under **Many chains, one identity**.
For a public application maximising composability, a rollup is the better answer. For an organisation that only needs an internal ledger and no interoperability, a database is the better answer.
#### "Is 9Chain a blockchain? Which layer is it?"
The first question answers itself: yes. 9Chain is a blockchain — a public network with the native token **LOVE9**, which the industry calls **Layer 1**.
The second is trickier, because the name 9Chain **covers three things** that sit in three different places on that scale. The table below separates them, and it is the table to hand anyone who asks.
| What you are asking about | Is it a blockchain | Place on the layer scale |
|---|---|---|
| **The 9Chain network** — the project's public network, native token **LOVE9** | **Yes.** This is what carries the name first | **Layer 1** |
| *[*The 9Chain platform*](/en/the-9chain-platform)* — the machine that produces chains for customers | **No.** It is the thing that *produces* blockchains; it is not one itself | the **Layer 0** position |
| **Each chain produced for a customer** | **Yes** — a private EVM appchain, running independently, able to survive even if the platform disappears | **Layer 1** |
| Layer 2 | — | **none, and none intended** |
In one sentence: **9Chain is a Layer 1 blockchain — and the same name also refers to the machine that produces other blockchains.** If you meet a document calling 9Chain a Layer 0, it is talking about **the second row**; if you meet one calling it Layer 1, it is talking about **the first**. Neither is wrong — they point at two different things under one name.
For the **Layer 0** reading — the platform reading — three things must be said alongside it, or the label leads you astray:
| What must be said alongside | Why |
|---|---|
| **Cosmos-style, not Polkadot-style** | Each chain produced keeps **its own validator set**. There is **no shared security** here — a deliberate choice, because the shared model means outside validators see the data, destroying the very thing customers need |
| **It stands ON such a layer, it does not replace it** | Chains produced use the existing Cosmos framework and existing interchain bridges. 9Chain's contribution is **whole-lifecycle automation** and **a compliance gate inside consensus**, not reinventing the base layer |
| **This scale has no cell for the thing that matters most** | Layer 0/1/2 ranks by *speed · fees · connectivity*. No cell asks *"at which layer are the rules enforced"* or *"is the data private even from the operator"* — and those are the two axes 9Chain lives or dies on |
So this document **does not define 9Chain by the words "Layer 0"**. That classification itself admits it is not a technical standard but **a sorting term of one era** — the same project can be called Layer 0 in one document and a multi-chain Layer 1 in another. A name whose meaning shifts with the speaker is fine for **pointing at a position** and useless as **a definition**.
> ⚠️ **Do not confuse this with the "four tiers" in [*The 9Chain platform*](/en/the-9chain-platform).** Those tiers — chain base · chains produced · platform · value — are how this document describes the **internal architecture**. They are **not** the industry's Layer 0/1/2, and the two schemes **do not map onto each other**. That is why those four tiers are deliberately left unnumbered.
> **In short:** an honest comparison must be able to say **when not to choose you**. Without that sentence it is an advertisement.
## Nine missions
> ### Nine Missions for Nine Billion
This page is written for someone **not yet born**.
The nine missions are not nine things 9Chain promises **to** anyone. They are nine things 9Chain undertakes **together with** — together with all of humanity, and with whatever lies beyond this planet — across **all three tenses: past, present, future**.
And those three tenses are **not three groups**. Splitting the nine pillars into a past group, a present group and a future group is wrong, because that split implies some pillars only deal with what has been and others only with what is to come. **No pillar is like that: every pillar lives in all three tenses at once** — it deals with what has already happened, it does something for a person alive now, and it leaves something for those not yet here. A pillar missing one of those three faces is a pillar not finished: caring only for the present is cruel to the past, caring only for the future is an empty promise, caring only for the past makes a museum.
**The word "universe" here is not science fiction — it is a constraint on the writing:** none of these nine may be written in a way that is only true for **one planet, one country, one era**. Wherever such an assumption is needed, that passage is written wrongly.
**The nine pillars are nine verbs, not nine values.** A value is declared; a verb has to be done, and doing can be counted. So each pillar comes with **a measurement** and **a refusal** — the place where you check us, and the place where you catch us doing the opposite. This is also the **only** page in the document written in the future tense.
**One rule that stands above all nine:** the project imposes a rule on itself — *what cannot be measured on chain does not count*, and **when words and chain disagree, the chain is right** — including when the words are ours. This rule was once a pillar, named *Transparency*; it was lifted above because **it is the condition that makes the other nine mean anything**. Its own measurement: the numbers we publish that you **cannot** trace back to a chain query must be **zero**.
```mermaid
flowchart TB
T["ANY ONE PILLAR
of the nine"]
T --> A["with the PAST
how it treats
what has already happened"]
T --> B["with the PRESENT
what it does for
a person alive now"]
T --> C["with the FUTURE
what it leaves for
those not yet here"]
```
*Figure 7 — The three tenses do not divide the nine pillars; they cut across each one. A pillar missing a face is not finished.*
| Pillar | With the past | With the present | With the future |
|---|---|---|---|
| **1 · Gratitude** | record what was done, never let it expire | repay by a readable formula | those who come later still know who laid the first stone |
| **2 · Healing** | correct what was recorded by adding, never erasing | give a person a second chance | leave a path of correction for later generations |
| **3 · Consent** | judge what happened, in public | rules made by those who live under them | decision power leaves the builders' hands |
| **4 · Honour** | count people, not what they accumulated | one person, one share, nobody two | keep that unit of counting as scale grows |
| **5 · Protection** | the recorded part of a life is not lost with the record keeper | the key stays in the owner's hands | the ledger outlives whoever built it |
| **6 · Enablement** | nobody pays a price for arriving late | the first step demands no assets | lower the threshold for those not yet born |
| **7 · Connection** | an identity once built need not be rebuilt | one identity shared across many chains | stopping at no border, including a planet's |
| **8 · Resonance** | shared work is credited to both sides | strangers cooperate without trusting each other | the greater the distance, the more it is needed |
| **9 · Preservation** | the oldest record is still readable | preserve while still allowing change | no finish line, and never a 10.0 |
The order of the nine below is **a reading order, not an order of importance**.
#### 1 · Gratitude
> *What you did for others never expires.*
Every system forgets those who came first, precisely as it begins to grow. Gratitude here is a mechanism rather than a thank-you: **what was done is repaid, retroactively, by a formula anyone can read on chain**. But the worst way to be grateful is **to hand early arrivals an advance allocation** — so the guardrail sits right here, and it is something **readable in the genesis file** rather than an engraved line: **no team allocation · no fund allocation · no premine · no sale to anyone.**
**How you know we kept our word:** the distance between the largest share and the median share, together with how much of what was issued was paid **retroactively for work done**.
**What we refuse:** every priority allocation round, including one for the builders themselves.
#### 2 · Healing
> *A ledger that never forgets must learn to forgive.*
Immutability has its cruel face: **a mistake once recorded stays there forever**. The paper world heals by **erasing** — and erasing is possible only because the ledger belonged to someone else. In a ledger nobody can erase, healing must be **adding**: the correction sits beside the error, and the system acts on the latest entry. That is the difference between *forgetting* and *forgiving* — forgetting is memory loss, forgiving is remembering and letting the other walk on. **The youngest pillar of the nine.**
**How you know we kept our word:** whether a wrong decision recorded on chain can be corrected by **another public record** — or only by rebuilding the whole network.
**What we refuse:** every mechanism that erases history, even one that acts in the name of correction.
#### 3 · Consent
> *The rules are ours — and so is the verdict, when we disagree.*
Consent is easy when everyone agrees; it is only worth something at the moment of disagreement — and **every disagreement is a disagreement about something that already happened**, which is why this pillar belongs to the past rather than to intent. Thousands of networks have become excellent at agreeing on **the order of transactions**, but almost none has managed to agree about **people**: who is who, and who is right when two people say opposite things. The rules are ours; disputes are settled **publicly, on data anyone can read**.
**How you know we kept our word:** what share of voting power sits **outside** the project's hands, and whether any proposal has passed with the project not in the majority.
**What we refuse:** every decision about the rules taken off chain.
#### 4 · Honour
> *Make the human being the thing that is counted.*
You may be richer than me, stronger than me, better schooled than me — but you cannot be **two human beings**. A network that counts electricity rewards whoever has more machines; a network that counts capital rewards whoever has more money: both amplify existing distance **by design, not by accident**. Honour here is a cold decision — **choose the right thing to count**, because a system will produce more of whatever it honours.
**How you know we kept our word:** whether what is issued flows into the wallets of verified human beings, and what percentage does.
**What we refuse:** every reward mechanism scaled by capital or by seniority.
#### 5 · Protection
> *The ledger written about you is yours — and nobody can take it away.*
Everything you do in a day is written into somebody else's ledger: they change the terms without asking; they close down and the recorded part of your life goes with them. **Owning something you cannot hold is ownership on paper only** — so three things must hold at once: the key in the owner's hands, the contents private even from whoever runs the infrastructure, and the ledger living on when its builder does not.
**How you know we kept our word:** how many running chains have **their keys in the hands of their own owners** rather than the platform's.
**What we refuse:** every architecture that makes users rent space inside someone else's ledger.
#### 6 · Enablement
> *You should not need to already have, in order to begin.*
On almost every network, to take your **first** action you must **already have money**. That is a silent door, and it closes in front of exactly the people a worldwide network needs most. **The first step is always the most expensive one, and most expensive for those with least** — so here, not paying a fee to begin is a position, not a convenience.
**How you know we kept our word:** how many people completed their first action **with an empty wallet**.
**What we refuse:** every step that requires a newcomer to hold assets before taking part.
#### 7 · Connection
> *One identity, travelling with the person everywhere.*
How many times a day must you prove you are you, starting over each time? When there are millions of networks, the scarce thing will not be one more ledger — it will be **an identity every ledger recognises**, something you carry the way you carry your face. That sentence deliberately does not say "every ledger **on Earth**": an identity forced to stop at a border is not yet an identity.
**How you know we kept our word:** how many identities are recognised by **two or more** places at once.
**What we refuse:** islands — however beautiful the island.
#### 8 · Resonance
> *Strangers who need not trust each other, making what none could make alone.*
If connection is the road, resonance is the traffic on it: **cooperation without trust** — something humans have managed in village markets and guilds for thousands of years, but never at **planetary scale**. The word *resonance* is more accurate than *joining forces*: it is not addition but **amplification** — and because it amplifies the bad as well, it must stand after *Consent* and *Protection*. The greater the distance, the less trust exists in advance, so this becomes more necessary rather than less.
**How you know we kept our word:** what share of transactions have **two independent parties**, rather than two wallets of the same person.
**What we refuse:** every feature that serves a single party alone.
#### 9 · Preservation
> *Exist forever, and evolve forever. There will never be a 10.0.*
A child born in 2100 opening this ledger must be able to read its first line, verify that whoever wrote it kept their word, and correct our generation's mistakes without tearing it down and starting again. But *preservation* is **not freezing** — what is only kept and never changed decays. Three things are preserved: **the record still exists · the way to read it still runs · the promise made can still be checked** — and all three must survive changes nobody can yet imagine, including changes in where human beings live.
**How you know we kept our word:** whether the oldest retrievable record still reaches the very first block — and how many steps remain on the scaffolding-removal schedule.
**What we refuse:** every decision optimised for this quarter that closes a door ten years out.
---
### What the nine pillars stand on
A mission attached to nothing that runs is only literature; a mission bolted to the system's current shape dies with that shape. This table holds both ends.
| Pillar | What it rests on | The part that outlives the method of one era |
|---|---|---|
| **Gratitude** | retroactive repayment for work done — [*Nine roles*](/en/nine-roles) · [*LOVE9 economics*](/en/love9-economics) | the repayment formula will be voted on many times; **the principle of paying retroactively — nobody draws in advance on merit — is settled** |
| **Healing** | upgrades with migration, history preserved across periods — [*Before you read*](/en/before-you-read) | most of the correction path is still missing; **the principle of correcting-by-adding is settled** |
| **Consent** | on-chain voting, the direction of a change decides the authority — [*Operations and governance*](/en/operations-and-governance) | voting forms will differ; **that rules are made by those who live under them will not** |
| **Honour** | the *who is who* tier stands before every paid role — [*Nine roles*](/en/nine-roles) | how a human is attested will change many times; **counting people rather than machines will not** |
| **Protection** | enforcement across five layers and a gate at the border — [*The 9Chain platform*](/en/the-9chain-platform) | the holding mechanism will one day have another name; **what is held is still the ledger owner's right** |
| **Enablement** | the first step demands no assets — [*LOVE9 economics*](/en/love9-economics) | the entry threshold will move; **the rule "you should not need to already have in order to begin" will not** |
| **Connection** | one identity shared across many chains — [*The 9Chain platform*](/en/the-9chain-platform) | connecting protocols will replace one another; **not having to rebuild yourself at every door will not** |
| **Resonance** | cooperation between parties who need not trust each other — [*Applications and users*](/en/applications-and-users) | the scale will grow; **the condition — nobody in the middle charging and judging — does not change** |
| **Preservation** | the constitution frozen by a hash published before engraving — [*LOVE9 economics*](/en/love9-economics) | this very chain is also the technology of one era; **what must survive is the record and the way to read it** |
The table deliberately **does not say how far anything has got**: what actually runs is in [*Open questions and concerns*](/en/open-questions-and-concerns), and which level the network stands at is in [*Check the network yourself*](/en/check-the-network-yourself).
### Where we are furthest away
The three hardest measurements — those of *Consent*, *Healing* and *Gratitude* — are all measurements of the **past face** of those pillars, and that is no coincidence: promising is cheap, treating what has already happened decently is what costs. All three turn green only when these gates are passed: **voting power leaves the project's hands** · **a wrong decision can be corrected by another record rather than by rebuilding the network** · **the way contributions are repaid is engraved as a readable formula**. *Protection* is not green either, because its measurement still depends on nodes leaving one place. A young project has not passed them — that is not a moral failing, it is **age**. And all four hard places share one route, which is also the cheapest: **spread the nodes out of one place, then engrave a handover schedule anyone can check.**
Three things these nine pillars do **not** say: no date is promised · no claim that they are achieved · no claim that they will not change. What is permanently engraved is only three memorial blocks and one rule — the rule that everything else, this page included, belongs to those who come after, and they may rewrite it.
> **In short:** do not judge us by how well these nine pillars read; judge us by **the distance between the nine pillars and their own nine measurements** — a distance you can measure without anyone's permission.
## Applications and users
Every page so far has been about mechanism. This one is about **people**: who needs what has been described, at **which moment** they need it, and — no less important — **whether they can use it yet**.
The nine audiences fall into four groups by their relationship to a chain: those who **build** one, those who **keep it alive**, those who **verify** it, and the **end users**. Each table below has the same four columns, and the last is the honest one: **which level unlocks it for them**.
⚠️ **This order follows who can use it first, not who matters most.** The project positions itself as *a multi-chain blockchain network belonging to everyone*, yet "everyone" sits in the last two rows and cannot use it yet. That is not an oversight — it is the order of the road: organisations pay first, and it is that money which funds the distance to individuals. Individuals come last because putting them first would be selling something that does not exist. But to say it fully: **if that distance is never covered, the positioning is only a phrase.**
```mermaid
flowchart TB
N1["LEVEL 1 · It runs"] --> N2["LEVEL 2 · Open to outsiders"]
N2 --> N3["LEVEL 3 · Real self-service"]
N3 --> N4["LEVEL 4 · Real assets"]
N1 -.- P1["1 · Asset issuers
2 · Fintechs and tokenisation firms
6 · Auditors
7 · Regulators"]
N2 -.- P2["3 · Multi-party consortia
4 · Validator operators
5 · Customer-side operations teams"]
N3 -.- P3["8 · Individuals"]
N4 -.- P4["9 · AI agents
and EVERY other audience
once real value is touched"]
```
*Figure 8 — The nine audiences placed on the maturity ladder. The further down, the further away.*
### Those who build a chain
| # | Audience | The moment they need 9Chain | Answered by | Unlocks at level |
|---|---|---|---|---|
| 1 | **Asset issuers** — funds, certificate issuers, stablecoin issuers | When a regulator asks *"prove that only approved wallets can receive this asset"* — and the answer cannot be "our contract checks it" | The compliance gate inside consensus, beneath a contract's reach | **1** to trial · **4** to touch real assets |
| 2 | **Fintechs and tokenisation firms** | When the task is to ship a product, and the first quote received is a six-month infrastructure project | A chain raised from a declaration; the lifecycle already encoded | **1** |
| 3 | **Multi-party consortia** — several institutions on one ledger | When the second party asks *"why should we trust your servers?"* and the third party will ask exactly the same | Multi-party mode; a threshold stopping anyone from holding more than a third of voting power | **2** — because each member must be able to run a node |
These three are the demand already proven with money in [*Context*](/en/context): it is precisely the absence of such a place that forced the largest institutions to build their own infrastructure, while the rest of the market could not.
### Those who keep a chain alive
| # | Audience | The moment they need 9Chain | Answered by | Unlocks at level |
|---|---|---|---|---|
| 4 | **Validator operators** | When invited to join a network whose condition of entry is **buying and holding** that network's token | Identity-based validators, bound by contract, paid in real money | **2** — needs participation artefacts and a publicly published node image |
| 5 | **Customer-side operations teams** | When leadership asks *"if the vendor switches off, do we still have our ledger?"* | The operator generates genesis, peer list and keys so they can run a node on their own infrastructure | **2** — same reason |
The fifth audience is what makes the phrase "multi-party" mean anything. If every node is run by one party, every promise about decentralisation is a figure of speech.
And here the document must point out a constraint on itself: **both of these unlock at level 2** — the level whose gate is **participation artefacts published publicly**. A network that has not published them cannot yet call itself multi-party to outsiders; it is only multi-party with those it invited.
### Those who verify
| # | Audience | The moment they need 9Chain | Answered by | Unlocks at level |
|---|---|---|---|---|
| 6 | **Auditors** | When they must answer *"was any transfer blocked last month, and why?"* — a log holding only successes cannot answer that | An on-chain audit role; every refusal emits an event, including refusals at the interchain border | **1** |
| 7 | **Regulators** | When they need to know at which layer enforcement sits, and who is accountable when something goes wrong | A compliance gate at the protocol layer; a clearly written responsibility boundary between platform and issuer | **1** to present · **4** to license |
These two **read** the chain rather than run it, so they are easily forgotten at design time. But they decide whether a chain may touch real assets at all — so they must be served from the start, never added afterwards.
### End users — the part not yet reached
| # | Audience | The moment they need 9Chain | Answered by | Unlocks at level |
|---|---|---|---|---|
| 8 | **Individuals** | When they want a ledger nobody can switch off, but know nothing about infrastructure and do not want to | Describe in words, a human approves, the machine builds | **3** — needs accounts, chains with owners, and low enough cost |
| 9 | **AI agents** | When an agent signs for something and afterwards nobody can answer *who did this* | Its own identity anchored at the protocol layer instead of a shared key | **4** — and also a published shared identity scheme |
These last two are **the reason the project exists**, and at the same time the two that **cannot use it yet**. *Market demand* shows the gap for the ninth growing very fast: agent numbers rise exponentially, the share of agents with their own identity does not.
The document places them at the end of the list rather than the start, because placing them first would be selling something that does not exist.
### Who is NOT among the nine
A list containing only invitations is a suspicious list. The four groups below are not 9Chain's audience, and saying so is cheaper for both sides.
| Not an audience | Why | What to use instead |
|---|---|---|
| An organisation needing only one party's internal ledger | There is nobody to distrust | A database |
| A public application maximising composability | Privacy here is a constraint, not a feature they want | A rollup or a public chain |
| An organisation wanting **absolute control** of its chain | Directly contradicts the one-third threshold: if one party can always decide, multi-party immutability means nothing | A database with an audit log, and say so plainly |
| Someone looking for a token to speculate on | The project does not sell, does not list, does not support the price | There is nothing here for them |
The third group is the easiest one to lose, because they usually have budget and believe they are buying a blockchain. What they actually want is a database that looks like one.
### One gate cutting across all nine
Four audiences can use it at the lowest level — to trial, to build, to verify. Three more wait for *Open to outsiders*. The last two are further off still.
But one boundary cuts across all of them: **the moment someone else's real value is on the chain, every audience stops at the same gate** — the *Real assets* level, with independent audit, a settled legal framework, and distribution across failure domains. Nobody routes around that gate, not even the first audience.
> **In short:** a platform is only trustworthy when it can say **who cannot use it yet**, and **who should not use it**, as clearly as it says who already does.
## LOVE9 economics
> **Label: PROPOSED** for every number on this page, **without exception** — the current constitution engraves no number at all, not even the four zeros (see *The only thing engraved permanently* at the end). The numbers were drafted by the founding group and are **voted on by the community**; each period's genesis turns them into an **opening record**, not into permanent law. They are not commitments, not an offer, not investment advice. The cheapest door for changing a number here is **before genesis** — see [*Before you read*](/en/before-you-read).
LOVE9 is **the native token of the 9Chain network** — the project's public Layer 1. It is entirely separate from customer chains' fuel tokens, and is never a condition for a customer chain to operate.
### The four zeros
No allocation for the team. No allocation for investment funds. No premine. No token sale to anyone.
These four once sat in the constitution as a permanently engraved clause, and earlier versions of this very document said exactly that. The current constitution reduces the engraved list to **three memorial blocks and one rule**, so the four zeros **leave the engraved text**: they are **a verifiable fact of each period's genesis file** — open it and you see no team allocation, no fund, no premine, no sale — and **a proposal to keep them for every period after**, which the community can change by vote like anything else.
That moves where trust rests, and the uncomfortable direction should be said outright: under this rule, a later community **has the right** to vote an allocation to some group. What stops it is no longer a line nobody can change — it is that it must **win a public vote on chain**, in front of everyone, and the record of that vote stays permanently. You are no longer invited to believe a promise; you are invited to **read the genesis file of the running period**, and to watch the single door every change must pass through.
### The proposed parameters
| Parameter | Proposal | Note |
|---|---|---|
| Total supply | 81 billion, that is 9² billion | no inflation, no further minting — and once the network charges fees the total supply **only goes down**, because part of each fee is burned |
| The claim | 81 billion divided among roughly 9 billion people is 9 each | "9 billion" is an **aspirational and symbolic** figure, not a population forecast |
| Genesis | A single endowment holds everything except operating capital | operating capital is self-declared on chain by a document engraved in genesis |
| Release rhythm | 0.09% of the **unreleased issuance base**, per day | the base is the **endowment's balance at genesis** — total supply minus operating capital — not the total-supply constant; see *Three near-equal parts* |
| Half-life | about 770 days | the flow shrinks but never reaches zero |
| Fee split | **9% back to the endowment · 9% burned · 82% to signers** | **a commitment with a gate attached, not a flow already running**: the network charges **no fees**, so there are no fees to split yet. Enabling fees is only permitted after the 9% split mechanism is on chain — that ordering is what keeps the commitment from being empty words |
| Validator ceiling | 81 | the gate to running a validator is still to open; genesis deliberately grants no gatekeeper role |
**What operating capital consists of, and why it does not contradict the four zeros.** It is split across four wallets, and the ratios say more about intent than any pledge: nearly **nine tenths** is there to **hand out to people who come to try the network, and to pay their fees for them**; about **one tenth** is the founding validators' stake, **forced into genesis**; the remainder — barely over one percent — covers governance deposits and the faucet. None of those four wallets is an allocation to a person or an organisation.
And a rule that matters as much as the structure: this is **an advance, not a grant**. Unspent funds and stake released from bonding **return to the endowment**, and the advance itself **is not deducted from the issuance base** — meaning it takes nothing from anyone in advance. The check is the same as everywhere else on this page: open the running period's genesis file and count, do not trust the table.
### Three near-equal parts
| Part | Meaning | For |
|---|---|---|
| VERITAS | truth | verified real human beings, one share each |
| LIBERTAS | freedom | keeping the network alive — the **destination** is that nobody can switch it off |
| AETERNUM | eternity | the builders, and a future the community decides |
> ⚠️ **LIBERTAS is a destination, not a description of the present.** A network is only truly *un-switch-off-able* when its nodes run by **several independent parties**, on **several independent infrastructures** — that is the condition, and it is checkable from outside. Until it is met, this part pays for **the work of getting there**, not for a state already reached. Writing it the other way turns a goal into a false statement.
```mermaid
flowchart TB
K["ENDOWMENT
holds everything unreleased"]
K -->|"0.09% of the remainder
per day"| S["The day's released flow"]
S --> V["VERITAS
one third"]
S --> L["LIBERTAS
one third"]
S --> A["AETERNUM
one third"]
V --> W["Recipient wallets"]
L --> W
A --> W
W -.->|"9% of fees
once the network charges fees"| K
W -.->|"9% of fees BURNED"| B0["Out of circulation
permanently"]
V -.->|"surplus beyond real need"| K
L -.-> K
A -.-> K
```
*Figure 9 — One endowment, one formula, three parts splitting each day's flow, and two paths back to the endowment.*
**Why the three parts are *near*-equal rather than exactly equal:** the release formula takes as its base the **endowment's balance at genesis** — total supply minus operating capital — rather than the total-supply constant. This was once settled the other way and then reversed, and the reason for reversing is worth more than the conclusion: when two of the project's own documents declared **two different bases for the same formula**, the honest fix was not to pick whichever was written more boldly, but to pick the base that **matches the real money sitting in the endowment** — so that the number engraved at genesis promises no coin without something real behind it. With a balance as the base, each part has an **asymptotic ceiling** of one third of that balance, and no day ever reaches it — because the endowment never empties. **Each day's** flow is still split into three exactly equal parts; what is only asymptotic is each part's **cumulative total**. Which base to use remains a design decision rather than an accounting detail — and, like every number here, the community can vote on it.
The three parts **exist from genesis with a zero balance**, and only hold funds once the distribution mechanism is built later. That sounds like bookkeeping, but it is a safety rule: each part's address is derived from **its name**, so outsiders can compute that address **before** the account exists — and an address that does not exist and is not on the blocked list means anyone who sends funds to it **locks them forever**. Creating the three empty wallets up front is the cheapest way to close that trap.
Released funds nobody has claimed stay as a buffer, and **never raise any day's issuance ceiling**. As a result nobody is owed anything, and nobody is promised a number with their name on it.
### Left blank on purpose: how it is received
**How** a human being receives their share **has not been designed.** The proposed distribution says *who* receives — verified real human beings, one share each — with two constraints: it must be measurable on chain, and it must be settled by vote; the minimal constitution leaves even that to the community. What does not change is the order: the three parts have wallets from genesis but zero balances, and **the endowment cannot open until a receiving mechanism has passed a vote** — this blank is a structured blank, not an oversight.
A foundational document willing to leave that box empty, rather than fill it with a good-sounding mechanism, says more than the boxes already filled.
### Three token layers, never to be confused
| Layer | Token | Role | Transferable |
|---|---|---|---|
| Infrastructure | LOVE9 | distribution from the endowment, staking, governance | Yes |
| Fuel | a nominal gas token | quota accounting against abuse | No |
| Assets | tokens created by issuers | real-world assets, stablecoins, products | Through the compliance gate |
> **And one thing that is NOT among those three layers: community points.** The project's community platform records contributions with a **points** system, not with the network's token. Points do not live on chain, cannot be staked, cannot vote, and **whether points convert into anything at all is LEFT BLANK** — nobody has decided. This is the easiest confusion in the whole document because the two things have similar names, so it is said once, plainly: **anyone who guarantees you a conversion rate from points to tokens is putting words in the project's mouth — nobody has decided that.**
### The only thing engraved permanently: three blocks and one rule
The project's constitution — formally the **LOVE Paper**, initial version **V0.0** — may be the shortest constitutional text in the industry: it keeps only **three memorial blocks** and **one rule**.
The three blocks: **Block 1** engraves Genesis 1:1 in the original Hebrew — heaven and earth, before humankind. **Block Adam** — *the first human*: the first block whose time passes **09:09:09 Jerusalem time on 09/09/2026**; it deliberately **names no block number**, because block numbers depend on network rhythm while time does not, and the date is a rule of the founding period rather than part of the constitutional text. The hour is anchored to **Jerusalem** rather than to a convenient time zone, because what is engraved in the first block is Genesis in the original Hebrew — the announced hour must be consistent with the thing engraved. A technical consequence worth remembering: because the moment is set in Jerusalem time, **its universal time drifts with the seasons**; anyone adding the offset by hand will be an hour out for half the year. **Block Eva** — *the second human, and the first "we"*: the block immediately after Block Adam. That order is itself a sentence: first heaven and earth, then a human being, then *we*.
**Why that text, and what the project does NOT claim.** Block 1 engraves a sentence roughly three thousand years old, read by many different traditions — that is why it was chosen: not because the project follows any faith, but because a ledger meant to live for centuries needs **a reference point older than every existing technology**. It is engraved as **an artefact with a date**, the way one lays a foundation stone, not as a profession of belief.
Four things stated plainly, so nobody has to guess. **9Chain has no religion, represents no religion, and neither favours nor excludes anyone for their beliefs.** **No rule of the network derives from the content of those three blocks** — they are referenced by no consensus, issuance or governance mechanism; remove their content and every formula in this document still runs unchanged. The names *Adam* and *Eva* are used here to mean **the first human and the second human**, the point where a ledger turns from *I* into *we*; anyone reading another meaning into them will get no argument from this document, only a statement of the meaning it uses. And the project's name **borrows from no faith** — the reasoning behind the number nine is in [*Taking part, and the doors still owed*](/en/taking-part-and-the-doors-still-owed), and it is a way of checking ledgers, not a sacred symbol.
One further consequence must be stated in full, because it touches operators rather than readers: the engraving is **immutable**, so anyone running a node of this network holds and re-serves that content. In some jurisdictions, storing and distributing religious content is separately regulated — and **engraved text cannot be taken down**. Operators in those places should check their own obligations before running a node. The project states this constraint rather than leaving others to discover it later.
One rule, and it is the entire remainder of the constitution: **everything else about 9Chain — every number, every rule, every share — belongs to the whole community to decide together, for as long as the network lives.**
These three blocks are engraved again in **every period**, and under the four-period rule **only the mainnet engraving is permanent** — the testnet ones are rehearsals.
The constitution's content is frozen by a hash published **before engraving**, so anyone can hash it again and reconcile the on-chain text with the published one.
> **A consequence few anticipate, and it cuts both ways.** Because engraved text is immutable, **changing a sentence in the constitution does not change what was already engraved**. The version on a period's chain is always the version as of that period's birth; new wording only reaches the chain at the **next rebuild**. So when text and engraving differ, the correct reading is: the text says what the project **intends** to engrave, the engraving says what the project **has** engraved. That gap is not itself a fault — it is the price of immutability, and one more reason **only the engraving on the official network is final**. To find out whether the two differ, do not ask: read the on-chain text and hash it again.
> **In short:** this constitution engraves no number — **not even a zero**. What is permanently engraved is three memorial blocks and one rule: everything else is decided by the community together. Any document calling one of the project's numbers *unchangeable forever* — including this one, in versions anchored earlier — misstates the current constitution.
## Nine roles
> 🟡 **Label: PROPOSED.** This entire page was drafted by the founding group and **has not been ratified by any vote** — not even the nine names. The document publishes it **early and deliberately**: to receive criticism while it can still be changed, rather than after it is engraved. You can change it, and [*Taking part, and the doors still owed*](/en/taking-part-and-the-doors-still-owed) explains how to send criticism.
> Why it **cannot** be ratified yet is in the last section of this page — the most candid section in the whole document.
### Why this set has to exist
The proposed tokenomics sets one principle, and that principle creates a debt:
> *All three parts pay for **tasks, not for a group of people** — flow beyond a task's **real need** **returns to the endowment**.*
It sounds perfectly fair. But it drags in a technical consequence that cannot be dodged: to know what **exceeds** real need, you must know **the real need of which task**. And **no document has listed those tasks**.
No task list ⇒ no computable real need ⇒ no ceiling ⇒ no way to know what exceeds it and returns to the endowment ⇒ **the issuance mechanism has too few inputs to begin being written**.
The nine roles are that list. They are not nine names to round out a number — they are **a precondition of the issuance mechanism**.
### How is this different from the nine audiences?
Two sets of nine, two different questions. **The nine audiences** answer *who uses this system*. **The nine roles** answer *who does work inside this system, and what they are paid with*. One person can be an audience and hold several roles.
### Tier A — who is who
Before roles comes identity. This tier is **not a role** and **is not paid**.
| | |
|---|---|
| **HUMAN** | The unique identity in the system. One verified real human being — one identity, one share. This is the ground, and what all nine roles serve |
| **DELEGATION** | Everything else acts **by delegation**, and accountability always returns to the humans behind it. Every delegation is declared on chain: scope · duration · revocation path · who is accountable |
An AI agent is **the most urgent case** of delegation, not the only one: an organisation, a co-signing group, a device signing for its owner all use the same scheme. This is also the correct statement of the counting principle: **only humans are counted; everything else is an extension of a human's arm.**
Both humans and delegations can hold roles in the tier below — **except the Citizen role, which only a human can hold**. If an agent could vote, whoever has more servers would have more votes, and we are back at exactly what the Honour pillar removes: counting machines instead of people.
```mermaid
flowchart TB
A["TIER A · WHO IS WHO
HUMAN · DELEGATION
not a role · not paid"]
A --> V["VERITAS
build and protect the truth about people"]
A --> L["LIBERTAS
keep it un-switch-off-able"]
A --> E["AETERNUM
build and steer the future"]
V --> V1["1 Sponsor
2 Gate
3 Juror"]
L --> L1["4 Signer
5 Witness
6 Connector"]
E --> E1["7 Builder
8 Chain holder
9 Citizen"]
```
*Figure 10 — The nine roles arranged by the three parts of issuance. Order within each set follows the lifecycle, not importance.*
### VERITAS — build and protect the truth about people
| Role | Task | Paid from | Loses the role when |
|---|---|---|---|
| **1 · Sponsor** | Brings a newcomer **across the entry threshold** — whether that threshold is a fee, a device, a language or understanding. **The only role that spends first**, reimbursed only when the sponsored person passes a real gate | VERITAS, per real person who passed | Sponsoring junk wallets → reimbursement cut |
| **2 · Gate** | Attests that a wallet corresponds to **one** real human. The task is **attestation**, not a specific method — one era's method is one thing, the next era's is another | Attestation fees and VERITAS | Careless issuance → stake lost, removed from the directory, by Citizen vote |
| **3 · Juror** | **Judges** public disputes using chain data. Chosen **at random** from verified people, **not standing** — exactly matching "no closed council judges anyone" | VERITAS, per case | Repeatedly overturned on appeal → out of the selection pool |
The Gate is the most powerful role in the system, because it decides **who counts as a human being**. It therefore carries its own constraints, described under the two laws below.
### LIBERTAS — keep it un-switch-off-able
| Role | Task | Paid from | Loses the role when |
|---|---|---|---|
| **4 · Signer** | Produces and signs blocks | LIBERTAS | Slashed, jailed, or withdraws its own stake |
| **5 · Witness** | **Keep · serve · detect.** Stores the full history, **opens it for others to read**, and reports dishonesty. *Keeping a record nobody can read is not witnessing* | LIBERTAS | Deliberate false report → stake lost · **stops serving data → the role lapses by itself** |
| **6 · Connector** | **Bridges value and identity across the boundary between networks.** One era's technology is a method, not a definition | LIBERTAS, per packet | Stops relaying → the role lapses, no punishment needed |
The Witness fills a gap few notice: the infrastructure for **reading** the chain — public query endpoints, explorers, indexers — is, if held by one party, a point of centralisation equal to block signing, and until now no role has owned it.
### AETERNUM — build and steer the future
| Role | Task | Paid from | Loses the role when |
|---|---|---|---|
| **7 · Builder** | Contracts, applications, tools — **and documentation, translation, teaching**. Paid **retroactively for work done**, never in advance | AETERNUM | Not funded further, as Citizens decide |
| **8 · Chain holder** | **Brings their own world in, and anchors identity back to the shared ledger.** A "private chain" is one era's form; another form later is still the same role | **DOES NOT RECEIVE — PAYS IN** | Stops paying anchoring fees → identity stops being anchored |
| **9 · Citizen** | **Read · propose · debate · vote** | **The ballot: never paid.** Drafting and analysis work: yes, from AETERNUM, with recipients public | **Only when Tier A human standing is revoked** — nobody loses the vote for voting "wrongly" |
The seventh role is where the principle *the initiator gets no special share* meets reality. The team receives from AETERNUM **as builders, competing in the open**, not as owners. Writing that down is the only way to make "no allocation for the team" both true and survivable for ten years.
The ninth role splits its funding source for a historical reason: **unpaid** governance means only those with spare time and means take part — every unpaid parliament **turns aristocratic**. Paying for **drafting work** while never paying for **the ballot** solves both sides: votes cannot be bought, and poor people are not excluded from the table.
### Three properties of the structure
**Seven receive · one pays in · one is unpaid for the ballot.** Seven roles receive from issuance; the Chain holder **pays in**; the Citizen receives nothing for the act of voting. And the Sponsor is the only role that must **spend first** before being paid. This is the answer to *"where does the money come from"* and *"why governance cannot be bought"* — stated as **structure**, not as a promise.
**Reporter and judge are separated.** The Witness detects and presents evidence; the Juror rules. Two roles, two funding sources, **nobody holds both in the same case**. That is the difference between a **court** and a **council**.
**The scaffolding has no role — deliberately.** The temporary functions of the build phase are not among the nine roles, because granting them a role **legitimises them permanently**. The nine roles are a map of the network **once the scaffolding is gone**.
### Two laws that permanence demands
**Law A — no role may decide who enters that role.** A permanent role is a **permanent power structure**. If those holding a role guard its door, the nine roles become **nine guilds** within a generation — nobody intends it, it simply grows. No signer approves new signers; no gate approves new gates; no juror selects jurors. Entry is by **public rule** or by **a vote of the whole**.
That law must cover Tier A too, and this is the most notable missing piece: **being refused by a gate is also a dispute**, so the right of appeal must apply to **the refusal itself**. Without that piece, the sentence *"no closed council judges anyone"* cannot save a person **quietly refused by every gate**.
**Law B — the nine names are permanent, definitions may widen, and there is never a tenth role.** New tasks appearing later must **find a home within one of the nine**. Two valves come with it, and without them the law breaks itself: every widening of a definition must **be recorded and the previous version hash-anchored** — because across centuries, nine vague definitions are nine places for power to hide; and an **honesty valve**: if a task genuinely has no home among the nine, that is evidence the nine are wrong, and the right response is **to say so publicly**, not to cram it in.
### What is engraved, what is voted
Permanent but immovable is wrong within ten years. Voteable in every respect is not permanent at all.
| Engraved — permanent | Voted — living |
|---|---|
| The nine **names** | Each role's **need ceiling** |
| The **task**, stated as function rather than technology | **Stake levels** |
| The rule mapping roles to parts | The specific **measurements** |
| The seven–one–one structure | **Which technology** implements it |
| The two laws above | Each role's **funding status** |
| The law that every role must have **an exit** | Who holds a role |
> **Engrave *what* and *why*. Vote on *how much* and *by what means*.**
And this is what makes the promise "pay for tasks" work: each role has a ceiling based on real need; a day's flow exceeding one role's ceiling returns to the endowment rather than spilling into another role; ceilings can change, but the three parts stay exactly equal in total. **Equality lives in the parts, flexibility lives in the ceilings within a part.**
### Three places deliberately without a role
Where the set of nine is **absent** also falls out of the text, and that is the best shield against the attack *"nine to round out the number"*.
| The empty place | Why deliberately |
|---|---|
| **The endowment valve** | A published principle: *"no hand turns the valve"* — not in the engraved text, and changeable **only by public vote**. Placing a role there contradicts exactly that |
| **Price** | A published principle: *no selling, no listing, no price support* — a verifiable fact of every period run so far, not an engraved line. A "market maker" role contradicts it |
| **The Resonance pillar** | Resonance is not something anyone **does** — it is what **happens** when the other eight run correctly. Naming a result is precisely the padding Law B forbids |
### Who is "the community" in "a community vote"?
This is the most candid section here, and the reason the nine roles **have not been put to ratification**.
Voting power in this system comes from staked capital. In the early phase, nearly all staked capital belongs to nodes provisioned by one party. Putting the foundation of the issuance mechanism to a vote in that state produces **something called community-approved that was ratified by one signature**.
That is worse than not voting at all — because it **borrows legitimacy without having it**, and what is borrowed stays in the opening record of the shared ledger.
So the project sets itself a condition: **distributing voting power out of the project's hands — to the point where the project loses its veto — must come BEFORE the vote ratifying the nine roles.** Not for procedure's sake, but because **a set of roles weighs exactly as much as the legitimacy of the ballot that ratified it**.
| # | Stage | Condition to pass |
|---|---|---|
| 1 | Draft | The proposal is settled |
| 2 | Resolve the three open questions | Have answers, **or state explicitly that they stay open** |
| 3 | **Publish early as a proposal** | Enough time to receive real criticism ← *this page is here* |
| 4 | **Distribute voting power** | Voting power outside the project's hands exceeds the veto threshold |
| 5 | Ratify by vote | With a real quorum, not one signature |
| 6 | Into the genesis of **mainnet** | It becomes the opening record of the shared ledger — the three preceding testnets engrave nothing, and under the constitution a later community can still change it by vote |
**Step 4 is the only one that cannot be shortened.** The other three go as fast or slow as we do.
### Three questions left open, and one with no answer
Three questions await answers: the **source of randomness** for selecting jurors (get it wrong and "jurors" become "a council") · a complete **delegation scheme** · and how many shares **a person verified at several gates** counts as.
And one question with no answer, heavier than all three: **people die.**
The proposed distribution promises that a real person in 2050 still has a share. But the proportion of the deceased in the set of wallets **only rises, forever**. Do gates revoke attestation when a person dies? Does a dead person's share stop, return to the endowment, or pass to an heir? And **a dead person's still-valid delegations — who switches them off?** Especially an agent that keeps signing on behalf of someone who no longer exists.
This is an **ethical and economic** question with no correct technical answer. A permanent set of roles that does not handle death is **guaranteed to break** — not "may", but certainly; only the timing is open.
> **In short:** a permanent set of roles should be read closely **before** it becomes permanent. That is why it is here, labelled a proposal, together with the full list of what it still cannot answer.
## Operations and governance
A system correct on paper still fails if it is run on impulse. This page covers two things that belong together: **operational discipline** — what must be green before anything is called done — and **governance** — who decides what, who holds the keys, and how the promise to withdraw is measured.
### Operational discipline
#### The standard acceptance test
The five steps below are what proves the platform works. They can be re-run and give the same result.
```mermaid
sequenceDiagram
participant CO as Compliance officer
participant AD as Administrator
participant A as Wallet A
participant B as Wallet B
participant X as UNAPPROVED wallet
participant AU as Auditor
CO->>A: Add to the permitted list
CO->>B: Add to the permitted list
AD->>A: Deploy a token and issue
A->>B: Transfer, no fee charged
A--xX: Transfer to an unapproved wallet, REJECTED
AU->>AU: Export the log
Note over AU: Contains both successful transactions
and the blocked attempt
```
*Figure 11 — The blocked step must appear in the log too, otherwise the blocking is invisible.*
The interoperability acceptance test adds three more steps: open a channel to a manually approved counterparty; send assets to an approved address and receive them; send to an unapproved address and watch the funds return to source rather than get stuck.
#### Four gates before anything is called done
| Gate | Content |
|---|---|
| 1 | Actually runs, verified end to end |
| 2 | Tests pass and the build is clean |
| 3 | Touching a live system requires a real person's approval |
| 4 | The status document is updated |
#### Two disciplines
**Rehearse first, never perform live on the first take.** The path to a network's birth is rehearsed on the real infrastructure: torn down and rebuilt from scratch, repeatedly, each time running the full set of gates. On the real day, the script has been run smoothly rather than improvised at midnight.
**A red gate moves the date; nothing is hot-patched.** If any gate is red: stop, preserve the scene, move the date to the 9th of the following month, and publish the reason. A date that can be moved publicly is a date that means something. A date that must be held at all costs is a date that invites hot-patching, and a hot-patched genesis cannot be undone.
> **In short:** "it works" is not a feeling, it is **a list of steps that can be re-run and give the same result**.
### Governance and who holds the keys
| Level | Who decides | By what means |
|---|---|---|
| Customer chain | Customer and platform, per contract | On-chain roles and the service agreement |
| Platform parameters | On-chain governance | Proposal and vote |
| LOVE9 economics | The community | Public on-chain vote |
#### The direction of a change decides the authority
This detail blocks a common kind of overreach. For protective parameters, what decides who may change them is not their importance but the **direction** of the change.
| Kind of change | Example | Who may do it |
|---|---|---|
| Weakens the system | Disabling anti-abuse, loosening limits, adding an exempt role | On-chain governance only |
| Strengthens the system | Enabling for the first time, tightening further | An administrator may act immediately |
This split avoids both extremes: forcing every change through a vote leaves the system unable to patch itself in an emergency, while giving administrators full authority means the door opens on a single decision.
#### Who holds the keys
Three separate signing groups, held by **three different sets of people**.
```mermaid
flowchart TB
subgraph G1["Administration group"]
A1["person A"] --- A2["person B"] --- A3["person C"]
end
subgraph G2["Compliance group · DIFFERENT PEOPLE"]
B1["person D"] --- B2["person E"] --- B3["person F"]
end
subgraph G3["Value store · cold · higher threshold"]
C1["several people
holding separately"]
end
G1 --> OP["System administration actions"]
G2 --> CP["Compliance approval actions"]
G3 --> TR["Touching the value store"]
X["One signature
is NEVER enough"] -.-> OP
X -.-> CP
X -.-> TR
```
*Figure 12 — Whoever approves compliance must not be whoever administers the system.*
The invariant principle: one signature is never enough, and those two roles must sit with two different sets of people. If the same person both grants an address its permission and runs the system recording that permission, separation of duties is a formality.
Two things here are easily read as one, and this document separates them. The **mechanism** is enforced: without the signatures a transaction is rejected. But a period's genesis **actually placing the two roles at two different addresses** has not happened yet — in the running period both sit at one address, and you can read that in the genesis file. The **actual key ceremony** — each key share generated on and staying inside a different person's own device, rather than test keys generated in a single build — is **a mandatory gate before the network holds real assets**. A correct mechanism without the ceremony means three groups are still only three addresses.
#### The commitment to remove the scaffolding
The company and organisation behind this are scaffolding. The removal schedule is counted publicly on chain, until the network needs nobody to operate it. This commitment is verifiable because it is measured by something countable: **how many tasks still require an administrative key.**
But the unflattering part must be said in full: until the scaffolding is gone, **the three key groups above are held by people the project appointed, not people the community elected** — and voting power is still concentrated there too. Splitting authority across three groups stops one person deciding alone; it does not make governance the community's. That is exactly why [*Before you read*](/en/before-you-read) makes distributing voting power **a gate that stands before** any ratification of anything permanent.
> **In short:** good governance is not everyone voting on everything, it is **the right decision in the right hands, and anyone being able to check that**.
## 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*](/en/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 |
```mermaid
flowchart LR
subgraph P["What the evidence can say"]
P1["Can be raised
and torn down"]
P2["Consensus threshold
matches theory"]
P3["Separation of key custody
is enforced"]
P4["Disaster recovery
works"]
end
subgraph L["What the evidence CANNOT say"]
L1["Does not replace
an independent audit"]
L2["Small scale does not
imply large scale"]
L3["Correct in an experiment
is not months under load"]
end
P --> L
```
*Figure 13 — 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*](/en/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 [*Taking part, and the doors still owed*](/en/taking-part-and-the-doors-still-owed) 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*](/en/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.
## Taking part, and the doors still owed
Nine missions written for nine billion people. The number of people building them can be counted on one hand.
That gap is nothing to be ashamed of — everything starts this way. It is simply **the project's remaining central problem**, and it has no technical solution.
### A small group cannot keep a hundred-year promise
This document admits two things to you side by side. One: everything here was proposed by the founding group. Two: the founding group is only **scaffolding**, and the removal schedule is counted publicly.
Those two can only both be true if a third is: **someone must step into the place the scaffolding is holding up.** A network promising to outlive the people who wrote it must not depend on them. The invitation below is therefore not a courtesy — it is **the condition that keeps the other promise from being empty**.
### Five ways to take part, and each one's door
| Take part by… | What it means concretely | Door | Corresponding role |
|---|---|---|---|
| **Contributing** | Criticism. Find where this document overstates, misstates, or evades | **OPEN** | Citizen — reading and debating |
| **Building** | Contracts, applications, tools — **and documentation, translation, teaching** | **AJAR** — can be submitted through the channels; fully open when **the public code repository is settled** | Builder |
| **Accompanying** | Running an independent node, or an audit node, on your own infrastructure | **NOT OPEN** — awaiting participation artefacts | Signer · Witness |
| **Governing** | Proposing, debating, voting on everything labelled PROPOSED | **NOT OPEN** — awaiting distribution of voting power | Citizen — proposing and voting |
| **Owning** | One real human, one share, one vote | **LEFT BLANK** — how shares are received has not been designed | Tier A: Human |
Read that table down the "Door" column and one thing is immediately visible: **the deepest way to take part is the most tightly shut.** That is the uncomfortable truth of this phase, and hiding it would turn the invitation into an advertisement.
### Four things you can do now, without anyone's permission
**1 · Find what is wrong in this document.** It lists its own weak points in [*Open questions and concerns*](/en/open-questions-and-concerns). If you find one that is not on those lists, that is the most valuable gift a stranger can give this project.
**2 · Check the network yourself.** [*Check the network yourself*](/en/check-the-network-yourself) reads straight from public endpoints, through no number the project declares. The three questions there can be asked of any network, not only this one.
**3 · Check the document yourself.** The text is hashed and anchored to Bitcoin; the *Verify this document* page gives you the artefacts to reconcile with independent tools.
**4 · Demand the three missing doors.** They are listed below with **the gate each must pass** — so you can ask about the right thing instead of asking in general.
Two addresses, one purpose — **feedback, criticism, and security reports**:
[contact@9chain.org](mailto:contact@9chain.org) · [t.me/LOVE_9Chain](https://t.me/LOVE_9Chain)
### Three doors the founding group still owes
| Door still owed | The gate it must pass | Who walks in when it opens |
|---|---|---|
| **Participation artefacts** — genesis file, peer addresses, node image, configuration bundle | **Ajar.** The genesis file and peer addresses can now be read straight from public endpoints, and the project's technical site has a guide to running a full node — *no keys, no tokens, no permission from anyone*. What is missing is **the configuration bundle and node image**: the guide's first command points into a directory inside the unopened code repository ⇒ **this door is locked to the one below it** | Validator operators · customer-side operations teams · audit nodes |
| **Public code repository and a contribution path** | Settle the decision to open the code — contribution and open code go together; opening one without the other is meaningless | Builders — code, documentation, translation |
| **Real voting power, outside the project's hands** | Distribute stake to the point where the project loses its veto | Citizens — and only then does ratification carry legitimacy |
These three doors are not on the ENGRAVED list. They are work to be done, and their progress is measurable from outside using the four-level ladder — no one's word required.
And one thing becomes clear on comparing this table with what the project has published: **the first two doors are really one.** However open a node guide is, it is no more open than the repository holding what it tells you to copy. While the code repository stays closed, the sentence *"one machine, one command"* is true for insiders and not yet true for outsiders — and outsiders are who that door was built for. The honest measure of the first door is therefore not *"have the artefacts been published"* but **"can a stranger, with only what is public, actually raise a node"**.
```mermaid
flowchart TB
R["You · the reader"] --> D1["OPEN
read · criticise · verify"]
D1 --> G1{"Gate: participation artefacts"}
G1 --> D2["Accompany
run an independent node"]
D1 --> G2{"Gate: public code repository"}
G2 --> D3["Build
code · docs · translation"]
D2 --> G3{"Gate: voting power leaves
the project's hands"}
D3 --> G3
G3 --> D4["Govern
propose · vote"]
D4 --> O["Own together
one human · one share · one vote"]
```
*Figure 14 — Four rings of participation and the three gates between them. The innermost is open; the other three are what the founding group owes.*
### What someone arriving later can still change
Finally, the sentence most worth saying on this page: **the right to change the design has no deadline.** Under the constitution, everything but the three memorial blocks belongs to the community's vote, for as long as the network lives. What has a deadline is **the price of changing it**: from now until the genesis of mainnet — through Testnet 1, 2 and 3 — everything labelled PROPOSED and LEFT BLANK can be edited on the drafting table: total supply, the release rhythm, the nine roles, how a human receives their share. After genesis it can still be changed — but it must win a vote on a living network, and **the record can no longer be changed**: what genesis did stays permanently in the ledger, and "permanently" in an infrastructure meant to live for centuries means **longer than everyone reading this sentence**.
So if you intend to say something about this project, the moment when saying it is **cheapest and carries most weight** is **now**, while it is still words.
> **In short:** nine missions cannot be held by nine people. What this document invites you to is not a product to use, but **a ledger to write together** — and an invitation is only as true as the number of doors already open, so we list the closed ones too, with the name of who must open them: **ourselves**.
## The 9Chain platform
This is the technical part of the document: **how the system is built, and why this way rather than another.** The six pages inside run from rules down to detail, and wherever you stop, you still hold everything above that point.
| Page | Answers which question | Read it when you want to |
|---|---|---|
| [*Seven principles*](/en/seven-principles) | What governs every technical choice? | Understand the rules before the detail — including what the project **refuses to do** |
| [*Architecture*](/en/architecture) | What tiers make up the system? | See the same system at three increasing resolutions |
| [*Many chains, one identity*](/en/many-chains-one-identity) | If everyone has their own chain, what connects them? | Read the core claim — and what the project still has to prove |
| [*Compliance at the protocol layer*](/en/compliance-at-the-protocol-layer) | Where are the rules enforced, and what does each layer see? | Assess what makes this different from an ordinary chain |
| [*Security and fault tolerance*](/en/security-and-fault-tolerance) | How many failures does it survive, and who pays for security? | Examine the part with countable thresholds — and one question with no answer |
| [*The chain-producing machine*](/en/the-chain-producing-machine) | How does a chain come into being? | Understand why "running a blockchain" stops being an infrastructure project |
```mermaid
flowchart TB
P["Seven principles
rules governing every choice"] --> A["Architecture
four tiers"]
A --> I["Many chains,
one identity"]
A --> C["Compliance
inside consensus"]
A --> S["Security and
fault tolerance"]
A --> M["The chain-producing
machine"]
```
*Figure 15 — Principles above, architecture in the middle, four faces of detail below.*
**One thing to know before reading on.** This part describes **design and mechanism**, not operating scale — that is the rule of the whole document, and it applies here too. You will find no block height, no machine count, no network identity on any page inside; for those, read [*Check the network yourself*](/en/check-the-network-yourself), where the numbers are read straight from the network rather than taken from this page.
**And one easy confusion, stated up front.** The name *9Chain* covers three things: the **shared network** (a Layer 1 blockchain with the native token LOVE9), the **platform** that produces chains for customers (not a chain — it is what produces chains), and **each chain produced** (a private blockchain again). The full comparison is in [*Context*](/en/context); this part talks about all three, so when you meet the word "chain", ask which one it means.
> **In short:** the technical part of an infrastructure project is worth reading not because it lists many components, but because it says clearly **what enforces what** — and calls the places where nothing enforces anything by their right name: a gate.
## Seven principles
Seven principles govern every technical choice behind this.
| # | Principle | Meaning |
|---|---|---|
| 1 | Compliance at the protocol layer | Control sits beneath the application layer, so contracts cannot route around it |
| 2 | Private by default, interoperable by intent | Private inside; only what is chosen goes out |
| 3 | Security from identity, not from token price | Validators are known parties, bound by contract, paid in real money |
| 4 | No single party runs everything | By default there is always at least one node outside the operating team |
| 5 | One main path, done properly | Automate exactly one path, and it must work with real customers |
| 6 | Measurable on chain, or non-existent | Published numbers are read from the chain; no dashboard is the source of truth |
| 7 | Inherited genesis | The network is designed to pass through several periods (three testnets, then mainnet); **contribution history from earlier periods is preserved** and attached to the shared ledger, but **no period promises a one-for-one balance** |
The seventh principle is one few projects dare to write down, so it needs stating plainly. A network can be rebuilt: to change base parameters, to fix a mistake that cannot be hot-patched, or to move into the next period. The project chooses to announce that in advance rather than let it happen and explain afterwards.
The direct consequence for this document: **the network's identity is a live fact, not a constant.** That is why you will find no chain identity hard-coded here. Every page points to where the current identity can be read.
### What the core refuses to do
A platform is defined as much by what it refuses to do as by its feature list.
```mermaid
flowchart LR
Y["A request arrives"] --> Q{"Several parties who do not fully trust each other?
Interoperability needed?
Auditable immutability needed?"}
Q -- "Missing one of the three" --> DB["The right answer is
a database.
9Chain REFUSES"]
Q -- "All three" --> OK["Accept"]
OK --> N1["Refuses token-economic security
for private customers"]
OK --> N2["Refuses to issue assets
on a customer's behalf"]
OK --> N3["Refuses to let one party hold
more than a third of voting power"]
OK --> N4["Refuses to touch the price"]
```
*Figure 16 — The screening gate stands in front of every sales pitch, and the four things the core refuses.*
**Refuses to accept the wrong problem.** If your problem is one party's internal data, the right answer is a database, and saying so plainly is cheaper for both sides. The three conditions above are a screening test written as a rule, not as advice.
**Refuses token-economic security for private customers.** The shared-security model means outside validators can see the data. It destroys the very thing customers pay for.
**Refuses to issue assets on a customer's behalf.** The platform runs chains. Issuers issue their own tokens, and carry their own licences.
**Refuses to let one party hold more than a third of voting power.** This is not a decentralisation slogan but a mathematical threshold, explained under *Security and fault tolerance* below. And to be straight about it: this is something **the project itself has not passed** — as long as the nodes are raised and keyed by one party, the threshold is a rule set for ourselves, not a state achieved. It sits on the open list in [*Open questions and concerns*](/en/open-questions-and-concerns), exactly where it belongs.
**Refuses to touch the price.** For LOVE9: no selling, no listing, no price support, no promise of returns.
> **In short:** a customer cannot protect themselves from a platform that accepts everything. **The refusal list is what protects them.**
## Architecture
The same system, described three times at increasing resolution. Stop after the first pass and you still have the rules.
### Pass one — four tiers
The four tiers below are **deliberately unnumbered**, because numbers get misread as the industry's Layer 0/1/2 scale — two entirely different schemes. Where 9Chain stands on that scale is covered in [*Context*](/en/context).
| Tier | What it is | Technology |
|---|---|---|
| Chain base | The blockchain framework | Cosmos SDK, Cosmos EVM, CometBFT |
| Chains produced | What the customer receives | A private EVM appchain with a compliance gate, charging users nothing, connected for interoperability |
| The chain-producing machine | What raises them | A Kubernetes operator, provisioning API, console, key store, explorer, relayer |
| **The shared network — 9Chain** | **The public blockchain where identity · governance · value live in common for every chain** | native token LOVE9, kept entirely separate from customer chains' fuel |
The last tier is the one most easily forgotten when people describe a chain-producing machine — and drop it, and what remains is merely an infrastructure service. **Multi-chain without a shared network is just many islands.** The part immediately below explains why.
The boundary between the **shared network** tier and the other three is a design decision, not an accident of arrangement: **the shared network's token is never a condition for a customer chain to function.** Customers pay in real money, and their chain runs regardless of what the token is worth, including when it is worth nothing.
### Pass two — the life of a chain
A chain is a declaration. The operator reads that declaration and keeps returning the system to the state described, over and over.
```mermaid
flowchart TB
M["Chain declaration"] --> P["Pending
create the private space"]
P --> G["Raise
generate keys into the key store
assemble genesis, then verify"]
G --> D["Deploy
validators · RPC · faucet · explorer"]
D --> S["Sync
wait for quorum to produce blocks"]
S --> H["Healthy
re-checked on a cycle"]
D -.-> F["Failed
diagnose, then retry with backoff"]
S -.-> F
F -.-> P
H --> T["Teardown
clean up resources"]
```
*Figure 17 — A self-levelling loop. Every pass gives the same result however many times it runs, so restarting the operator is always safe.*
The hardest step is assembling genesis: generating each validator's key into the key store, creating accounts, placing validators directly into genesis, setting base parameters, then **verifying before writing**. A wrong genesis cannot be patched; it can only be fixed by rebuilding the whole network.
### Pass three — many customers on the same infrastructure
```mermaid
flowchart LR
subgraph NT["Private space of chain A"]
A1["Validators run by
the platform"]
A2["RPC · faucet
explorer"]
end
subgraph NB["Private space of chain B"]
B1["Validators run by
the platform"]
end
Q["Resource quotas
network policy
least privilege"] --- NT
Q --- NB
X["CUSTOMER node
running outside"] -.->|"genesis · peer list · keys
generated by the operator"| A1
Y["AUDIT node
running outside"] -.-> A1
```
*Figure 18 — The responsibility boundary: the operator manages only the platform's nodes.*
Customer and audit nodes run outside, on their own infrastructure; the operator only produces the artefacts they need to join. That is what makes "multi-party" real rather than decorative — if every node is run by one party, the phrase means nothing.
> **In short:** once the life of a chain is written as code, **"running a blockchain" stops being an infrastructure project.** It becomes a line of configuration that can be put through review.
## Many chains, one identity
This is the page that answers the question every multi-chain architecture has to answer, and most avoid: **if everyone has their own chain, what do those chains have to do with each other?**
The poor answer is "bridge them". A bridge can move assets, but it cannot move the far more expensive thing: **who you are**. In a world of many chains, the scarce thing is not one more chain — chains can be produced in bulk. The scarce thing is **an identity that many chains recognise**, so that a person does not have to rebuild themselves at every door.
That is why the shared network exists, and it carries exactly three jobs no private chain can do for itself:
| What the shared network carries | Why not leave it to each chain |
|---|---|
| **Shared identity** — one human, one identity, recognised by many chains | If every chain issues its own identity, one person becomes many people, and "one person, one share" loses its meaning |
| **Governance** — common rules and a place to settle disputes between parties | Inside a chain, the strongest party in it is the court; between chains there is no court at all |
| **Value** — a common unit to pay for keeping the network alive | If value lives inside each chain, each must fund its own security — which small chains cannot afford |
```mermaid
flowchart TB
M["SHARED NETWORK · 9Chain
identity · governance · value"]
C1["An organisation's chain"] -->|"anchors identity"| M
C2["A community's chain"] -->|"anchors identity"| M
C3["A person's chain"] -->|"anchors identity"| M
M -.->|"one identity
recognised by many chains"| C1
M -.-> C2
M -.-> C3
C1 <-->|"assets pass a gate"| C2
```
*Figure 19 — Chains stay private, identity is shared. Remove the identity-anchoring arrows and what remains is islands with bridges.*
Assets moving between chains still pass the gate at the border — the mechanism is under *Compliance at the protocol layer* below. The difference is that a bridge moves **assets**, while the shared network holds **identity**, and only the second turns many chains into one world instead of a heap of islands.
> ⚠️ **Label: PROPOSED, and the hardest part is still ahead.** The compliance gate inside consensus is **running**; a **published shared identity scheme** is not — it sits on the open list in [*Open questions and concerns*](/en/open-questions-and-concerns). Put another way: the "many chains" half exists; the "one identity" half is what the project still has to prove.
> **In short:** multi-chain is not an achievement — producing many chains is easy. The achievement is **many chains that still recognise the same human being**.
## Compliance at the protocol layer
The compliance module holds three kinds of data: the list of permitted addresses with their status and the **hash** of a KYC reference, the roles, and operating parameters. One point deserves emphasis: only hashes are on chain. **Personally identifying data is never written there.**
### Five enforcement layers
| Layer | Mechanism | What it blocks |
|---|---|---|
| 1 | A block at transaction pre-processing | Who may sign and submit transactions, on both the Cosmos and EVM sides |
| 2 | Restrictions in the treasury module | Asset flows; the fuel token is non-transferable |
| 3 | A hook into the EVM | Contract deployment rights, and child-contract creation patterns — exactly as far as this layer can see |
| 4 | Interchain middleware | Assets arriving from outside: if the recipient is not approved, an error is returned and funds are refunded |
| 5 | A precompile | Lets a contract itself ask "is this address permitted?" |
```mermaid
flowchart TB
TX["Transaction arrives"] --> L1{"Layer 1 · is the signer
permitted?"}
L1 -- "no" --> R1["Reject · emit event"]
L1 -- "yes" --> L2{"Layer 2 · is the asset
flow valid?"}
L2 -- "no" --> R2["Reject · emit event"]
L2 -- "yes" --> L3{"Layer 3 · permitted to
deploy contracts?"}
L3 -- "no" --> R3["Reject · emit event"]
L3 -- "yes" --> EX["Execute"]
EX --> L5["Layer 5 · the contract asks
before passing on"]
```
*Figure 20 — Each layer has its own rejection branch, and every rejection leaves a trace.*
Why five layers rather than one? Because layer one has a known blind spot, and this document states it rather than hiding it: **pre-processing cannot see contract-to-contract calls inside the virtual machine.** An already-permitted contract can call another one without layer one ever knowing. Layer five exists precisely because of that blind spot. Saying "it cannot be bypassed" without saying this sentence would be false advertising.
From which comes a reading rule for the whole table, more durable than any table: **each layer blocks exactly what it can see.** Where one layer does not look, another must cover; where no layer covers, it must be listed rather than left silently blank. So the right measure of an enforcement system is not **counting layers** but **asking what each layer sees** — and five layers blind in the same place are still only as strong as one.
### Assets arriving from outside
```mermaid
sequenceDiagram
participant N as Public network
participant R as Relayer
participant M as Compliance middleware
participant C as Customer chain
N->>R: Asset transfer packet
R->>M: Deliver packet
M->>M: Is the recipient permitted?
alt Permitted
M->>C: Credit the recipient
C-->>N: Success acknowledgement
else Not approved
M-->>N: Error returned, assets refunded to source
Note over M,N: Nothing is credited. Funds do not get stuck.
end
```
*Figure 21 — The gate at the border: on refusal it refunds, never leaving assets stranded.*
The status of this diagram must be stated correctly: it describes **a gate that has been built and tested**, not a route already carrying assets — **opening the first interoperability channel is still a gate not yet passed**. And a border gate is only as trustworthy as the weakest link in the chain that reads the packet, so the project's rule is to fail **closed**: if a packet cannot be read, block it, and never hand it down to a lower layer to handle. A gate that only blocks what it understands is a gate open to everything it does not.
Every change emits an event, and an external indexer gathers them into reports for auditors. There is a detail here that has already cost us something and is worth keeping: when the middleware **rejects** a packet, the layer below reverts the context and re-emits the event **with a different prefix**. The indexer must match the prefixed form as well, or it will undercount exactly the packets that were blocked — that is, be blind precisely where it most needs to see.
> **In short:** compliance is only trustworthy when it **does not depend on the goodwill of whoever wrote the contract**.
## Security and fault tolerance
Validators are run by parties whose identities are known, bound by legal contract, and paid under service agreements in real money. As a result the network needs no inflation, and a customer chain's fuel token needs no market value at all.
This is a fundamental cost difference, not an optimisation at the margin. The competing model must **sustain an asset's price** to maintain security; somebody ends up paying that cost.
### Who pays for security — and one question this document cannot answer
The sentence above is about **a customer chain's validators**, and there it holds: the customer pays real money under a service agreement, so that chain runs whether or not LOVE9 is worth anything. But **the signers of the shared 9Chain network** are not covered by it — [*Nine roles*](/en/nine-roles) places them under the **LIBERTAS** part of the daily release, meaning they are paid in LOVE9 itself. Two different models, and this document used to let them blur together.
All three mismatches, stated in full, because a careful reader will find them whether or not we say so:
| Mismatch | One side says | The other says |
|---|---|---|
| **Who pays the signers** | This page: paid in **real money**, so the network needs no inflation | [*Nine roles*](/en/nine-roles): signers are paid from **LIBERTAS**, that is, in LOVE9 |
| **Whose stake** | Glossary: self-bond is capital the signer **puts up themselves**, what they lose if they misbehave | [*LOVE9 economics*](/en/love9-economics): the founding validators' stake is **advanced from operating capital** |
| **What a vote counts** | [*Nine roles*](/en/nine-roles): voting power comes from **staked capital** | [*Taking part, and the doors still owed*](/en/taking-part-and-the-doors-still-owed): **one human, one share, one vote** |
Which is design and which is destination must be said plainly. The two ways of counting votes belong to **two different tiers**: technical governance of the chain counts staked capital, because that is what bears the technical consequence; governance of rules and shares aims at one-person-one-vote, and **it cannot run yet** because the tier that counts people is unfinished. Until it is, every vote on this network is a vote **by staked capital**, including votes carrying the community's name. As for the founding period's stake: because the project advanced it, it demonstrates **operating commitment**, not **personal capital at risk** — two different things, and only the second deters.
The hardest question is left here because it **has no answer yet**: in the interval — when the endowment cannot open because the receiving mechanism is LEFT BLANK, while the scaffolding has begun coming down — the source that pays the shared network's signers is a **gate not yet passed**. This is not an operational detail: it is the condition that keeps the promise *"nobody can switch it off"* from being empty. A network secured by token price weakens when the price falls; a network secured by salary **stops entirely** when whoever pays the salary runs out — and this project promises to remove that payer. Anyone who can answer this should write to the two addresses in [*Taking part, and the doors still owed*](/en/taking-part-and-the-doors-still-owed); it is the most valuable contribution available.
### Three operating modes, one codebase
| Mode | Who runs validators | Suits |
|---|---|---|
| Fully platform-run | The platform runs all of them | Simple customers, low budget |
| Mixed (default) | Platform majority, customer one node, auditor one node | Finance, consortia |
| Multi-party | Several institutions run them together | Multi-member consortia |
```mermaid
flowchart LR
CB["One codebase
differing by exactly one field
in the declaration"] --> M1["Fully platform-run"]
CB --> M2["Mixed · default
always an outside node"]
CB --> M3["Multi-party"]
```
*Figure 22 — Three modes differing in configuration, not in code.*
### The law of fault tolerance
Consensus needs **more than two thirds** of total voting power to finalise a block. With power divided equally, a network of `n` nodes tolerates `f` sudden failures according to `n ≥ 3f+1`. This is a mathematical constraint; no configuration lowers it.
| Nodes | Tolerates | Note |
|---|---|---|
| 3 | 0 | losing any node stops it |
| 4 | 1 | the minimum meaningful threshold |
| 5–6 | 1 | a sixth node adds no fault tolerance |
| 7 | 2 | the recommended threshold for a network carrying real assets |
| 10 | 3 | survives a whole region or provider failing |
### Three things easily misread
**Counting validators is not counting fault tolerance.** What decides it is the number of **independent failure domains**, because what dies is the machine, not the process. Nine validators on one cluster tolerate exactly one machine: lose it and the network stops, even though the validator list is still nine lines long.
The threshold for spreading machines follows from the halting rule itself, not from a feeling of safety. A network halts when a third of voting power disappears at once, so no machine may hold a third or more of the validators — with nine validators that means at most two per machine, that is **at least five machines**, and those five must fail for different reasons before they deserve to be called five domains. That number is an arithmetic consequence of the consensus threshold: the only way to lower it is to change the halting rule.
From which comes a way to read every piece of news about decentralisation: **one machine leaving the cluster is not yet decentralisation.** That step is real and necessary, but the measurement does not move while one machine still holds more than the halting threshold — before that point, losing exactly one machine still loses the whole network. That is why this document writes decentralisation as a gate with a countable threshold rather than a process to be narrated step by step: a step narrated sounds like a result, while the result has only one place to be read — ask the network how many machines its voting power sits on.
**Consensus would rather halt than split.** Past the threshold, the chain stops entirely instead of forking into two branches each claiming to be real. That is the safe choice, not a defect. The duty that comes with it is fast recovery: a time objective, a procedure, and rehearsals.
**Cheap capital requirements make a chain cheap to capture.** If the self-bond threshold is low, the network's total stake is small too, and a modest sum buys two thirds of voting power. That is why the threshold is set high. But its status must be stated correctly: **the text engraved at genesis says plainly that the chain does not yet enforce that floor in consensus** — it is a proposed figure and an operating discipline, not a protection already in place. Enforcing it is **a gate not yet passed**, and you can check that by reading the genesis file itself.
> **In short:** a network is only trustworthy when you know **exactly how many failures it survives** — and that number is usually smaller than the validator count you can see.
## The chain-producing machine
Three parts, one path.
```mermaid
sequenceDiagram
participant U as User
participant AI as AI layer
participant CS as Console
participant OP as Operator
U->>AI: One sentence describing the idea
AI-->>U: A blueprint, with reasons and WARNINGS
Note over U: A human approves, with grounds to refuse
U->>CS: Approve, then create
CS->>OP: Declaration
OP-->>U: Chain running
Note over U,CS: With the AI absent, the manual form still works
```
*Figure 23 — 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.
## Build on 9Chain
This page is for people who write software: you want to deploy a contract, call into the network, or build a product on top of it.
The honest answer has to lead with the unglamorous half: **the network has standard interfaces and can serve requests, but the path to contributing to the source itself is not open**. Those two are different things, and blending them is the easiest way for an infrastructure project to overstate itself.
| What you want to do | Status | Where it lives |
|---|---|---|
| Call the network through the standard EVM-ecosystem interface | **RUNNING** — verifiable from outside | The project's technical documentation, *Connect to the network* |
| Deploy a contract on a test period | **RUNNING** | Technical documentation, *Quickstart* |
| See the public addresses to point tools at | **RUNNING** | [*Network and endpoints*](/en/network-and-endpoints) in this documentation |
| Read the compliance rules a transaction must pass | **RUNNING** | Technical documentation, *Protocol compliance*; the principle is in [*The 9Chain platform*](/en/the-9chain-platform) |
| Declare a new chain from a description | **PROPOSED** — the mechanism exists, the door for outsiders does not | [*The 9Chain platform*](/en/the-9chain-platform), under *The chain-producing machine* |
| Read and modify the source, submit contributions | **LEFT BLANK** — the code repository is not open | See [*Taking part, and the doors still owed*](/en/taking-part-and-the-doors-still-owed), *Three doors the founding group still owes* |
```mermaid
flowchart TB
D["A software developer"] --> O1{"Door 1: call the network"}
O1 -->|"open"| U1["Standard interface
contracts · queries"]
D --> O2{"Door 2: raise your own node"}
O2 -.->|"ajar"| U2["Guide is public,
configuration bundle missing"]
D --> O3{"Door 3: modify the source"}
O3 -.->|"closed"| U3["Code repository not public"]
```
*Figure 24 — Three doors for a developer, and only one fully open.*
**Why this documentation does not copy the technical guide.** Commands and parameters change with each release; a page that copies them fails silently, and the reader has no way to know they are reading an old version. So this page does exactly one job: say **which door is open, which is locked, and why** — then point to the original kept by the technical team at [9chain.org/docs](https://9chain.org/docs). If the two ever disagree, **the technical version is the correct one**, and this page is wrong and needs fixing.
**A measure you should apply to any project, including this one.** Do not ask *"has documentation been published"* — ask **"can a stranger, with only what is public, actually build this"**. However open a guide is, it is no more open than the repository holding what it tells you to copy.
> **In short:** the network's interface is open to outsiders; **the source is not** — and while that holds, every invitation to "build together" is only half true.
## Where to start
This page is a map, not a guide. It says **which route to take**; the actual steps live in the technical documentation — the reason for that split is in [*Build on 9Chain*](/en/build-on-9chain).
Pick by what you intend to do; do not read the whole table:
| You want to | Take this route | Door |
|---|---|---|
| Look at the network without writing anything | [*Network and endpoints*](/en/network-and-endpoints) → open the explorer | **OPEN** |
| Point a familiar wallet or tool at the network | [9chain.org/docs](https://9chain.org/docs) → *Connect to the network* | **OPEN** |
| Deploy a contract on a test period | [9chain.org/docs](https://9chain.org/docs) → *Quickstart* | **OPEN** |
| Understand the rules your contract must pass | [*Contracts and the compliance gate*](/en/contracts-and-the-compliance-gate) | **OPEN** |
| Know in advance where you will trip | [*Limits and what to expect*](/en/limits-and-what-to-expect) | **OPEN** |
| Hold an independent copy of the ledger | [*Run a node*](/en/run-a-node) | **AJAR** |
| Declare a private chain from a description | [*The 9Chain platform*](/en/the-9chain-platform) → *The chain-producing machine* | **NOT OPEN** |
| Read and modify the source | — | **LEFT BLANK**, see [*Taking part, and the doors still owed*](/en/taking-part-and-the-doors-still-owed) |
```mermaid
flowchart TB
D["A software developer"] --> Q{"What do you need first?"}
Q -->|"to look"| A["Explorer · endpoints"]
Q -->|"to call"| B["Standard interface
familiar wallets and libraries"]
Q -->|"to understand the rules"| C["Compliance gate
five layers"]
Q -->|"independence"| E["A node of your own"]
A --> F["Three questions to ask
before believing a number"]
B --> F
C --> F
E --> F
```
*Figure 25 — Four ways in, one meeting point: check before you trust.*
**One thing to do before anything else**, and it costs exactly one minute: open the read-it-directly panel in [*Check the network yourself*](/en/check-the-network-yourself) to find out **which period the network you are about to point tools at actually is**. Builds for testing carry **exactly the identity** of the official network, so the chain name alone is not enough. Developers routinely skip this step and discover it after deploying.
> **In short:** the most expensive thing you can lose here is not coding time, but **building on a test period while believing it is the official network** — one minute with the self-check panel buys that risk back.
## Contracts and the compliance gate
This page is for people **writing contracts** on a chain produced by the platform. It does not teach syntax; it tells you what syntax cannot: **which rules block your transaction, at which layer, and why the layer you can see is not the only one.**
The fundamental difference from an ordinary public chain: here, most of the rules **are not in your contract**. They sit beneath it, inside the consensus mechanism — the full mechanism is in [*The 9Chain platform*](/en/the-9chain-platform), under *Compliance at the protocol layer*. What that means for whoever writes the code:
| What you do | Which layer sees it | What to expect |
|---|---|---|
| Submit a transaction | Pre-processing (layer 1) | An unapproved wallet is **rejected before the virtual machine runs** — there is nothing for your contract to catch |
| Move assets | Treasury module (layer 2) | The fuel token is **non-transferable**; do not design mechanics that depend on moving it |
| Deploy a contract | EVM hook (layer 3) | Deployment permission is a **role**, not a default. Child-contract creation patterns are inspected too |
| Receive assets from an outside network | Interchain middleware (layer 4) | An unapproved recipient makes the packet **return an error and refund** — funds do not stick, but your flow must survive that branch |
| Ask "is this address permitted?" | Precompile (layer 5) | This is the layer **you can call from inside a contract**, and it is what compensates for layer 1's blind spot |
```mermaid
flowchart LR
H["Your contract"] -->|"asks"| P["Precompile: is this address permitted?"]
P --> Y["Yes -> pass it on"]
P --> N["No -> stop, with a reason"]
H -.->|"does NOT ask"| Z["Calls another contract
that layer 1 cannot see"]
```
*Figure 26 — Layer one's blind spot, and how a contract covers it itself.*
**The blind spot you must know about, because this document does not hide it:** pre-processing **cannot see contract-to-contract calls inside the virtual machine**. An already-permitted contract can call another one without layer 1 ever knowing. Layer 5 exists precisely because of that — so if your contract forwards value to an address supplied by a user, **asking the precompile is your job, not the protocol's**.
The general reading rule, more durable than any table: **each layer blocks exactly what it can see.** Do not count layers and feel safe; ask what each layer sees.
**A customer chain and the shared network are two different places.** Your contract runs on the **customer chain**; the fuel token there has no market price and **is not LOVE9**. The three token layers, and the easiest confusion between them, are in [*LOVE9 economics*](/en/love9-economics).
> **In short:** on this chain, a carefully written contract **is not enough to be compliant**, and a carelessly written one **is not enough to escape compliance** — that is exactly what "compliance at the protocol layer" means.
## Limits and what to expect
Without this page, the *Build* part would be only an invitation. This is where what you will trip over is stated in advance, so you decide before writing rather than after deploying.
| Limit | What it means for you | Label |
|---|---|---|
| The EVM base is pre-stable | This is the project's **largest technical risk**, and it touches your code directly. Pin versions, keep load low, leave an upgrade path | **RUNNING**, with risk |
| The virtual machine executes **sequentially** | Enough for low permissioned load; do not design something needing high throughput and measure only afterwards | **RUNNING** |
| The network is **gasless** | Users pay no fee — but do not read that as "no limits". There are anti-abuse quotas, and the fuel token is **non-transferable** | **RUNNING** |
| No interoperability channel is live yet | The bridge and border gate are built and tested, but **opening the first channel is a gate not yet passed**. Do not build flows depending on assets crossing networks | **Gate not passed** |
| A test period can be **rebuilt** | Balances, addresses, contracts and history of an abandoned build **do not flow into the next one**. Keep your own copy of anything you need | **RUNNING** |
| No independent audit yet | It is a **mandatory gate** of the *Real assets* level — so do not put other people's real value here | **Gate not passed** |
| The repository is closed | You can read the interface, **not the inside**; you cannot rebuild the whole stack yourself | **LEFT BLANK** |
```mermaid
flowchart TB
I["Your idea"] --> Q{"Does it need:
high throughput?
assets crossing networks?
other people's real value?"}
Q -->|"none of the three"| G["You can build on a test period now"]
Q -->|"any of the three"| W["You are waiting on a gate
— the table above names which"]
```
*Figure 27 — Three questions that decide whether you build now or wait.*
**One thing worth stating separately: do not measure performance here and draw conclusions about later.** This document deliberately **promises no performance number** — no throughput, no finality latency. What you measure on a test period is the number of a build made for testing, on this phase's infrastructure; it says nothing about the official network, in either direction.
**And the easier half:** most tooling you already know still works, because the chains produced are EVM appchains. What has to be relearned is not syntax but **the rules underneath** — [*Contracts and the compliance gate*](/en/contracts-and-the-compliance-gate) covers it.
> **In short:** a specific list of limits is what **someone overstating their case does not want to write** — so use it as a test on every piece of infrastructure you consider building on, including this one.
## Network and nodes
This part is for people who would rather **check for themselves** than take our word, and for people who want to **hold a copy of the ledger of their own**.
The three pages inside are ordered by the effort they ask of you: reading a public address takes a minute, running a node takes an afternoon, and checking where the network actually stands is something you should do **every time** before believing any number about this project.
| Page | For | Effort |
|---|---|---|
| *[*Network and endpoints*](/en/network-and-endpoints)* | Anyone pointing tools at the network, or just wanting to look | A minute |
| *[*Run a node*](/en/run-a-node)* | Anyone wanting an independent copy, not dependent on the project's machines | An afternoon, and a machine |
| *[*Check the network yourself*](/en/check-the-network-yourself)* | Anyone about to believe a claim about this network | One read, each time you hear something |
```mermaid
flowchart LR
P["You"] --> R["Read a public address"]
R --> V["Check for yourself: which network,
born when"]
V --> N["Run your own node"]
N --> I["No longer having to trust anyone
about the ledger's contents"]
```
*Figure 28 — Four steps of independence, each removing one place where you must trust someone else.*
**One thing worth saying first.** Reading numbers from an address the project runs still means trusting the project — only at a lower level than trusting a screenshot of a dashboard. Real independence begins at **your own node**: once the ledger sits on your machine, what the project says matters less than what you can read.
> **In short:** each step here removes **one place where you are forced to trust someone else** — and that is the right measure of open infrastructure, not the amount of documentation it publishes.
## Network and endpoints
The project's network serves several public interfaces. This page says **what each one is for** and **what you can check through it** — not so that you can copy numbers away.
| Interface | Used for | What you can verify yourself |
|---|---|---|
| Consensus interface (Cosmos RPC) | Asking node status, the list of signers, the genesis file | When this network was born · who signs blocks · whether it is advancing |
| EVM-compatible interface (JSON-RPC) | Pointing familiar wallets and tools at the network | Calling contracts and reading balances with tools you already trust |
| Query interface (REST) | Reading state per module | The parameters actually in force, rather than the ones in a document |
| Test faucet | Requesting a small amount to experiment with on a test period | That this is test-period money, not an asset |
| Explorer | Looking with your eyes, no tooling required | Blocks, transactions, signers — a view built by another party |
```mermaid
flowchart TB
You["Your tooling"] --> C["Consensus interface
status · signers · genesis"]
You --> E["EVM interface
wallets · contracts"]
You --> Q["Query interface
parameters in force"]
C --> T{"Two answers must agree:
which network does the address claim?
when was the first block born?"}
T --> OK["They agree: read on"]
T -.-> NO["They differ: believe no number"]
```
*Figure 29 — Every way in passes the same two-question check.*
**The naming rule, and why it is worth more than it looks.** The project sets a rule: the public address of a test period **carries the word *testnet*** in its name, the official network will have a name of its own, and **an address that has meant one thing never comes to mean another**. Because of that rule, a link you save keeps its meaning, instead of one day quietly returning another network's data. It is also why [*Check the network yourself*](/en/check-the-network-yourself) makes you ask **two** questions rather than one: *which network does this address say it is* and *when was its first block born* — the two answers must point to the same place, and if they differ, one of the two statements is false.
**Three things this page deliberately does not do.** It does not copy a list of addresses into the body as a permanent truth — the list lives in the project's technical documentation, under *Public endpoints*, and that is the correct version. It does not record any number of the network — live numbers belong in the read-it-directly panel in [*Check the network yourself*](/en/check-the-network-yourself). And it does not promise these endpoints will always be free or always survive any load: this is infrastructure for experimenting, not a service commitment.
**The explorer is a separate project.** It is not run by the same team as the network, and that is a plus rather than a minus: a second party reading the same ledger is the cheapest way to catch a first party telling it wrong.
> **In short:** an endpoint is only trustworthy when **its name says the same thing as the data it returns** — ask both questions before believing any number.
## Run a node
Running a node is the first real step of independence: the ledger sits on your machine, and from then on what the project says matters less than what you can read.
Three kinds of node, not to be confused — each asks for a different level of trust and carries a different risk.
| Kind of node | What it does | Needs | Door status |
|---|---|---|---|
| **Full node** | Holds and serves the ledger, does not sign | One machine, one command, no keys, no tokens, nobody's permission | **AJAR** — the guide is public, the configuration bundle is still inside the unopened repository |
| **Archive node** | Holds the entire history from the first block | As above, plus disk and sync time | **AJAR** — the same door as a full node |
| **Validator** | Signs blocks, is accountable for consensus | A signing key, a stake, and acceptance into the consensus set | **CLOSED** — the project has not invited outsiders into the signing set |
```mermaid
flowchart TB
M["Your machine"] --> S["Sync from a public p2p endpoint"]
S --> A{"The distinguishing check:
can you read the FIRST block?"}
A -->|"yes"| R["A genuine archive copy"]
A -.->|"no"| F["Only a copy taken from midway"]
R --> Q["Answer any question about the ledger
without asking anyone"]
```
*Figure 30 — A one-question test for whether your node holds the whole history or only its tail.*
**The most useful test when raising a node.** A node that syncs quickly is not necessarily a node holding the full history: some sync methods copy only recent state and continue from there. The cheapest way to tell is to **ask it for the first block**: if it can be read, and that block's time matches what the network declares, it is a genuine archive copy. If it cannot, you are holding the tail of the ledger rather than the ledger.
**Why this page does not copy commands.** Commands and parameters change with each release. The original is kept by the technical team at [9chain.org/docs](https://9chain.org/docs), under *Run your own node* — that is the correct version, and if it differs from this page, this page is wrong.
**Where the door is stuck, stated plainly.** The very first command of that guide tells you to copy a configuration directory that lives in a repository that is **not public**. That means the "run a node" door and the "open the code" door are really **one door**: however open a guide is, it is no more open than the repository holding what it tells you to copy. So the honest measure of this door is not *"has a guide been published"* but **"can a stranger, with only what is public, actually raise a node"**.
**A full node does not make the network more decentralised.** It makes **you** more independent — a different thing. The network's fault tolerance is decided by its signing set, and its countable threshold is in [*The 9Chain platform*](/en/the-9chain-platform): no machine may hold a third or more of the signers.
> **In short:** your node cannot save the network, but it **saves you from having to trust the network** — and that is the whole reason open infrastructure must make raising a node boringly easy.
## Check the network yourself
This page stands in place of a table of figures captured at one moment. Such a table decays within weeks; a guide to reading for yourself does not.
The panel below reads **directly** from public endpoints, at the moment you open the page, through no number the project declares.
```9chain-network-status
```
### Warning: a rehearsal carries the real network's name
Because the path to birth is rehearsed on real infrastructure, **rehearsals carry exactly the official network's identity.** Looking at the chain's name is not enough to tell them apart.
The only reliable way to distinguish them is to read **the time of the first block** and compare it with the announced birth moment. If they match, this is the official network. If they differ, this is another build, and its figures are not the real network's figures. The panel above performs exactly that comparison and states the result plainly.
**Until the mainnet birth moment is announced, the panel above says plainly that every network running under this name is a build for testing** — including one carrying exactly the right chain identity. That is a deliberately safe state: it never confers official standing on a network the project has not declared.
**There is a second signal, and it is cheaper than the comparison above: the name of the address you are querying.** The project sets a rule that a test period's public address **carries the word *testnet*** in its name, and the official network will have a name of its own — **an address that has meant one thing never comes to mean another**. That rule is worth more than it looks: it keeps a link you save meaning what it meant, instead of one day quietly returning another network's data. When reading any number about this network, ask both questions — *which network does this address say it is*, and *when was its first block born*. The two answers must point to the same place.
### Which period you are looking at, and which level it is at
Two scales, not to be confused. **Step** (the nine steps, see [*Before you read*](/en/before-you-read)) says where the project stands on its release roadmap — and the four periods Testnet 1 → 2 → 3 → Mainnet sit at steps 4, 5, 6 and 8 of it. **Level** (the four below) says what the system has **proven**.
| | Period | Level |
|---|---|---|
| Answers which question | how far along the roadmap is the project? | what has the system proven? |
| Who decides | the project's roadmap | **evidence**, and you can check it |
| Can it go backwards | no — periods only advance | **yes** — a security finding pushes the level back |
A new period **does not automatically raise the level**. Moving to Testnet 2 without publishing participation artefacts leaves the level exactly where it was — and that is precisely the kind of claim you should examine.
### Three questions to ask any network
| Question | Where to read it | Why it matters |
|---|---|---|
| Is this the official network? | The time of the first block | See the warning above; this is the most important question |
| How many failures does it survive? | The validator list, **and** who runs them where | Counting validators is not enough; count independent failure domains |
| Is it alive? | Block height rising steadily, block rhythm stable | A halted network still answers queries |
### The maturity ladder
This section stands in place of a "not done yet" list. It is written in **criteria**, so it does not decay: what changes over time is only which level the network stands at.
| Level | Meaning | Gates to pass |
|---|---|---|
| 1 — It runs | The chain lives, and can be rebuilt | The standard acceptance test green; genesis through the full set of gates; disaster recovery actually rehearsed |
| 2 — Open to outsiders | Outsiders can use it and run nodes | Participation artefacts published publicly; a node image in a public registry; a community channel and **a security reporting address**; anti-abuse at every public write path |
| 3 — Real self-service | Outsiders raise their own chains | User accounts; every chain must have an owner; isolation and quotas that survive strangers |
| 4 — Real assets | Running with other people's real value | Independent third-party audit, all serious findings fixed and re-audited; jurisdiction and legal entity settled with appropriate licences; consensus keys signed from dedicated hardware; **at least seven independent failure domains**; load and deliberate fault injection over weeks; monitoring and on-call rehearsed |
```mermaid
flowchart LR
N1["1 · It runs"] --> N2["2 · Open to outsiders"]
N2 --> N3["3 · Real self-service"]
N3 --> N4["4 · Real assets"]
N4 -.->|"security finding
network rebuilt
infrastructure changed"| N1
```
*Figure 31 — No skipping, and moving back a level is a real possibility.*
**No skipping.** Each level is a condition of the next. A network at level one presenting itself as level four is lying, even when every individual sentence is true.
**A claimed level must be verifiable from outside.** If you cannot check it yourself, it is not a claim, it is an advertisement.
**Moving back a level is normal.** Rebuilding the network, changing infrastructure, or a security finding can all push it back. Saying so costs credibility once; hiding it costs credibility permanently.
> **In short:** a roadmap measured in **conditions** never goes out of date. A roadmap measured in **dates** is out of date the next day.
## Reference
This part contains no argument. It is a place to **look things up**: the meaning of a word, how to report a vulnerability, short answers to common questions, and the record of one contribution.
| Page | Use it when |
|---|---|
| *[*Glossary*](/en/glossary)* | You meet an unfamiliar word, or suspect you and the writer mean different things by it |
| *[*Security and disclosure*](/en/security-and-disclosure)* | You found a vulnerability, or want to know how far the project has been audited |
| *[*FAQ*](/en/faq)* | You need a short answer, and a link to where it is discussed properly |
| *[*Appendix — The first submission*](/en/appendix-the-first-submission)* | You want to see how one person filled in this document's empty boxes |
```mermaid
flowchart LR
Q["Your question"] --> W{"What shape is it?"}
W -->|"a word"| G["Glossary"]
W -->|"a vulnerability"| S["Security and disclosure"]
W -->|"a query"| F["FAQ"]
W -->|"a submission"| A["Appendix"]
```
*Figure 32 — Four reference doors, chosen by the shape of the question.*
**One convention of the whole document, repeated here because reference pages are the most skimmed:** every claim in this document carries exactly one of four labels — **ENGRAVED**, **RUNNING**, **PROPOSED**, **LEFT BLANK** — defined in [*Before you read*](/en/before-you-read). Anything not marked ENGRAVED can be changed.
> **In short:** a document without a reference section forces readers to read all of it before they can use any of it — and **most readers will not read all of it**.
## Glossary
This glossary explains words **as this document uses them**. Where a word means something else in the wider industry, that is noted — because misreading one word is enough to misread a whole mechanism.
### Network and consensus
| Word | Meaning in this document |
|---|---|
| **Blockchain** | A ledger that can be appended to but not quietly altered, held by many parties at once. This document says **ledger** when speaking of meaning, and **chain** when speaking of the product |
| **Chain** | Kept in established names such as *the chain-producing machine* and *customer chain*. For how *chain* and *ledger* divide, see **Blockchain** above |
| **Consensus** | The rule deciding which block counts as real. Here it is the kind that **would rather halt than split** |
| **The two-thirds threshold** | More than two thirds of voting power is needed to finalise a block. The consequence: losing a third halts the network |
| **Independent failure domain** | A place where, when it dies, everything inside it dies with it — usually a machine, a region, a provider. Counting these gives fault tolerance; counting signers does not |
| **Validator** | A node entitled to sign blocks and accountable for doing so |
| **Self-bond** | The stake a signer puts up from their own assets — what they lose if they misbehave |
| **Full node** | A node that holds and serves the ledger but does not sign blocks |
| **Archive node** | A node holding the complete history from the first block, not only recent state |
| **Genesis** | The birth file: the first state every node must agree on before any block is signed |
| **Re-genesis** | Rebuilding a network from a new birth file. During the test phase this is permitted; the inheritance promise only takes effect from the official network |
| **Test period · testnet** | A run for testing. A rehearsal carries **exactly the identity** of the official network, so telling them apart requires the time of the first block |
| **Mainnet · official network** | Two words for the same thing: the period where everything is engraved for the last time and the record is kept permanently |
### Economics and assets
| Word | Meaning in this document |
|---|---|
| **LOVE9** | The 9Chain network's native token — used for staking, voting, accounting |
| **AGAPE** | The only endowment holding a balance at birth; every issued flow opens from here |
| **VERITAS · LIBERTAS · AETERNUM** | The three parts each day's flow divides into: truth about people · keeping the network alive · builders and the future |
| **The four zeros** | No premine · no team allocation · no investment fund · no sale to anyone. **NOT on the engraved list** — the current constitution engraves no number. They are a verifiable fact of each period's genesis file, and a **PROPOSAL** to keep for later periods |
| **Operating capital** | The advance that lets the network run on day one — **an advance, not a grant**: what is unspent returns to the endowment |
| **Gasless** | Users pay no fee to submit a transaction. It does not mean the network costs nothing — it means somebody else is paying |
| **LOVE9 Point** | Community points on the project's community platform. **Not the network's token**, not on chain, and **whether they convert is LEFT BLANK** |
| **Token issuer** | An asset issued by an organisation on their chain, not the network's native token |
### Customer chains and compliance
| Word | Meaning in this document |
|---|---|
| **The chain-producing machine** | The infrastructure that takes a description and raises, keeps alive, and tears down a private chain |
| **Customer chain** | A private chain produced for an organisation or a community |
| **Declaration · blueprint** | A written declaration of a chain: what it is, what its rules are — what the infrastructure reads in order to build it |
| **Compliance at the protocol layer** | Rules enforced inside the consensus mechanism itself, not in a contract running above it |
| **Shared identity** | Proving you are you **once** and being able to use it across many chains. This is the part the project still has to prove |
| **Interoperability** | The ability of two chains to read and trust each other's data. In this project, opening the first channel is **a gate not yet passed** |
### How to read this document
| Word | Meaning in this document |
|---|---|
| **ENGRAVED** | Locked permanently, changeable by nobody — including whoever holds the name |
| **RUNNING** | Built, and verifiable from outside |
| **PROPOSED** | Drafted by the founding group; the community can change it by vote |
| **LEFT BLANK** | Deliberately undecided. Not forgotten, and not a promise either |
| **Gate** | A condition that must be passed, written in criteria rather than dates — so it does not go out of date |
| **Maturity level** | A four-step scale measuring **what the system has proven**, read in [*Check the network yourself*](/en/check-the-network-yourself). Moving back a level can happen |
| **Live measurement** | A number that changes over time. The body of this document contains none — they live only where they are read straight from the network |
| **Hash anchoring** | Timestamping a version of the document into a public ledger, so that later it can be proven unaltered. It proves **integrity and timing**, not that the content is true |
```mermaid
flowchart LR
W["A word in the document"] --> N{"Which group?"}
N -->|"network"| A["Consensus · nodes · genesis"]
N -->|"money"| B["LOVE9 · endowment · three parts"]
N -->|"customer chains"| C["Producing machine · compliance"]
N -->|"reading"| D["Four labels · gates · levels"]
```
*Figure 33 — The glossary splits into four groups, matching the document's four lines of content.*
> **In short:** most arguments about an infrastructure project turn out to be **arguments about what words mean** — so a public glossary is the cheapest guard against talking past each other.
## Security and disclosure
This page answers three questions: **where to report a vulnerability**, **how far the project has been audited**, and **what you should guard against yourself** on any network in its test phase.
### Official channels — read this first, because the rest depends on it
A warning that *"an impersonator is a fraudster"* is only usable if you know **what is genuine**. This is the closed list:
| Channel | Address | Used for |
|---|---|---|
| This documentation | `docs.9chain.org` | Design, mechanism, how to check for yourself |
| Technical documentation | [9chain.org/docs](https://9chain.org/docs) | Connecting, running a node, endpoints |
| Mail | **contact@9chain.org** | Feedback · criticism · **vulnerability reports** |
| Community | [t.me/LOVE_9Chain](https://t.me/LOVE_9Chain) | Public questions |
**Anything outside this list is not the project** — there is no fifth channel, no staff member who messages you first, and no project wallet that takes your money.
### Reporting a vulnerability
Send it to **contact@9chain.org**. Please do not publish details publicly before the vulnerability is fixed — an unfixed vulnerability disclosed early harms the people trusting the network, not the person who wrote it.
| What to send | Why it is needed |
|---|---|
| A description of the flaw and **how to reproduce it** | What cannot be reproduced cannot be fixed, nor confirmed as fixed |
| Your estimate of the impact | To order the work — not every flaw is equally urgent |
| A way to reach you | To ask follow-up questions, and to credit you if you want it |
#### How long we take to reply
**Acknowledgement within 72 hours. Preliminary assessment within 7 days.** If that passes in silence, raise it again in the community channel — **silence is our failure, not an answer.**
The limits of that promise, stated plainly, because you deserve to know what you are relying on: this is a **shared** mailbox for feedback and reports, read by a small team, and there is **no dedicated end-to-end encrypted channel for security reports yet** — that is a **gate not yet passed**. If what you intend to send is dangerous enough that it should not sit in an ordinary mailbox, send one line asking for a safe channel first; do not send the details straight away.
#### Our commitment to good-faith reporters
If you report through the address above, **do not exploit beyond what is needed to demonstrate the flaw**, **do not access anyone else's data**, and **give us time to fix before publishing** — then:
- we will **not pursue you in any form**;
- and if a third party pursues you over that report, **we will say so on your behalf**.
| This commitment covers | It does not cover |
|---|---|
| The test networks and the project's public nodes | Denial of service, or anything that stops the network serving others |
| This documentation and the verification page | Social engineering against people (deceiving staff, impersonation) |
| The source code, **once the repository is opened** | Third-party infrastructure — the explorer, hosting providers, users' wallets |
Why write this down: at most infrastructure projects **it does not exist** — including some of the largest in the industry. Whoever finds a flaw must first weigh whether reporting it exposes them to legal trouble, and whoever does that weighing usually chooses silence. One line of commitment is far cheaper than one unreported vulnerability.
The honest thing to say alongside: **a bug bounty programme is LEFT BLANK** — the project has announced no reward, so do not report expecting payment. Public credit can be given immediately, and that is something the project can promise without overstating.
### How far it has been audited
| Kind of review | Status | Read more |
|---|---|---|
| Internal review and acceptance tests | **RUNNING** | [*Operations and governance*](/en/operations-and-governance), under *Operational discipline* |
| Independent third-party audit | **A mandatory gate of the *Real assets* level** — not passed | [*Check the network yourself*](/en/check-the-network-yourself), under *The maturity ladder* |
| A real key ceremony with several holders | **Gate not passed** — the mechanism exists, the ceremony does not | [*Operations and governance*](/en/operations-and-governance), under *Governance and who holds the keys* |
| Distributing the signing set across independent failure domains | **Gate not passed**, with a countable threshold | [*The 9Chain platform*](/en/the-9chain-platform), under *Security and fault tolerance* |
How to read that table correctly: a project saying *"we take security very seriously"* gives you no information. A project saying *"an independent audit is a mandatory gate of level four, and we are not at level four"* gives you a **checkable** sentence — and gives you the right to ask again next time.
```mermaid
flowchart TB
F["You find a vulnerability"] --> P["Send it privately to the project"]
P --> V["Fix, then publish"]
F -.->|"the path NOT to take"| X["Publish details immediately"]
X -.-> H["People trusting the network are harmed"]
```
*Figure 34 — Responsible disclosure: order matters more than speed.*
### Three things to guard against in the test phase
**Do not treat assets on a test period as assets.** A test period can be rebuilt, and balances of an abandoned build do not flow into the next one. The inheritance promise takes effect only from the official network.
**Do not believe anyone promising a conversion rate.** How LOVE9 is received is **LEFT BLANK**, and anyone stating a fixed rate from points to tokens is putting words in the project's mouth — nobody has decided that.
**Do not believe anyone selling a share.** Ownership here is **one person, one share, one vote**, and no amount of money buys more — so anyone offering to sell you a share in this project's name is defrauding you, even with the right name and the right logo.
> **In short:** a trustworthy security page is not one boasting about what has been audited, but one **stating clearly what has not** — and pointing at where you can check again yourself.
## Legal, licence and legal entity
The project's three legal boundaries, gathered in one place because they are so often read into each other: **what is not an offer**, **what belongs to whom**, and **who stands behind this document**.
This page sits **after** the self-check part and after the invitation, following a rule of the whole document: **check first, invite second — and once you have invited, state the boundaries plainly.** The three sections below are not appendix material for a tidy file; each one blocks a misreading that has been seen in the wild.
| Boundary | Which misreading it blocks | Label |
|---|---|---|
| **Not an investment offer** | *"own it together"* read as *"buy a share"* | A published principle, verifiable in each period's genesis file |
| **Code and name are separate** | *"open source"* read as *"anyone may call their product 9Chain"* | Code licence: **PROPOSED** · trademark: **RUNNING** |
| **Two different legal entities** | *"there is an entity holding the name"* read as *"there is an entity operating the network"* | Holding the name: **RUNNING** · operating: **LEFT BLANK** |
```mermaid
flowchart TB
R["You read 'own it together'"] --> A{"What does it mean?"}
A -->|"CORRECT"| B["One human · one share · one vote
no amount of money buys more"]
A -.->|"WRONG, and whoever says it is defrauding you"| C["Buy a portion · early access · profit share"]
B --> D["The name does have an owner
— and that is what gives
'an impersonator is a fraudster' its meaning"]
```
*Figure 35 — One phrase, two readings, only one of them correct.*
### This is not an investment offer
It must be said plainly, because the words *own together* are easily read as a sales pitch.
**No selling, no listing, no price support, no promise of returns.** These four are the project's published principles and a verifiable fact of every period run so far — and under the constitution, the only way such a thing could change is **a public on-chain vote**, never an offer in a private message. *Ownership* in this document means **one real human, one share, one vote** — something no amount of money buys more of, and something you do not lose by arriving late.
The direct consequence, worth remembering: **anyone offering to sell you a share, a portion, or early access in this project's name is defrauding you** — even if they use the right name, the right logo, and the right words from this document.
### The code and the name do not belong together
Having said *own together*, this half must be said too, because it is the most easily misunderstood point remaining.
**The code** will be released under the open Apache-2.0 licence: anyone may read it, use it, modify it, and build their own version — including a competing one. The label on that sentence is **PROPOSED**, not RUNNING: a licence only takes effect once there is a repository to apply it to, and the repository is still **a closed door**. **The name does not travel with the code.** *"9Chain"*, *"LOVE9"* and the associated marks are held by **Krao Holdings**, and are **not part of that licence**. In short: you may say your product is **built on** 9Chain; you may not say it **is** 9Chain, nor let anyone believe you speak for the project.
Placing this right beside the invitation is deliberate. **An invitation to co-own a network is not an invitation to own a name** — and the place where those two get confused is exactly where the sales pitches above come from. A name with a clear owner is what gives the sentence *"an impersonator is a fraudster"* any meaning; if the name had no owner, nobody could impersonate anyone, and nobody could protect you either.
This is a boundary about **the right to use a name**, not about decision rights. What the community can vote on remains exactly as this document states — and the rule that *everything belongs to the community to decide together* sits in the constitutional text itself; even the holder of the name cannot take it down.
### Who stands behind this, and what belongs to whom
A document that asks readers to verify everything, without saying who wrote it, is asking in one direction only. So here it is in full, including the unflattering part.
There are **two different legal entities** here, and this document used to let them blur together:
| | What it is | Status |
|---|---|---|
| **The entity holding the name** | **Krao Holdings** — holds the *9Chain* and *LOVE9* marks. This is what gives the sentence *"an impersonator is a fraudster"* any meaning | **RUNNING** — it exists, and it holds the name |
| **The entity that will operate the network once it touches real assets** | The party carrying licences and legal accountability to each jurisdiction's regulator | **LEFT BLANK** — not settled, and it determines the entire licensing regime |
These are not the same thing. That the name has an owner does **not** mean the network has an operating entity; and that the operating entity is still blank does **not** mean the name is unowned.
**The people are not named in this version.** The founding group is not listed here, and that choice has a price: a project that sells nothing carries no legal duty to publish identities, but it carries another duty — it invites strangers to build something meant to last centuries. So the honest measure of separated key custody is not *"are there three key groups"* but: **how many key holders do not depend on this project for their income.** Same organisation, same city, same interests, and three key groups are still one group of people. That is a gate not yet passed, and it belongs on the same list as the three doors below.
> **In short:** these three boundaries are not there to defend the project, but to **give you ground to stand on when someone speaks to you in the project's name and says otherwise** — a name with an owner, a licence with a scope, and an entity not yet settled that says so plainly.
## FAQ
Twenty-seven questions — nine groups of three. The first version had eighty-one; more than half only gave a short answer and pointed elsewhere, so they were cut. What remains are the questions with **content that is nowhere else**, and the questions whose honest answer is *"not yet"*.
The answers use the four labels from [*Before you read*](/en/before-you-read) — **RUNNING · PROPOSED · LEFT BLANK · ENGRAVED** — plus one recurring phrase: **it is a gate**, meaning a condition not yet met rather than a task forgotten.
```mermaid
flowchart TB
N["27 questions · 9 groups"] --> A["Newcomers
1 Basics · 2 LOVE9"]
N --> B["Those who want to help operate
3 Nodes · 4 Security"]
N --> C["Organisations and developers
5 Legal · 6 Organisations · 7 Developers"]
N --> D["Those who want to verify
8 Governance · 9 Status"]
```
*Figure 36 — Nine groups arranged by four kinds of reader.*
| Group | Topic | For whom |
|---|---|---|
| 1 | Basics | Anyone hearing the name for the first time |
| 2 | LOVE9 and distribution | Anyone interested in the token |
| 3 | Running nodes and validators | Anyone wanting to contribute infrastructure |
| 4 | Security and risk | Anyone assessing risk |
| 5 | Compliance and legal | Organisations with compliance obligations |
| 6 | For organisations | Potential customers |
| 7 | For developers | Anyone writing contracts and applications |
| 8 | Governance and community | Anyone wanting a voice |
| 9 | Status and trust | Anyone wanting to verify for themselves |
### Group 1 · Basics
**1. What is 9Chain? Is it a blockchain?**
Yes. 9Chain is a blockchain: the project's public network, native token LOVE9, that is, a Layer 1. But the name also refers to two other things. The 9Chain platform — the machine producing chains for customers — is not a blockchain but the thing that *produces* blockchains, which is the Layer 0 position. And each chain produced for a customer is a private blockchain, also Layer 1.
The shortest form: **a multi-chain blockchain network belonging to everyone** — many private chains, one shared network so they can trust each other. At the level of meaning: 9Chain makes having a ledger of your own, that nobody can switch off and nobody can quietly alter, something anyone can reach. The full comparison table is in [*Context*](/en/context).
**2. Is 9Chain a Layer 0? How is it different from raising a Cosmos chain myself?**
Under the prevailing classification, **its position is Layer 0** — the tier that produces and connects chains. But it is the **Cosmos style, not the Polkadot style**: each chain keeps its own validator set, with **no shared security**. What differs from raising a Cosmos chain yourself: here the whole lifecycle is encoded — key generation, genesis assembly, deployment, self-healing, teardown — and each chain arrives with a compliance gate inside consensus rather than bolted on with a contract. Why this document does not use "Layer 0" as its definition: see [*Context*](/en/context).
**3. What does the number 9 mean?**
It is an identifying motif, and it also shapes some proposed parameters: total supply 9² billion, validator ceiling 81, a release rhythm of 0.09% per day, 9% of fees back to the endowment and 9% burned. To be clear: those are **opening proposals**, not inviolable constants, and the community can vote on them.
### Group 2 · LOVE9 and distribution
**1. How much do the team and investors hold?**
No share at all. No premine, no sale to anyone — and you do not have to take our word for it: it is **readable in each period's genesis file**. The current constitution no longer engraves this as permanent law; like everything else beyond the three memorial blocks, it belongs to the community's vote — meaning that to change it, someone must **win a public vote, in front of you**.
**2. So how does one receive LOVE9?**
**The receiving mechanism has not been designed.** The current proposal states who receives — verified real human beings, one share each — with two constraints: it must be measurable on chain, and settled by vote; the minimal constitution leaves even that to the community. Until a receiving mechanism has passed a vote, the endowment cannot open — a structured blank, not an empty promise.
**3. Where is the token listed, and at what price?**
The project does not sell, does not list, does not support the price and does not promise returns. Anyone promising returns in 9Chain's name does not represent the project.
### Group 3 · Running nodes and validators
**1. Do I have to buy or hold tokens to be a validator?**
No. The network's security comes from identity, contracts and several independent parties, not from an asset's price. See [*The 9Chain platform*](/en/the-9chain-platform).
**2. At which level can outsiders run nodes?**
At the *Open to outsiders* level, and that level has its own full set of gates: participation artefacts, a public image, a community channel, a security reporting address, and anti-abuse at every public write path. [*Applications and users*](/en/applications-and-users) states plainly that this leaves two audiences unable to use it.
**3. Are more validators always safer?**
Not necessarily. Fault tolerance comes from the number of **independent failure domains** — different machine, different region, different provider — not from the number of processes. Many processes on one cluster tolerate exactly one machine. The countable threshold is in [*The 9Chain platform*](/en/the-9chain-platform): no machine may hold a third or more of the validators, and one machine leaving the cluster is not enough to move the measurement.
### Group 4 · Security and risk
**1. Has there been an independent audit?**
An independent audit is **a mandatory gate** of the *Real assets* level — so if the project is not at that level, you know the answer. Internal review does not substitute for a third party's assessment.
**2. What is the largest technical risk?**
The maturity of the EVM base in use — it is still pre-stable. Mitigated by pinning versions, keeping load low and leaving an upgrade path. The document ranks it as the largest risk rather than burying it at the end of a list.
**3. Can the chain be captured?**
In theory any consensus network can be captured if one party gathers more than two thirds of voting power. Two things aim to stand against it here: a high self-bond threshold, and the rule that no party holds more than a third. Both are **gates not yet passed** rather than protections already switched on — the genesis file says plainly that the self-bond floor is not yet enforced in consensus.
### Group 5 · Compliance and legal
**1. Is KYC data written on chain?**
No. Only a reference **hash** is on chain. Personally identifying data is never written there.
**2. Does 9Chain have a licence?**
Jurisdiction and legal entity are **gates of the *Real assets* level**: they determine the entire licensing regime, so until they are settled there is no licence to speak of.
**3. Is this a token offering?**
No. No sale, no listing, no promise of returns. This document is not an investment solicitation.
### Group 6 · For organisations
**1. Is my chain private from 9Chain itself?**
This needs a direct answer: in fully platform-run mode, no — whoever runs the nodes sees the data. To reduce that, choose mixed or multi-party mode, where you and an auditor run nodes yourselves. That is exactly why the default mode always has at least one node outside the operating team.
**2. What if I want to leave?**
You keep the data, because the chain is yours and you can run a node yourself. The real barrier is not data but operations: leaving means carrying the load the platform is carrying.
**3. What happens to my chain if 9Chain stops operating?**
This is the most worthwhile question in this group. The honest answer has two halves: your chain **technically** keeps running if enough independent nodes are running it; but if every node is run by the platform, that is only a promise. The second half is why the default mode always includes an outside node.
### Group 7 · For developers
**1. Can I use familiar EVM tooling?**
Yes — the chains produced are EVM appchains, so familiar wallets, libraries and deployment pipelines all carry over.
**2. Is there somewhere to try it?**
Yes, but read [*Check the network yourself*](/en/check-the-network-yourself) first: builds for testing **carry exactly the official network's identity**, and the only way to tell them apart is the time of the first block.
**3. How does interoperability work?**
Assets arrive through gated middleware; if the recipient is not approved, the packet returns an error and funds are refunded to source. One detail worth remembering when writing an indexer: the event for a rejected packet is re-emitted **with a different prefix**, and if you do not match it you will undercount exactly the packets that were blocked.
### Group 8 · Governance and community
**1. What about everything beyond those four?**
Everything else can be voted on, including the release rhythm, the ratio of the three parts, and how a human receives their share — and under the minimal constitution, in principle **so can those four**: the only things outside the vote are the three memorial blocks and the rule that *everything belongs to the community*. The difference is the path: changing those four must win a public on-chain vote — nobody can change them quietly.
**2. Where are the community channels?**
Two addresses, both receiving feedback, criticism and **security reports**: [contact@9chain.org](mailto:contact@9chain.org) and [t.me/LOVE_9Chain](https://t.me/LOVE_9Chain). This door is **open**; the closed ones are listed directly in [*Taking part, and the doors still owed*](/en/taking-part-and-the-doors-still-owed).
**3. What if the community wants to change the project's direction?**
That is what the voting mechanism exists to allow — and under the minimal constitution the scope is nearly total: only the three memorial blocks stand outside. A project claiming to be community-decided without a path for the community to change direction is only talking well.
### Group 9 · Status and trust
**1. How do I know whether I am looking at the real network or a build for testing?**
Compare **the time of the first block** with the announced birth moment. Matching means the official network; differing means another build. The chain's name is not enough.
**2. Across the testnet periods and into mainnet, what happens to my share?**
Two halves, and both must be read. First: **contribution history is preserved** — mainnet is defined as *Testnet 1 + Testnet 2 + Testnet 3 + Mainnet*, so what you did in a test period is not erased when the next begins. Second, no less important: **no period promises a one-for-one balance**. What that history converts into — or whether it converts at all — is **LEFT BLANK**, for the community to vote on at mainnet. Anyone guaranteeing you a conversion rate is putting words in the project's mouth — nobody has decided that.
**3. Could this document be quietly altered?**
Its content is hashed and anchored to Bitcoin. The *Verify this document* page gives you all three artefacts to reconcile with independent tools, without taking anyone's word.
> **In short:** count how many of the twenty-seven answers above are **"not yet"** or **"not designed yet"**. That number is not the document's weakness — it is what makes the **"already running"** answers worth believing.
## Nine factors, and one name
This page is **an empty box with measurable dimensions** — not a section presenting design. It builds a frame, writes exactly one ninth of it, then stops and hands the rest to someone else.
Read it differently from the technical pages: there is **nothing here to believe**, only a test to run. The founding group\s own filled-in version is in [*Appendix — The first submission*](/en/appendix-the-first-submission), deliberately placed outside the body of the document.
Every project has a list of *why we will succeed*. This document does not write that list. It writes exactly **one ninth** of it, and then stops.
The frame is this: nine factors, nine points each. The ninth point of all nine factors leads to the same place — **the name**. The other eight points of each factor are left empty.
| Factor | The ninth point — what the name carries |
|---|---|
| **Strategy** | A strategy only spreads if it can be repeated in one sentence at a dinner table — *blockchain number 9* does that before anyone opens a slide deck |
| **Technology** | End users cannot carry a consensus mechanism or a validator set around with them. The only part of an infrastructure they carry is a name |
| **Product** | The network, explorer and token share one mark, so people see the relationship between them without anyone explaining an ecosystem diagram |
| **Community** | A digit belongs to no language. A community of many nationalities says the project's name identically, with nothing to translate |
| **Culture** | Reaching the number nine, most people feel something complete rather than something unfinished — that goodwill is already there, and no budget buys it |
| **Humanity** | Someone who never went to school still knows the number nine. That is the lowest door an infrastructure can offer an end user |
| **Brand** | The cost of remembering is near zero: no slogan is needed to explain a slogan |
| **Economics** | The proposed parameters all anchor to one number — total supply 9², validator ceiling 81, a release rhythm of 0.09% per day, 9% of fees back to the endowment and 9% burned. Because the rhythm is even, quietly altering one parameter falls out of tune at once: turning 0.09% into 0.1% breaks a rhythm even outsiders can hear. This is the one place the name does something **verifiable** — a layer of auditing by memory |
| **Execution** | The only factor where the name stands **behind** rather than alongside: finish the other eight and the name is an amplifier; leave them unfinished and it amplifies an empty space |
> **The name borrows from no faith.** Nine is the digit humans used to **check their books** long before computers: the digits of every multiple of nine sum back to nine, so earlier bookkeepers used it to catch arithmetic errors. A ledger named after a way of checking ledgers.
**The other eight points of each factor — seventy-two boxes — are labelled LEFT BLANK**, and blank on purpose. Were the founding group to write all eighty-one points, this would stop being an analysis and become an advertisement: anyone can write eighty-one reasons for their own project. What nobody can write for themselves is **someone else's reasons** — so that part belongs to someone else.
The frame is therefore a test rather than a boast: **any factor the community cannot fill with eight points is not yet an advantage.** An outsider's version may be shorter than this one, and may show that several of the factors above do not stand up — that is still a correct result of the test.
**The place to collect those seventy-two boxes is a door not yet open.** It needs a public place to submit and a public way to choose what is kept; without either, the boxes stay empty spaces rather than a form. The two addresses above still receive, and the nine factor names are themselves subject to a vote — including replacing one factor with another.
**The founding group submits its own version first, and submits it outside the body of the document** — that version is the appendix *The first submission*. It is not an answer key, it is **something for others to refute**: an empty box is hard to argue with, whereas a written version can be argued with point by point. It comes with a rule that keeps it from quietly becoming the answer — whoever holds authority and submits first will find their version easily becoming the default, so it must **carry the submitter's name, sit outside the body, and never be cited as a section of this document**. The seventy-two boxes stay empty.
```mermaid
flowchart LR
Y["Any one factor
of the nine"] --> B["Point 9
the name"]
Y --> A["Points 1 … 8
LEFT BLANK"]
A -.-> T["Eight points can be filled
⇒ the factor stands"]
A -.-> F["They cannot
⇒ not yet an advantage"]
```
*Figure 37 — The document writes one box in nine. The other eight are a test, not decoration.*
And the unwelcome half must be said too: **the name amplifies mistakes as well.** It sits directly under the *Resonance* pillar — an amplifier does not get to choose what it amplifies. A memorable name makes a good ledger spread faster, and a broken one spread just as fast. The nine factors above say the project **has a chance**; they do not say which gate it has passed. Which gates are passed is read in [*Check the network yourself*](/en/check-the-network-yourself), not here.
> **In short:** a project that writes all eighty-one reasons for itself is advertising; a project that writes nine and **leaves seventy-two boxes empty** is inviting you to check — and any box nobody can fill has answered for itself.
## Appendix — The first submission
*Nine factors, and one name* sets up a frame of nine factors, nine points each, and **writes only the ninth point**. The other seventy-two boxes are left for others to fill. This page is **the first submission into those seventy-two boxes**, written by the **founding group**.
> **Read this page differently from the pages above.** It is **not a section of the document**: it carries no ENGRAVED label, makes no design statement, and binds nobody. It is **an artefact with an author** — an entry, published to be refuted rather than believed. The body of the document does not cite it, and the seventy-two boxes remain labelled LEFT BLANK after you finish reading.
**Why the founding group submits first.** An empty box is hard to argue with; a written version can be argued with point by point. But whoever holds authority and submits first will find their version quietly becoming the default answer — so this one carries the submitter's name, sits outside the body, and **may not be cited as a section of the document**. Your version may be shorter, may refute each point, and may conclude that several of those nine factors do not stand up.
**This is a snapshot of one moment, deliberately not updated.** It describes things existing when it was written — websites, tools, community activity — exactly the kind of fact the body forbids itself. A submission may, because it is an artefact rather than the document's own testimony: its moment is anchored by the hash on the *Verify this document* page. To find out how far it still holds when you read it, read [*Check the network yourself*](/en/check-the-network-yourself).
| Kind of sentence in a submission | How to read it | Example |
|---|---|---|
| **A condition to be met** — *must*, *needs*, *if* | A gate not yet passed, not something done | *"Validator infrastructure must be stable"* |
| **A description of what exists** | A snapshot at time of writing; re-check in [*Check the network yourself*](/en/check-the-network-yourself) | *"An independent explorer so anyone can verify the data"* |
| **The submitter's judgement** | An opinion, open to refutation | *"A platform supporting many chains has more room to grow"* |
Try counting by those three kinds before believing any line — including in your own submission later.
### 1 · Strategy
1. The market already has many blockchains, but raising and running a chain of your own is still complex, costly and demanding of deep technical staff.
2. The direction is many chains serving many purposes, rather than one network doing everything.
3. If starting a chain genuinely reduces to a simple procedure, that is a considerable competitive advantage — the *if* here is a gate, not a description.
4. Shared nodes, validators, explorers and tooling save new chains time and deployment cost.
5. AI can help with configuration, monitoring, anomaly detection and simplifying operations. The limit must be stated: AI makes this **faster**, not **more correct** — remove AI and the problem is still there in full.
6. Users do not only receive a product; they experience it, give feedback, propose things, and take part in some decisions.
7. Designed well, the platform serves developers, businesses, institutions, communities and newcomers alike.
8. A platform supporting many chains has more room to grow than a product solving exactly one need.
### 2 · Technology
1. The architecture must create, configure and operate many chains with differing requirements.
2. Customisation must be flexible enough: speed, fees, access, assets, governance, degree of decentralisation.
3. Complex technical work must become a comprehensible procedure — that is where the platform's value lies.
4. Validator infrastructure must be stable. This is where real technical capability is measured, not declared.
5. Data must be verifiable: an explorer allowing anyone to follow blocks, transactions, addresses and network state.
6. Developers need adequate documentation, APIs, SDKs and test environments.
7. Code, contracts and infrastructure must be tested, monitored and **independently security-assessed** — without an independent assessment this is a gate not yet passed.
8. The experience must be simple: users should not have to understand the whole of the complexity in order to use it.
### 3 · Product
1. A technical face publishing architecture, development documentation and infrastructure direction.
2. A community face where participants can experience it, complete tasks, contribute and discuss governance.
3. An independent explorer so anyone can verify data without asking the project.
4. A testnet where users and developers try the system, find flaws and give feedback before features are settled.
5. Node activity helps participants understand how a network runs, instead of knowing it only as a concept.
6. Real applications are what keep users; an ecosystem without applications is only a demonstration.
7. Community points record contributions on the community platform. **Points are not the network's token**, and whether they convert into anything is **LEFT BLANK** — anyone guaranteeing a conversion rate is putting words in the project's mouth — nobody has decided that.
8. The products must complement each other into one coherent experience rather than existing separately.
### 4 · Community
1. Users can reach it early, through the testnet, before the ecosystem is complete.
2. There are many ways to take part: trying products, running nodes, using applications, contributing content, finding bugs, proposing initiatives.
3. Contributions are recorded by a counting system rather than resting on someone's impression.
4. Feedback from real use surfaces problems invisible in an internal development environment.
5. A proposal mechanism draws on knowledge and creativity from a wider group than the team.
6. Voting, designed sensibly, raises transparency and creates a real sense of shared ownership.
7. The more participants, the more feedback, content, applications and opportunities for collaboration.
8. Rights come with responsibilities: clear rules, anti-manipulation mechanisms, and accountability for each decision.
### 5 · Culture
1. A culture of participation — members are encouraged to act rather than only observe.
2. A culture of co-creation — the community helps complete the product and shape its direction.
3. A culture of respecting contribution — time, knowledge, technical skill and creativity all fairly recognised.
4. A culture of transparency — rules about points, voting and entitlements must be published clearly.
5. A culture of learning — newcomers approach blockchain step by step in a real environment.
6. A culture of cooperation — developers, validators, businesses and users work together rather than separately.
7. A culture of accountability — the right to take part in governance comes with responsibility for the consequences.
8. A culture oriented to long-term value — a durable community is built on use value, not on expectation of rewards.
### 6 · Humanity
1. The technology must be accessible: nobody is excluded merely for lacking technical knowledge.
2. Opportunities to take part must be broad — a diverse community produces more perspectives than one made only of specialists.
3. Many forms of contribution must be recognised: not everyone has capital or knows how to program.
4. Participants need a voice through proposal and voting mechanisms.
5. Every mechanism distributing entitlements must have clear, verifiable criteria — without criteria it is patronage, not recognition.
6. Users need protection: security, privacy, risk warnings, responsible communication.
7. Do not turn users into a marketing instrument — community activity only means something when value flows both ways.
8. Real value must rank above speculation: users need a reason to use the product beyond expecting a reward.
### 7 · Brand
1. A short name, quickly read and remembered, needing no time to explain.
2. The structure speaks for itself: *Chain* suggests blockchain, the number 9 gives it a mark of its own.
3. Convenient to search for, to type again, to share and to introduce to others.
4. One central mark used throughout the whole identity system.
5. It forms a brand family: the products connect to each other from the name alone.
6. Less language-dependent than long or locally rooted names — an advantage in a multinational environment.
7. The community can use it themselves: a simple mark makes it easy for members to create images, videos and content.
8. The positioning message lands in seconds: *9Chain — blockchain number 9*.
### 8 · Economics
1. No share for the team or investors, and that is readable in the genesis file rather than taken on trust.
2. Issuance must have a public formula — a fixed release rhythm rather than case-by-case decisions.
3. The released flow must divide across different kinds of work, not concentrate in one place.
4. Network fees need a path back to the endowment rather than flowing entirely outward.
5. Community points and tokens must be kept absolutely distinct; confusing the two is the largest source of misunderstanding in an ecosystem that has both.
6. How a human being receives their share is still a question without an answer — an economic model that cannot answer it is not finished.
7. The model must survive the community changing the model itself: every parameter is a proposal, changeable by vote.
8. Value must come from real use. An economy standing only on price expectations does not stand for long.
### 9 · Execution
1. The roadmap must be concrete: each stage with objectives, deadlines and clear evaluation criteria.
2. The product must run — technology claims proven by testnet, explorer, nodes, applications and real experience.
3. The team must have the right expertise: technology, security, economics, law, operations, community development.
4. Information must be transparent — progress, changes, risks and difficulties all told honestly.
5. Governance must be sound: voting power accompanied by mechanisms against manipulation, conflicts of interest and concentration of power.
6. Security must be proven by independent audit, a vulnerability programme and an incident process.
7. The economic model must be tied to real value, not merely short-term incentives.
8. Trust is not built with promises. It accumulates through each product finished, each commitment kept, each incident handled responsibly.
```mermaid
flowchart LR
N["The founding group's
submission"] -.-> O["Seventy-two boxes
still LEFT BLANK"]
N --> P["To be refuted
point by point"]
O --> Q["Your version
may be shorter"]
Q --> R["Refuting a factor
⇒ still a correct result"]
```
*Figure 38 — A submission does not close the empty boxes. It only gives whoever comes next something to aim at.*
**What this submission admits about itself.** Most of the eighty-one points above are written as *must*, *needs*, *if* — that is, **conditions not yet met**, not achievements. Read closely, this is not a list of reasons to believe, but **a list of unfinished work**, arranged in nine groups. Whoever submitted it holds that this is the honest shape of an answer to the question *"why is this project worth attention"* — and if your version comes out the same shape, the two are saying the same thing.
> **In short:** a good name makes people stop. A good product makes people stay. Only real value makes people walk alongside. The eight points must be proven by capability; the ninth only helps people remember — and it is only worth remembering if the other eight stand up.