# 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 **nine billion** — a figure sized to the number of people on Earth — and its allocation table is labelled PROPOSED, for the community to vote on.

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. [*How to read this document*](/en/how-to-read-this-document) 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 and need*](/en/context-and-need) → [*Platform architecture*](/en/platform-architecture) → [*Who uses it, and who cannot yet*](/en/who-uses-it-and-who-cannot-yet) → [*Risks and open questions*](/en/risks-and-open-questions) |
| **An operator or a developer** | [*Platform architecture*](/en/platform-architecture) → [*Governance*](/en/governance) → [*FAQ*](/en/faq) |
| **A sceptic** | [*How to read this document*](/en/how-to-read-this-document) → [*Risks and open questions*](/en/risks-and-open-questions) → [*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.

## How to read this document

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 [*Risks and open questions*](/en/risks-and-open-questions) |
| **PROPOSED** | Drafted by the founding group, awaiting the community | **The community**, through argument and then a vote | Total supply of nine billion · the allocation table · the release rhythm · the nine roles · 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<br/>drafted by founders"] --> R["PUBLIC ARGUMENT<br/>anyone may object"]
  R --> G["MANDATORY GATE<br/>voting power must leave<br/>the project's hands FIRST"]
  G --> B{"Vote with<br/>a real quorum"}
  B -- "rejected" --> P
  B -- "passed" --> K["Into the genesis of<br/>the official network"]
  K --> KH["OPENING RECORD<br/>immutable as a record,<br/>still changeable as a rule"]
```

*Figure 1 — The path of a decision. The gate in the middle is where the project blocks itself: see Nine roles.*

### 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). On the roadmap, the closing point has a clear name: **the vote that chooses the branch** — 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.

## Positioning and boundaries

The three sentences below do three different jobs. Do not make one sentence carry all three — that is how a positioning dies.

| Sentence | Its job | Content |
|---|---|---|
| **Positioning** | memorable, used on every surface | *9Chain — the multi-chain blockchain network that belongs to everyone.* |
| **The full line** | the whole shape in one breath | *A chain of your own for each person, and a shared network so those chains can trust one another — something only a few have ever had, now open to anyone.* |
| **Definition** | states the **meaning**, not the technology | *9Chain turns having a ledger of your own — one nobody can switch off and nobody can quietly rewrite — from the privilege of a few into something available to anyone.* |

Two words in the positioning have to be kept exactly, because changing one changes the model. **"Belongs to everyone"** rather than *"for everyone"*: *for* makes them guests, *belongs to* makes them owners. **"Multi-chain"** rather than *"multi-application"*: multi-application describes the ordinary case — every chain is that — and it points at a different model, whereas the real shape here is **many chains plus one shared network**.

And the definition deliberately states a **function**, not a technology name. *In the technology of one era, that ledger takes the form of a blockchain of your own* — but "blockchain" is **how it is done in one era, not what it is**. A document meant to outlive the technology it describes cannot take that technology's name as its own definition.

### Is 9Chain a blockchain, and which layer

**Yes — 9Chain is a blockchain, Layer 1.** That is the project's public network, with a native coin of its own. But the same name also points at two more things, and this order matters:

| # | What the name points at | Where it sits |
|---|---|---|
| **1** | **The 9Chain network** — the project's public network | **Layer 1** |
| **2** | **The 9Chain platform** — the machine that produces other chains | **Layer 0** (not a chain) |
| **3** | **Each chain created for a user** | **Layer 1** of its own |

**There is no Layer 2 in this model.** The compact version: *9Chain is a Layer 1 blockchain — and the same name also refers to the machine that produces other blockchains.*

⚠️ The Layer 0 position here is the **many-chains-secure-themselves** kind, not the shared-security kind: each chain produced **keeps its own signing set**, and that is deliberate — shared security means outside signers can see the data, which breaks exactly what many customers need.

```mermaid
flowchart TB
  N["THE 9CHAIN NETWORK<br/>Layer 1 — the project's public network"]
  P["THE 9CHAIN PLATFORM<br/>Layer 0 — the chain-producing machine"]
  N --- P
  P --> C1["A's chain<br/>its own Layer 1"]
  P --> C2["B's chain<br/>its own Layer 1"]
  C1 -.->|"shared identity"| N
  C2 -.->|"shared identity"| N
  C1 -.->|"governance and value"| N
  C2 -.->|"governance and value"| N
```

*Figure 2 — One name covering three things. The three dashed paths are the three jobs the shared network carries; they are the reason the chains are not islands.*

**Three jobs the shared network carries: shared identity · governance · value.** Of those, the *many chains* half already exists; **the *one identity* half is what still has to be proved** — see [*Many chains, one identity*](/en/many-chains-one-identity). Saying a bridge moves assets is one thing; saying *"a bridge can move an asset, but it cannot move who you are"* is where the actual problem sits.

### Boundaries: what 9Chain is NOT

| Not | Why it has to be said |
|---|---|
| **A token** | The native coin exists to pay for signing blocks, for bonding and for governance weight. Holding or trading it **is not the purpose of 9Chain** |
| **An exchange** | There is no trading product here, and this document quotes no price for anything |
| **A financial product** | The platform itself is infrastructure. Nowhere does this document state a gain from holding, or when one might be available |
| **An investment offer** | Every economic figure is labelled **PROPOSED** and settled by vote — see [*LOVE9 economics*](/en/love9-economics) |

> **In short:** an infrastructure project's positioning is only trustworthy when it can also **state what it is not**. The four lines in that last table are boundaries rather than modesty — and they hold across every remaining page of this document.

## 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 and has happened more than once; balances do not survive it, and they do not carry across to the official network either |
| **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** | Names of the named accounts stood up in genesis. The names are frozen by a hash, so their addresses can be computed **before** the accounts hold a single coin. Which allocation item maps to which account is design work **still being settled** |
| **The allocation table** | Five items — team · private sale · foundation · community · signing rewards — summing to the total supply. **NOT on the engraved list**: the current constitution engraves no number, so the whole table is labelled **PROPOSED** and the community can change it by vote |
| **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 3 — 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.

## Why 9Chain exists

One sentence, and this whole part exists to explain it:

> **Blockchain should not be a privilege of the few.**

In the early period of this technology, opening a blockchain network of your own demanded deep expertise, serious capital and a long road. Those three barriers stop nobody openly — they just quietly leave the right to build digital infrastructure in the hands of a few well-resourced organisations. 9Chain exists to take those barriers down, **one step at a time**.

### Three things, and the order between them means something

| | The work | Why it sits here |
|---|---|---|
| **1** | **Create** | Opening a chain of your own has to become as ordinary as opening a website. While creating is still hard, the two below have no room to happen |
| **2** | **Own** | The chain you create is **yours**: your rules, your governance, your economics. Not rented space on someone else's network, reclaimable whenever they choose |
| **3** | **Govern** | People should not merely **use** infrastructure that someone else builds and whose rules someone else changes. This is the hardest of the three, and it comes last because it only means anything once the first two are real |

That order is also the one most often reversed in the telling. A project that says *"the community governs"* before the community has anything to govern is selling a noun, not a mechanism.

### Who the people in this story are

An individual with an idea. A business serving customers and partners. A school recording learning and achievement. A community setting its own rules. A city or a country building infrastructure that fits its own conditions, instead of importing one wholesale from elsewhere.

That list is ordered by **who can use it soonest**, not by who matters most — and this document states its own uncomfortable half: **the individual heads the list but is furthest from the door**. The detail is in [*Nine roles*](/en/nine-roles).

```mermaid
flowchart TB
  R["Barriers of the early period<br/>deep expertise · serious capital · a long road"]
  R --> T["1 · CREATE<br/>opening a chain must become<br/>as ordinary as opening a website"]
  T --> S["2 · OWN<br/>rules, governance and economics<br/>belong to whoever created the chain"]
  S --> Q["3 · GOVERN<br/>those who depend on infrastructure<br/>must be able to change its rules"]
  Q --> D["The goal: no single person, company<br/>or interest group holds<br/>decisive control"]
  D -.->|"not reached — see *Removing the scaffolding*"| Q
```

*Figure 4 — Three pieces of work and the order they must come in. The dashed arrow is where this document is not allowed to draw a solid line: the goal has not been reached.*

### Three principles that come with it, and one sentence that lowers the claim

**Inherit, do not start from zero.** 9Chain does not open by denying what already works. It inherits proven technology and carries it forward; a new chain inherits the platform, the tooling and every improvement across the system, so **when one part moves forward the rest can follow**.

**Independent, but not isolated.** Each chain sets its own purpose and rules, but chains are not islands — they have to be able to communicate, share data and exchange value. ⚠️ This is a **goal, not a description of the present**: interoperability on both branches is an unpassed gate — see [*A1 and C1 side by side*](/en/a1-and-c1-side-by-side).

**There is no final version.** No release of this technology will be declared finished. A network people depend on has to keep learning, correct itself, and change alongside them.

And the sentence that lowers the claim, because without it everything above reads as advertising: **this part says where 9Chain is heading, not how far it has got.** Creating a chain on the public test network does work — a few minutes to stand up, and some technical familiarity. Closer to the goal than before, and **not there**.

> **In short:** an infrastructure project deserves to be measured by the distance between where it stands and where it says it is going, not by how well that destination is phrased. Throughout this document that distance is written out as **countable gates** — and [*Risks and open questions*](/en/risks-and-open-questions) is where it is told once more, without softening.

## Context and need

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,<br/>not tradable"]
  y-axis "billion USD" 0 --> 360
  bar [13, 25.4, 31.4, 33.5, 345]
```

*Figure 5 — 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<br/>forecast by 2028"] --> B{"Does the agent have<br/>its own auditable identity?"}
  B -- "21.9%" --> C["Yes"]
  B -- "the rest" --> D["Static API keys · 44%<br/>shared accounts · 35%"]
  D --> E["Nearly 80% of organisations<br/>cannot say what an agent did<br/>or who answers for it"]
```

*Figure 6 — 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<br/>private inside · controlled opening outward<br/>compliance beneath the application layer"]
  G --> A["Compliance becomes a property<br/>of the protocol"]
  G --> B["Privacy and interoperability<br/>coexist"]
  G --> C["A chain becomes something<br/>that can be produced"]
  A --> R["A chain drops from an infrastructure project<br/>to a reviewable declaration"]
  B --> R
  C --> R
```

*Figure 7 — 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 8 — 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 [*Platform architecture*](/en/platform-architecture), 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** |
| *[*Platform architecture*](/en/platform-architecture)* — 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 [*Platform architecture*](/en/platform-architecture).** 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<br/>of the nine"]
  T --> A["with the PAST<br/>how it treats<br/>what has already happened"]
  T --> B["with the PRESENT<br/>what it does for<br/>a person alive now"]
  T --> C["with the FUTURE<br/>what it leaves for<br/>those not yet here"]
```

*Figure 9 — 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 a promise: what is paid for contribution is **retroactive, for work already done**, and every item in the allocation table is **readable, and changeable by vote**.

**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 the allocation table states plainly:** there are items granted up front — the team, and a private sale round — and they are **locked for years**, sitting in the table to be read rather than hidden in an appendix. What is paid for **work already done** travels a different path: retroactively, by a public formula.

#### 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 — [*How to read this document*](/en/how-to-read-this-document) | 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 — [*Governance*](/en/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 — [*Platform architecture*](/en/platform-architecture) | 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 — [*Platform architecture*](/en/platform-architecture) | 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 — [*Who uses it, and who cannot yet*](/en/who-uses-it-and-who-cannot-yet) | 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 [*Risks and open questions*](/en/risks-and-open-questions), 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.

## The two-branch strategy

> **This is a strategic move, not a gamble** — and the distinction is worth making in the very first line. A gamble stakes something on what you do not know, and then waits. Building both foundations is the opposite: it **costs twice over precisely so that nothing has to be guessed**. It moves a decision that is close to irreversible — which engine carries this platform for years — off judgement and onto **a measurement anyone can reproduce**. The price is paid in money and time; what it buys is **not having to rely on luck**.

9Chain is being built **twice at the same time**, on two independent technical foundations, and the community will choose which foundation becomes the official network. The two branches are called **9Chain A1** and **9Chain C1**. Throughout this document they are always listed **in alphabetical order**, and that order **implies no ranking** — it is a rule of the project, not a courtesy.

### Why build the same thing twice

The choice of the engine underneath decides what the platform can do for years, and it is the kind of decision that is close to irreversible once people have built on top. There are two ways to make it: read the documentation of both technologies and argue, or **stand both up and measure**. The first is far cheaper and ends with whichever side argues better winning. The second costs twice as much and ends with a number anyone can reproduce.

The project chose the second. That is why two public test networks run side by side, each exposing **the same set of public surfaces**: an endpoint, an explorer, a test faucet, and a path to create a sovereign chain. A comparison only means something when both sides expose the same things.

### What this means for you

| If you are | What to do | What not to do |
|---|---|---|
| Reading to understand | read both, and take the alphabetical order exactly as it is | conclude that either branch is "the official one" — neither is |
| Building experimentally | try both; the public endpoints exist precisely for this | pick one branch and build something you need to keep on it |
| Planning to operate | read the technical documentation published by that branch itself | assume the two branches share one set of commands |

And one thing common to all three: **both are test networks**, so neither is a commitment to run for real. Balances there carry no value, and a test network can be rebuilt from scratch.

> **In short:** the two branches are not two competing products but **one question asked twice, so that it can be answered by measurement instead of by argument**. Until the measurements are published and the ballot opens, anyone telling you which branch will win is guessing — including people inside the project.

```mermaid
flowchart TB
  Q["ONE QUESTION<br/>which engine should carry this platform<br/>for years to come?"]
  Q --> A["Answer by ARGUMENT<br/>read both technologies' docs and debate"]
  Q --> B["Answer by MEASUREMENT<br/>stand both up and measure"]
  A --> A2["Cheap. Ends with<br/>whichever side argues better winning"]
  B --> B2["Twice the cost. Ends with<br/>a number anyone can reproduce"]
  B2 --> C["The project chose this path"]
```

*Figure 10 — The project's strategic move in one choice: pay twice over to **take luck out of** a decision that is close to irreversible.*

## A1 and C1 side by side

This page sets the two branches side by side by **architectural property**, not by score. Neither column is the winner: the two branches make different trade-offs, and which one fits depends on what you intend to build. Every cell comes from that branch's own source — **no cell is filled in on the other's behalf**.

| Property | 9Chain A1 | 9Chain C1 |
|---|---|---|
| Consensus family | Snowman — repeated random sampling of the signing set | CometBFT — every signer votes on every block |
| Block cadence | **On demand** — a block exists only when someone transacts | **Fixed cadence** — blocks are produced even when nothing happens |
| Chains in the network | **Many L1s, created on request** | **A single chain**, everything shares it |
| Transaction index | Not built in — a separate indexer has to be run | Built into the node |
| Transaction fees | An elastic fee market, sitting at its floor while the network is quiet | **No fee charged** — the minimum gas price is set to zero |
| On-chain voting | **None** — parameters change by operator action | A governance module: proposals, deposits, on-chain voting |
| Compliance in the protocol | **None at the protocol layer** — it sits outside the chain | Enforced in the protocol, with a gate contracts can call into |
| Cross-chain messaging | An internal messaging mechanism — **not switched on** | The standard module is compiled in, **with no working route** |

**Five places worth reading more closely than the rest**, because these are where a tidy table is easiest to read as something it does not say.

**One — the two block heights cannot be subtracted from one another.** A fixed cadence keeps block time predictable but grows the chain even while it sits idle. On-demand production costs nothing when idle — **but it takes away silence as a health signal**: a branch that has stalled and a branch that is merely quiet **look identical**. That is why no page of the project is allowed to raise an alarm when the on-demand branch has produced no new blocks.

**Two — "free" and "paid" are closer together than they look.** The branch that charges no fee has to hold back abuse some other way (a per-account gas quota), and **the zero floor is a setting on machines the project runs, not a guarantee of the protocol**. The other branch keeps an elastic fee market, which sits exactly at its floor while the network is quiet. So the real distance between them is far narrower than the word *free* suggests.

**Three — what protocol-level compliance buys, and what it costs.** Rules enforced below the contract layer apply to **every** transfer on the chain, and no contract can route around them. But they apply only to transfers **on the chain**, and whoever can upgrade the chain can still change the rules. The cost, stated plainly: **that branch is permissioned — someone decides who may transact.** The other branch pushes that decision up to whatever runs on top.

**Four — an on-chain vote, at this stage, records a decision more than it makes one.** A governance module leaves a public record of every parameter change, at the cost of taking days and needing a quorum. But on a test network where **most of the voting power sits with the project itself**, that ballot is mostly a set of minutes. Operator action takes effect immediately and **leaves no such record** — faster, and dimmer.

**Five — interoperability is an unpassed gate on both sides.** One branch has the standard module compiled in, but **a working route also needs a counterparty chain and someone running a relayer**; on the other, the equivalent mechanism is **not switched on**. Neither is moving assets in or out. Treat both as **unproven** here.

```mermaid
flowchart TB
  Q{"What do you need first?"}
  Q -->|"many separate chains,<br/>one per workload"| A["The branch that creates<br/>many L1s on request"]
  Q -->|"compliance rules<br/>contracts cannot skip"| C["The branch that enforces<br/>in the protocol"]
  Q -->|"a public record for<br/>every parameter change"| C
  Q -->|"absolute finality<br/>the moment the round closes"| C
  Q -->|"a signing set<br/>that scales up"| A
  A --> G["Both are test networks:<br/>neither has been load-tested,<br/>neither is a commitment to run for real"]
  C --> G
```

*Figure 11 — Read by need, the table above produces this shape. But every path leads to the same final box, and that box is the most important thing on this page.*

**One thing this table deliberately lacks: any operating figure.** No time to finality, no throughput, no count of machines signing. The reason is on [*Measurement and the ballot*](/en/measurement-and-the-ballot) — and it is not laziness but the fact that a frozen number would have both branches judged by a measurement nobody can reproduce.

> **In short:** the two columns above are **trade-offs, not scores** — and the line worth remembering is not in the table at all: **neither branch has been load-tested, and neither is a commitment to run for real**. Anyone who reads this table and immediately knows which side wins is almost certainly skipping the trade-off column of the side they just picked.

## Measurement and the ballot

The comparison between the two branches ends in **a community vote**, and the result decides which engine the official network is built on. This page is about what comes **before** the ballot — because a ballot with no measurements in front of it is a vote on sentiment, and the louder side wins.

### Why that table carries no operating figures

An operating figure frozen into a document makes **both branches judged by a measurement nobody can reproduce** — and that error does not announce itself, because the number still looks perfectly concrete. This is not hypothetical: when the project first measured both in parallel, the two branches produced two quantities **carrying the same name without the same meaning**. One branch produces blocks on a steady time interval; the other produces a block only when there is a transaction. Printing two *seconds per block* figures side by side would read as "this one is hundreds of times slower", when the truth is that **one of them does not produce empty blocks**.

The lesson is a rule, and it applies to every comparison from here on: **using the same measurement is not enough to compare — both sides must also be doing the same work.** Getting genuinely comparable numbers means putting the same load on both first, and that is a gate not yet passed.

So each branch's live figures belong to **that branch's own explorer**, not to this document.

### The vote, and what makes it mean anything

The comparison ends in **a community vote**, and the result decides which engine the official network is built on.

| Criterion | How it is measured |
|---|---|
| Degree of decentralisation | raise the number of machines signing until finality degrades, and record where it degrades |
| Finality | time from submitting a transaction until it can no longer be reversed, measured on a public endpoint |
| EVM maturity | run a standard contract suite and record which pass without modification |
| Wallet compatibility | add the network to a standard wallet and complete a transaction |
| Creating a chain | time from the creation command until the chain answers on its own endpoint |
| Interoperability | move an asset to another chain and read it back at the far end |
| Cost of operation | resources per chain, and what deploying a chain actually costs |

The right-hand column is the one that matters, and it is a guardrail rather than decoration: **a published score with no reproducible measurement behind it is not a score — it is an opinion with a number attached.** The community sets the weights between criteria, and **no branch scores itself**.

> ⚠️ **The vote is a gate that is NOT OPEN.** How the ballot works, who is eligible, and the window will be published **before** the first vote is cast. Until then **there is nothing to sign up for**, and no page of the project collects anything from you in exchange for a future share. Anyone inviting you to register to "hold your place in the vote" is offering something that does not exist.

### Why this sequence is harder than it looks

Three things have to be finished in order, and each is a gate: **produce the same load on both branches** → **publish the measurements with their method** → **open the ballot with a mechanism published in advance**. Skip the first and the two numbers cannot be compared; skip the second and the ballot has nothing to stand on; skip the third and nobody can recognise the result.

```mermaid
flowchart TB
  L["Produce the same load<br/>on both branches"] --> D["Publish measurements<br/>with a reproducible method"]
  D --> W["The community sets the weights<br/>between criteria"]
  W --> B["Open the ballot<br/>mechanism published BEFORE it opens"]
  B --> M["The official network<br/>on the chosen engine"]
  L -.->|"gate not passed"| L
  D -.->|"gate not passed"| D
  B -.->|"gate not passed"| B
```

*Figure 12 — Three unpassed gates stand between the testing stretch and the ballot. An arrow looping back on itself is how this document draws a gate that is not open.*

> **In short:** what decides the worth of this ballot is not how many people vote, but **whether a reproducible measurement stands behind each score**. Until those three gates are passed, every statement about which branch is better — including from inside the project — is an opinion, not a result.

## Platform 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 and need*](/en/context-and-need).

| 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<br/>create the private space"]
  P --> G["Raise<br/>generate keys into the key store<br/>assemble genesis, then verify"]
  G --> D["Deploy<br/>validators · RPC · faucet · explorer"]
  D --> S["Sync<br/>wait for quorum to produce blocks"]
  S --> H["Healthy<br/>re-checked on a cycle"]
  D -.-> F["Failed<br/>diagnose, then retry with backoff"]
  S -.-> F
  F -.-> P
  H --> T["Teardown<br/>clean up resources"]
```

*Figure 13 — 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<br/>the platform"]
    A2["RPC · faucet<br/>explorer"]
  end
  subgraph NB["Private space of chain B"]
    B1["Validators run by<br/>the platform"]
  end
  Q["Resource quotas<br/>network policy<br/>least privilege"] --- NT
  Q --- NB
  X["CUSTOMER node<br/>running outside"] -.->|"genesis · peer list · keys<br/>generated by the operator"| A1
  Y["AUDIT node<br/>running outside"] -.-> A1
```

*Figure 14 — 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.

## 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 | Inherit the technology, not the balances | A new chain **does not start from nothing**: it inherits proven technology, the tooling and every improvement across the system — when one part moves forward the rest can follow. But **balances are not inherited**: the official network is born from a new genesis, and balances on a test network do not carry across |

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?<br/>Interoperability needed?<br/>Auditable immutability needed?"}
  Q -- "Missing one of the three" --> DB["The right answer is<br/>a database.<br/>9Chain REFUSES"]
  Q -- "All three" --> OK["Accept"]
  OK --> N1["Refuses token-economic security<br/>for private customers"]
  OK --> N2["Refuses to issue assets<br/>on a customer's behalf"]
  OK --> N3["Refuses to let one party hold<br/>more than a third of voting power"]
  OK --> N4["Refuses to touch the price"]
```

*Figure 15 — 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 [*Risks and open questions*](/en/risks-and-open-questions), 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.**

## 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<br/>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<br/>recognised by many chains"| C1
  M -.-> C2
  M -.-> C3
  C1 <-->|"assets pass a gate"| C2
```

*Figure 16 — 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 [*Risks and open questions*](/en/risks-and-open-questions). 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**.

## Sovereign chains

**Sovereign chains are the core use of 9Chain** — what the whole platform exists to do. A sovereign chain is not a contract deployed onto a shared network: it is a chain of its own, with its own genesis, its own signing set and its own rules, operated with exactly the same tooling as every other chain on the platform.

| A sovereign chain has | What that means |
|---|---|
| **Its own signing set** | You decide who validates. A chain can be open, or limited to a named group of operators |
| **Its own access policy** | Who may transact, deploy or hold — enforced by **the chain itself**, not by an application sitting on top |
| **Its own economics** | Each chain carries its own gas configuration, so running it does not depend on another chain's fee market |
| **Shared tooling** | Explorer, endpoints and operations work the same on every chain — one way of working, many chains |

> 🔴 **And this has to be said first, before anything else in this part: only ONE of the two branches can create chains on request.** The other is **a single chain** and cannot produce more. That means **the flagship capability of the whole platform runs on only one of the two foundations** — and which foundation wins the vote for the official network is still open. If the branch that cannot create chains wins, this capability has to be rebuilt on that foundation. That is a real risk, it belongs in [*Risks and open questions*](/en/risks-and-open-questions), and this document states it at the top of the part rather than the bottom.

⚠️ One more boundary, smaller but easily missed: **self-service is not open**. During this phase chains are provisioned by the team, and the write side of the console is sealed at the edge **on purpose**. There is no button here that pretends otherwise. The three gates that must be passed before chain creation becomes genuine self-service are set out below.

Three parts, one path.

```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 17 — 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.

## What a chain can hold

A chain on its own is only a ledger. What makes it useful is what can be assembled on top — and the brief for a platform is that those pieces **arrive as parts of the platform**, rather than every project rebuilding them from scratch.

The table below uses the same four labels as [*How to read this document*](/en/how-to-read-this-document). Read the label column before the description column — read it the other way round and the whole table sounds like a list of features already shipped.

| Component | What it is on a chain | Label |
|---|---|---|
| **Identity** | Who is who, carried across everything built on the network | **GATE** — the *one identity* half still has to be proved |
| **Wallets** | Standard wallets can hold and sign, with no special client | **RUNNING** |
| **Smart contracts** | Standard contracts, using tooling that already exists | **RUNNING** |
| **Digital assets** | Issued and moved under rules the chain itself enforces | **RUNNING** on the branch with protocol-level compliance |
| **Payments** | Settled on the chain, not beside it | **RUNNING** |
| **Explorer** | Every chain readable by anyone, without asking the operator | **RUNNING** |
| **Operations** | Signers, upgrades and monitoring through one surface | **RUNNING** |
| **Your own rules** | Purpose, economics and policy set per chain | **RUNNING** on the branch that can create many chains |
| **Governance** | Proposing and voting as **a function of the chain**, not a forum thread | **RUNNING** on one branch, **LEFT BLANK** on the other |
| **Contribution records** | Effort and participation recorded where they cannot be quietly rewritten | **GATE** — needs a recognition mechanism settled by vote |
| **Data storage** | Records living with the chain that vouches for them | **GATE** |
| **Interoperability** | Messages and value moving between chains in the network | **GATE** — no branch has a working route |

### The most important sentence on this page is in the right-hand column

Count the label column and the real shape appears at once: **what already runs is what any EVM chain can do**, while **what would make 9Chain different — shared identity, contribution records, interoperability — sits almost entirely under the GATE label.** That is not an embarrassing admission; it is the correct map of an infrastructure project still in its testing stretch. But it has to be said here, because a twelve-item list **without labels** reads as twelve things already finished.

```mermaid
flowchart TB
  C["ONE CHAIN<br/>a ledger standing alone"]
  C --> A["Already running<br/>wallets · contracts · assets · payments<br/>explorer · operations"]
  C --> B["Gates not passed<br/>shared identity<br/>contribution records · interoperability"]
  A --> U["Useful immediately,<br/>but not yet different from an ordinary EVM chain"]
  B --> V["Where 9Chain intends to differ<br/>— and what remains to be proved"]
```

*Figure 18 — The twelve components split into two columns by label. The right-hand column is where the project's actual problem sits.*

### Four steps from an idea to a chain that answers

| # | Step | Worth remembering |
|---|---|---|
| **1** | **Define the chain** | Chain identity, gas configuration, the initial allocation — written **before** anything runs, because genesis cannot be edited afterwards |
| **2** | **Create it** | One command, or one declaration. The platform builds the chain and registers it with the network |
| **3** | **Connect to it** | The chain comes up on its own endpoint; standard tooling connects as it would to any EVM chain |
| **4** | **Operate it** | Signers, upgrades and monitoring run through the same operating surface as everything else |

**Steps two and four are where the two branches genuinely differ** — one uses a chain factory driven from the platform chain itself, the other an external controller. Both were built to the same brief, and that is precisely what makes them comparable.

This document **does not copy the commands** for those four steps: commands change with each release, and **the two branches have two different command sets** — copying them guarantees being wrong about one. The original lives on each branch's own site.

> **In short:** the list of what a chain can hold is **a list of the brief, not a list of what has been delivered**. The way to read it correctly is to count the label column — and once counted, the most interesting part of 9Chain is still on the far side of a gate.

## Who uses it, and who cannot yet

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<br/>2 · Fintechs and tokenisation firms<br/>6 · Auditors<br/>7 · Regulators"]
  N2 -.- P2["3 · Multi-party consortia<br/>4 · Validator operators<br/>5 · Customer-side operations teams"]
  N3 -.- P3["8 · Individuals"]
  N4 -.- P4["9 · AI agents<br/>and EVERY other audience<br/>once real value is touched"]
```

*Figure 19 — 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 and need*](/en/context-and-need): 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.

## Compliance and safety

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<br/>permitted?"}
  L1 -- "no" --> R1["Reject · emit event"]
  L1 -- "yes" --> L2{"Layer 2 · is the asset<br/>flow valid?"}
  L2 -- "no" --> R2["Reject · emit event"]
  L2 -- "yes" --> L3{"Layer 3 · permitted to<br/>deploy contracts?"}
  L3 -- "no" --> R3["Reject · emit event"]
  L3 -- "yes" --> EX["Execute"]
  EX --> L5["Layer 5 · the contract asks<br/>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**.

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 [*Platform architecture*](/en/platform-architecture), 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<br/>that layer 1 cannot see"]
```

*Figure 22 — 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.

## 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<br/>differing by exactly one field<br/>in the declaration"] --> M1["Fully platform-run"]
  CB --> M2["Mixed · default<br/>always an outside node"]
  CB --> M3["Multi-party"]
```

*Figure 23 — 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.

## 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 | Each branch's own site: [a1.9chain.org](https://a1.9chain.org/) · [c1.9chain.org](https://c1.9chain.org/) | Connecting, running a node, endpoints — each branch publishes its own set |
| 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** | [*Governance*](/en/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 | [*Governance*](/en/governance), under *Governance and who holds the keys* |
| Distributing the signing set across independent failure domains | **Gate not passed**, with a countable threshold | [*Platform architecture*](/en/platform-architecture), 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 24 — 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, balances of an abandoned build do not flow into the next one, and **balances on a test network do not carry across to the official network** — that is settled, not a possibility.

**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.

## LOVE9 economics

> **Label: PROPOSED** for every number on this page, **without exception** — the current constitution engraves no number at all (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 [*How to read this document*](/en/how-to-read-this-document).

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.

### 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.**

```mermaid
flowchart TB
  H["INFRASTRUCTURE LAYER<br/>LOVE9 — bonding, governance, release from the endowment"]
  N["FUEL LAYER<br/>nominal gas token of a customer chain<br/>non-transferable"]
  T["ASSET LAYER<br/>tokens created by an issuer<br/>through the compliance gate"]
  H --- N --- T
  X["COMMUNITY POINTS<br/>NOT one of the three layers above"]
  X -.->|"not on chain · cannot bond<br/>cannot vote · conversion LEFT BLANK"| H
```

*Figure 25 — Three token layers, and one thing deliberately placed outside all three. The dashed path is the most easily confused point in this entire document.*

> **In short:** these three token layers **must never be mixed**, and the thing outside all three — community points — is where misuse is easiest. Anyone promising you a fixed rate from points into tokens is putting words in the project's mouth: **nobody has decided that.**

## The allocation table

### The proposed allocation

The proposed total supply is **9,000,000,000 LOVE9** — nine billion. That figure is a **nominal ceiling**, not the amount that will circulate. The table below is the proposed allocation, and it applies to both technical branches of the project.

| Item | Share | LOVE9 | Form |
|---|---:|---:|---|
| Team | 9% | 810,000,000 | locked **four years** — see the warning below the table |
| Private sale | 9% | 810,000,000 | locked **two years** — see the warning below the table |
| Foundation | 12% | 1,080,000,000 | liquid; holds the self-bond of the genesis validators |
| Community | 30% | 2,700,000,000 | a small part sits in the faucet, the rest locked two years |
| Signing rewards | 40% | 3,600,000,000 | **not granted at genesis** — minted gradually over time |

**Six things to read alongside the table, because the table alone is easy to misread.**

**One — a ceiling is not circulation.** Genesis issues only **six tenths** of the total supply; the remaining four tenths sit in a minting fund and leave it only when there is someone signing blocks to pay. At the bonded levels a young network usually has, real minting is very slow — so the amount **actually in circulation will sit near what genesis issued**, not near the nine billion ceiling. Anyone using nine billion as a denominator to compute anything is computing the wrong thing.

**Two — just after genesis, the transferable part is thin, and it is concentrated.** Most of the table is locked for years, so what can actually move in the early days is a small slice of the issued amount — and within that slice, **more than nine tenths belongs to a single item, the Foundation**. This is the number outsiders will add up on day one, so this document adds it up first rather than waiting to be asked.

**Three — the genesis validators' self-bond sits at its own address.** It comes out of the Foundation item but is not mixed into it. The reason is a safety rule worth remembering: mixed together, one change to the Foundation's lock schedule would **silently change the voting weight** of the people signing blocks.

**Four — the genesis validators' terms are staggered.** None of them expires on the same day as another. If they all expired at once the network would stop **with no error reported anywhere** — the hardest kind of silent failure to diagnose, and the way to prevent it is to stagger the terms while genesis is still being drafted.

**Five — the private sale item is different in kind from the other four.** It is the **only item in the table with fiat money flowing in**, and that pulls in a chain of questions no allocation table can answer: sold to whom, under which jurisdiction, through what identity process, along what money path, and where that sale counts as a security. **Legal review of that chain of questions is a mandatory gate, and that gate has not been passed.** This document states the constraint rather than leaving someone else to discover it later.

**Six — the whole table is labelled PROPOSED.** It replaces an earlier allocation, and anchored versions of this very document follow the older one. That is why [*How to read this document*](/en/how-to-read-this-document) tells you to read the latest version and hash it yourself, rather than trusting a copy circulating somewhere.

### Nine billion, and why nine billion

The figure of nine billion was not chosen to be round. It was chosen so the total supply is **sized to the number of people on Earth**:

> **One LOVE9 for every human being on Earth.**

That sentence is about the **size of the total supply**, and only about its size. It is **not an individual entitlement** — this document says so plainly, because this is exactly the place where a memorable line gets read as a promise. The share directed at people is the Community item, **three tenths** rather than the whole; divided evenly among the people alive today, the figure per person is **well under one**. How it would be divided has not been designed, and will be decided by a vote.

| Sentence that works | Sentence that does not |
|---|---|
| *One LOVE9 for every human being on Earth* | *Every person will receive one LOVE9* |
| *The total supply is sized to the number of people on Earth* | *You will get one LOVE9* |
| *Nine billion LOVE9 for nine billion people* | *Sign up to claim your share* |

The real population is smaller than nine billion, so the ceiling is **more than humanity, not less** — and that is the half that makes the sentence hold. If someone presses the point, answer with that half, not with a per-person figure.

> ⚠️ **An earlier version of this document anchored the total supply to nine squared** and read it as nine coins per person. That figure has been replaced, and the nine-squared anchor goes with it. Anywhere in the project's documents still saying nine squared is **a leftover not yet cleaned up**, not another way of saying the same number.

```mermaid
pie showData
  title Proposed allocation (%)
  "Signing rewards" : 40
  "Community" : 30
  "Foundation" : 12
  "Team" : 9
  "Private sale" : 9
```

*Figure 26 — The five items of the proposed allocation. The two smallest — team and private sale — are the two granted up front, and both are locked for years.*

### 🔴 Where the locks are — and what the chain does NOT enforce

The word *locked* in the last column above is **a stated intention, not a rule the chain enforces** — and it is the genesis text itself that says so, not this page inferring it. From the engraved `pool_allocation` document: *"no vesting account, lock or protocol rule holds them, and none can be added to this genesis after block 1. The locks are to be implemented as smart contracts after launch."*

Three consequences have to be read alongside it, because without them the table reads as something it is not:

| What the table suggests | What the chain actually does |
|---|---|
| The two up-front items are **locked** for years | No vesting account and no protocol rule holds them. The locks are to be **contracts deployed after launch** |
| The endowment opens **0.09% per day** | **No module performs that in this genesis.** It needs an upgrade that governance must enable |
| Each item's balance equals its percentage | The **foundation item takes the remainder**: it is lower than its headline share by **exactly** the operating capital advanced at genesis |

What is worth crediting is that the engraved text **declares all three of these itself**, rather than describing them as rules already in force. This document reproduces that level of claim and does not raise it.


> **In short:** this allocation table is labelled **PROPOSED**, and the way to check it is not to trust the table — it is to **open the genesis file of the running period and count**. The two items granted up front, team and private sale, sit in the table itself rather than in an appendix; and the private sale item is the only one that drags in a **legal gate that has not been passed**.

## The endowment, the rhythm and the fees

### The endowment, the release rhythm, and the fee path

| Parameter | Proposal | Note |
|---|---|---|
| Total supply | nine billion LOVE9 | a nominal ceiling; outside the reward minting fund nothing further is minted, and once the network charges fees part of each fee is burned |
| Issued at genesis | six tenths of the total supply | the remaining four tenths sit in the minting fund |
| Release rhythm | 0.09% of the unreleased remainder, **each day** | the base is the **endowment's remaining balance**, not a fixed fraction of total supply |
| Half-life | roughly 770 days | the flow shrinks steadily but never reaches zero |
| Fee split | **9% back to the endowment · 9% burned · 82% to the signers** | a commitment paired with a gate, not a cash flow already running: the network charges **no fees**, so there are no fees to split. Turning fees on is permitted only after the 9% split mechanism is on chain — that ordering is what keeps the commitment from being talk |

```mermaid
flowchart TB
  T["PROPOSED TOTAL SUPPLY<br/>nine billion — a nominal ceiling"]
  T --> G["Issued at genesis<br/>six tenths"]
  T --> M["Minting fund<br/>four tenths"]
  G --> N1["Community and Foundation<br/>the part that goes outward"]
  G --> N2["Team and private sale<br/>locked for years"]
  M -->|"minted only when blocks are signed"| K["Rewards for signers"]
  N1 --> W["Recipient wallets"]
  K --> W
  W -.->|"9% of fees, once the network charges them"| R["Back to the endowment"]
  W -.->|"9% of fees BURNED"| B0["Out of circulation<br/>permanently"]
```

*Figure 27 — Nine billion splits into two paths: the part issued at genesis and the minting fund. The two dashed paths are the fee share returning to the endowment and the share burned, and they only flow once the network charges fees.*

The items in the table sit in **named accounts**, and their names are frozen by a hash engraved in genesis — so an outsider can **compute the address of an item before that account holds a single coin**. It sounds like bookkeeping, but it is a safety rule: an address that does not yet exist and is not on a block list will swallow permanently whatever someone sends to it by mistake, so standing the empty wallets up from the start is the cheapest way to close that trap.

> ⚠️ **And here a five-item table meets a hard technical constraint.** A named account can only be added **when the chain is born**, never afterwards. The allocation table has **five** items, so genesis must carry **five** named accounts. Whether it carries all five is a **gate**, and it has to be passed **before** the birth of the chain — it is not a tidy-up job for later.

Whatever has been released but not yet claimed stays as a buffer, and **never raises any single day's release ceiling**. The consequence is that nobody is owed anything, and nobody is promised a figure 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 allocation table says *how much* is directed at people, but not *who* receives it or *how* — and it deliberately does not say. The only two constraints settled are that it must be **measurable on chain** and **settled by vote**; the minimal constitution leaves the rest to the community. What does not change is the order: the items have named accounts from genesis, but the part directed at people has no way out yet, 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.

> **In short:** the release formula is the part that is **engraved**, while **how a human being receives their share is a LEFT BLANK box** — and that box is blank by design, not by oversight. The endowment cannot open until a receiving mechanism has passed a vote; that is the order, and it does not reverse.

## 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<br/>and the blocked attempt
```

*Figure 28 — 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<br/>holding separately"]
  end
  G1 --> OP["System administration actions"]
  G2 --> CP["Compliance approval actions"]
  G3 --> TR["Touching the value store"]
  X["One signature<br/>is NEVER enough"] -.-> OP
  X -.-> CP
  X -.-> TR
```

*Figure 29 — 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 [*How to read this document*](/en/how-to-read-this-document) 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**.

## 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<br/>HUMAN · DELEGATION<br/>not a role · not paid"]
  A --> V["VERITAS<br/>build and protect the truth about people"]
  A --> L["LIBERTAS<br/>keep it un-switch-off-able"]
  A --> E["AETERNUM<br/>build and steer the future"]
  V --> V1["1 Sponsor<br/>2 Gate<br/>3 Juror"]
  L --> L1["4 Signer<br/>5 Witness<br/>6 Connector"]
  E --> E1["7 Builder<br/>8 Chain holder<br/>9 Citizen"]
```

*Figure 30 — 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 a principle meets an allocation table. The table **does** carry an item for the team, and that item is locked for four years. But what is paid for **building** does not travel through it: it is paid retroactively for work done, competing in the open like any other builder. Two different money paths, and this document keeps them apart rather than merging them into one.

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, and 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.

## 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 [*Risks and open questions*](/en/risks-and-open-questions). 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<br/>read · criticise · verify"]
  D1 --> G1{"Gate: participation artefacts"}
  G1 --> D2["Accompany<br/>run an independent node"]
  D1 --> G2{"Gate: public code repository"}
  G2 --> D3["Build<br/>code · docs · translation"]
  D2 --> G3{"Gate: voting power leaves<br/>the project's hands"}
  D3 --> G3
  G3 --> D4["Govern<br/>propose · vote"]
  D4 --> O["Own together<br/>one human · one share · one vote"]
```

*Figure 31 — 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 the official network — through the testing stretch and the vote that chooses the branch — 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**.

## What is engraved permanently

Almost every number in this document can be changed by vote. This part is about the part that **cannot** — and the most notable thing about it is how **unusually short** it is.

| | What | Changeable |
|---|---|---|
| **ENGRAVED** | The three memorial blocks that open the ledger | ❌ No, from the birth of the official network onward |
| **ENGRAVED** | One meta-rule: *everything else belongs to the community deciding together* | ❌ No — and it is what guarantees everything else does |
| Everything else | total supply · allocation · the nine roles · how it is received · the names of the factors | ✅ Yes, by public on-chain vote |

A constitution holding only **three blocks and one rule** is likely the shortest in the industry. That is a choice with a price, and this document states both sides: in exchange for the comfort of a line nobody can edit, the project takes on 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**.

```mermaid
flowchart TB
  K["ENGRAVED — cannot be changed"]
  K --> B1["Block 1<br/>the opening sentence, in its original language"]
  K --> B2["Block Adam<br/>the first human being"]
  K --> B3["Block Eva<br/>the second human being, and the first *we*"]
  K --> L["ONE META-RULE<br/>everything else belongs to the community deciding together"]
  L --> M["Total supply · allocation · the nine roles<br/>how it is received · the names of the factors"]
  M -.->|"changeable by public vote"| M
```

*Figure 32 — Three blocks and one rule. The meta-rule is what keeps every remaining box changeable — it engraves the right to change, not a number.*

### 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 **every time a network is born**, and **only the engraving on the official network is permanent** — every one on a test network is a rehearsal. The project is building **two technical branches in parallel** and the official network will follow the branch the community chooses, so the final engraving sits on that branch; see [*The two-branch strategy*](/en/the-two-branch-strategy).

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.

### The nine documents engraved in the first block

The part above says what the constitution **intends** to engrave. This part says what the chain **has** engraved — and, more usefully, how you check that yourself without trusting this document.

In the first block, the chain writes **nine documents**. Each has a name and a body; the chain stores both, and the hash of the body is something anyone can recompute.

| Document name | Content | Changes when the network is rebuilt? |
|---|---|---|
| `genesis_inscription` | The opening sentence, **in ancient Hebrew** — seven words | **No** |
| `dedication` | The dedication for Block Adam — *the first human being* | **No** |
| `dedication_eva` | The dedication for Block Eva — *the second human being, and the first "we"* | **No** |
| `love_paper_en` | The full constitution, version **V0.0** | **No** |
| `love_paper_version` | The constitution's version number | **No** |
| `love_paper_prev_sha256` | Hash of the previous constitution — the lineage link | **No** |
| `pool_allocation` | The allocation and each item's balance at the first block | **YES** |
| `genesis_operating_budget` | Operating capital and every wallet funded | **YES** |
| `validator_access` | The rules for entering and leaving the signing set | **YES** |

**That split down the middle is the most worthwhile thing on this page.** The first six are the **constitution**: they do not change by a single character across rebuilds, so their hashes are as durable as the text itself. The last three are **the economic record of one specific period**: each time the network is rebuilt the figures are engraved again, so **their hashes change with it**. That is why this document does not print those three: publishing a number that will change within days only gives a reader something to check against wrongly.

### Check it yourself: three steps, no permission needed

| Step | Do this | Correct result |
|---|---|---|
| **1** | Ask the chain for the document list through the branch's public endpoint | The nine names in the table above |
| **2** | Take the body, **normalise to NFC**, encode as UTF-8, **add no trailing newline** | a byte string |
| **3** | Take the SHA-256 of those bytes | matches the hash the chain states |

⚠️ **Step 2 is the only place this goes wrong, and it goes wrong silently.** One full stop, one byte-order mark, or one extra blank line at the end produces **an entirely different hash** — not slightly different, completely different. If your result disagrees, suspect your own normalisation before you suspect the chain.

The three economic documents' hashes are read straight from the chain of the running period. For the six constitutional documents, this page prints the hashes here so you can check without trusting any third party:

```text
genesis_inscription      7e89adee122f26790f748375e3ea6769cb386b20d695206c2e2c65e57e0f9615
dedication               19f90a317851933e88fb288949a44b18f87103b2d7947b80d557f05d425a236c
dedication_eva           747ebe59ab6a152e962a2c3f215f46a8a30a82265210cb4fd6ee4bd31ffc97df
love_paper_en            8cee72ba268f4f5fb0a55d77dd52313bcdfb8ff3afed3165686140e2a0339835
love_paper_version       8aed642bf5118b9d3c859bd4be35ecac75b6e873cce34e7b6f554b06f75550d7
love_paper_prev_sha256   cb52483fe9cd7804e0b3447d3ab3bf4b3c0cbeb21c1f5e3f7ee1ed139c302426
```

### Four things easily misread, said plainly once

**One — only the English version is engraved.** The Vietnamese version of the constitution exists for cross-checking and **has no force on the chain**. Where the two read differently, the engraved one is correct.

**Two — Block Adam and Block Eva do not exist yet.** What sits on the chain is their **dedication text**, engraved as documents in the first block. The blocks themselves are defined by time — the first block past the mark on **09/09/2026** in Jerusalem time, and the block immediately after it — so they appear only when that moment arrives.

**Three — no document can be added after the first block.** The module holding these documents **has no command to add one**; the list closes the moment the chain is born. Engraving another text means waiting for **the next rebuild**, with the text finished before that hour. This is a hard technical constraint, not a negotiable choice.

**Four — the number of documents is a settled figure, and one is missing from it.** The project has decided to engrave **an English translation of the opening sentence**, so that it can be read without knowing Hebrew. That text **has not been produced**, so the list stands at nine rather than ten. The translation chosen is one in the **public domain** — a detail that sounds small but is mandatory: permanently engraving a text still under copyright into a public chain **cannot be undone**.

> **In short:** this constitution engraves no number. What is permanently engraved is three memorial blocks and one rule; everything else — total supply, the allocation, how it is received — is decided by the community together. And what separates that from a promise is that **you can check it in the three steps above**: read the nine documents, rehash the six durable ones, and reconcile the other three against the chain of the running period. Any document calling one of the project's numbers *unchangeable forever* — including this one, in versions anchored earlier — misstates the current constitution.

## 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 nine billion, 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<br/>of the nine"] --> B["Point 9<br/>the name"]
  Y --> A["Points 1 … 8<br/>LEFT BLANK"]
  A -.-> T["Eight points can be filled<br/>⇒ the factor stands"]
  A -.-> F["They cannot<br/>⇒ not yet an advantage"]
```

*Figure 33 — 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<br/>submission"] -.-> O["Seventy-two boxes<br/>still LEFT BLANK"]
  N --> P["To be refuted<br/>point by point"]
  O --> Q["Your version<br/>may be shorter"]
  Q --> R["Refuting a factor<br/>⇒ still a correct result"]
```

*Figure 34 — 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.

## The roadmap

### The order of the work, and only one step that engraves

9Chain's roadmap publishes an **order**, and deliberately publishes **no dates**. The project states the reason plainly: the order is a commitment it can keep, and dates at this stage are not — so posting a calendar would only be posting something that has to be withdrawn.

| Stage | The work | Does it engrave anything permanently |
|---|---|---|
| **Now** | **Two technical branches running publicly side by side**, each with its own explorer, endpoint and test faucet | **No** |
| **Next** | **Publish the measurements** on both branches — each result with its method, so outsiders can reproduce it and refute it with evidence | **No** |
| **Then** | **A community vote** chooses the branch the official network will follow | **No — but this is when the window closes** |
| **After** | **The official network** is born on the chosen engine | **Yes — and only here** |
| **Finally** | **Full decentralisation** | **Nothing further engraved — this is when the scaffolding comes down** |

Three points in that order deserve more attention than the rest.

**Measurement comes before the ballot.** A vote choosing a technical direction with no measurements in front of it is a vote on sentiment, and the louder side wins. The constraint that comes with it is itself a gate: **a published score with no reproducible measurement behind it is not a score** — it is an opinion with a number attached. No branch scores itself.

**The voting mechanism must exist before voting opens.** How the ballot works, who is eligible, and the window — all three have to be published **before** the first vote is cast. Until they are, **there is nothing to sign up for**, and anyone inviting you to register to "hold your place in the vote" is offering something that does not exist.

**Full decentralisation comes after launch day.** This is where this roadmap differs from most: **the day the official network runs is not the finish line.** At the moment of engraving, control is still more concentrated than it ought to be — saying otherwise would be a lie. Full decentralisation is therefore a stage that comes **afterwards**, and it is the only stage that does not end with a launch event: it is done when **no task requires a governance key any more**, which is a countable number (see *The commitment to remove the scaffolding* in [*Governance*](/en/governance)).

*Which stage the project stands at is live data, so it is not written here — how to read it for yourself is in [*Check the network yourself*](/en/check-the-network-yourself).*

This is the most important thing to carry into the rest of the document: **not one line of it is engraved before the official network is born.** The testing stretch exists precisely so that what is written here gets tried, argued with, and corrected — by community vote, with **almost no clause off limits**. The single exception is the core reduced to its minimum: the **three memorial blocks** that open the ledger, and the rule that *everything else is decided by the community together* (see [*LOVE9 economics*](/en/love9-economics)).

#### The official network starts from a blank page

An earlier version of this document said the official network was **the sum of the test periods** — their history preserved and attached to the shared ledger. **That has been reversed, and this is where the reversal is recorded.** The current position: the official network is born from **a new genesis**, not as the continuation of a test network, and **balances on a test network do not carry across**.

The reason is worth more than the conclusion. A ledger that admits the history of networks rebuilt several times has to answer the question *which of those was the real one* — and there is no answer to that question that does not require **someone to choose on everyone's behalf**. Starting from a blank page sounds more ungrateful, but it is the only option that **needs no such person**.

> ⚠️ **What you do on a test network is not lost, but it does not become a balance either.** What is settled: **balances do not carry across**. What is **not** settled: how contribution during the testing stretch will be recognised — that is marked **LEFT BLANK**, and the community votes on it. Anyone telling you that running a test network 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 network can be wiped and rebuilt from scratch** — that is exactly what the testing stretch exists to do, and it has happened more than once. 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. And that boundary has no exception standing behind it: **no inheritance promise catches it**.

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.

```mermaid
flowchart TB
  A["NOW<br/>two branches running publicly side by side"] --> B["NEXT<br/>publish the measurements<br/>with a reproducible method"]
  B --> C["THEN<br/>the vote that chooses the branch"]
  C --> D["AFTER<br/>the official network on the chosen engine<br/>— the ONLY place that engraves"]
  D --> E["FINALLY<br/>full decentralisation<br/>— the scaffolding comes down"]
  D -.->|"a new genesis, balances NOT inherited"| D
```

*Figure 35 — The order of the work, deliberately without dates. Only one stage engraves, and the final stage comes AFTER the one that engraves.*

> **In short:** this roadmap publishes an **order**, not **dates**, and at this stage that is the only honest thing to publish — an order can be kept, a date cannot yet. The two points worth remembering: **measurement comes before the ballot**, and **full decentralisation comes after launch day**. Any roadmap placing "decentralisation" before launch day is selling something that does not exist.

## Networks and endpoints

The project runs **two public test networks side by side**, and each publishes **the same set of public surfaces**: an endpoint to point a wallet or tool at, an explorer to read the chain, a test faucet, and a path to create a sovereign chain. A comparison only means something when both sides expose the same things — which is why this list is identical in both columns.

| Surface | What it is for | Where |
|---|---|---|
| **The project's shared page** | The way in, and where what is settled and unsettled is published | [9chain.org](https://9chain.org) |
| **Each branch's own site** | Technical documentation, faucet, chain-creation tooling — **each branch publishes its own set** | [a1.9chain.org](https://a1.9chain.org/) · [c1.9chain.org](https://c1.9chain.org/) |
| **The shared explorer** | Read both networks in one place, and see where they differ | [9scan.org](https://9scan.org) |
| **Each branch's explorer** | Blocks, transactions and account state for that branch alone | [a1.9scan.org](https://a1.9scan.org) · [c1.9scan.org](https://c1.9scan.org) |
| **This document** | Why the system is designed as it is, and what is left blank | you are reading it |

> ⚠️ **Two things have to be said alongside that list.** First: **both networks are operated by the project itself**, so every page describing them — the shared explorer included — is **the operator's own account, not an independent review**. Second: **specific addresses can change, and one has already changed meaning** — an address carrying *testnet* in its name now serves a chain quite different from the one that name used to point at. So take addresses **from the branch's own site**, and always check against the chain itself: read the network identity and the first block's moment, and do not trust the name.

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<br/>status · signers · genesis"]
  You --> E["EVM interface<br/>wallets · contracts"]
  You --> Q["Query interface<br/>parameters in force"]
  C --> T{"Two answers must agree:<br/>which network does the address claim?<br/>when was the first block born?"}
  T --> OK["They agree: read on"]
  T -.-> NO["They differ: believe no number"]
```

*Figure 36 — Every way in passes the same two-question check.*

**The naming rule, and why part of its value is gone.** The project once set a rule: the public address of a test period **carries the word *testnet*** in its name, the official network would have a name of its own, and **an address that has meant one thing never comes to mean another**. The intent was sound, and this document used to tell you to rely on it. **What has to be said plainly: that rule has already been broken once by the project itself** — an address carrying *testnet* in its name now serves a different chain from the one that name used to point at, with a different identity and a different first block. So the reading has changed: still ask **two** questions — *which network does this address say it is* and *when was its first block born* — but when the two disagree, **believe the second**. A name is something people assign; the first block is something the chain states about itself and cannot restate.

**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.

## 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 set a rule that a test period's public address **carries the word *testnet*** in its name, and the official network would have a name of its own — **an address that has meant one thing never comes to mean another**. But that rule **has already been broken once by the project itself**: an address carrying *testnet* now serves a different chain from the one that name used to point at. So this is a **secondary signal, not evidence**. Ask both questions — *which network does this address say it is*, and *when was its first block born* — and when the two disagree, **believe the second**: a name is something people assign, while the first block is something the chain states about itself and cannot restate.

### Which period you are looking at, and which level it is at

Two scales, not to be confused. **Roadmap stage** (see [*How to read this document*](/en/how-to-read-this-document)) says where the project stands on its release roadmap: the two-branch testing stretch, then publishing the measurements, then the vote, then the official network. **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**. Rebuilding a test network 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<br/>network rebuilt<br/>infrastructure changed"| N1
```

*Figure 37 — 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.

## Risks and open questions

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 [*How to read this document*](/en/how-to-read-this-document): 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<br/>and torn down"]
    P2["Consensus threshold<br/>matches theory"]
    P3["Separation of key custody<br/>is enforced"]
    P4["Disaster recovery<br/>works"]
  end
  subgraph L["What the evidence CANNOT say"]
    L1["Does not replace<br/>an independent audit"]
    L2["Small scale does not<br/>imply large scale"]
    L3["Correct in an experiment<br/>is not months under load"]
  end
  P --> L
```

*Figure 38 — 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 [*How to read this document*](/en/how-to-read-this-document): 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 *an engraved list* — a line nobody could change, blocking in advance 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.

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:<br/>high throughput?<br/>assets crossing networks?<br/>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<br/>— the table above names which"]
```

*Figure 39 — 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** — [*Compliance and safety*](/en/compliance-and-safety) 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.

## 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<br/>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<br/>— and that is what gives<br/>'an impersonator is a fraudster' its meaning"]
```

*Figure 40 — 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 [*How to read this document*](/en/how-to-read-this-document) — **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<br/>1 Basics · 2 LOVE9"]
  N --> B["Those who want to help operate<br/>3 Nodes · 4 Security"]
  N --> C["Organisations and developers<br/>5 Legal · 6 Organisations · 7 Developers"]
  N --> D["Those who want to verify<br/>8 Governance · 9 Status"]
```

*Figure 41 — 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 and need*](/en/context-and-need).

**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 and need*](/en/context-and-need).

**3. What does the number 9 mean?**
It is an identifying motif, and it also shapes some proposed parameters: total supply **nine billion**, a release rhythm of 0.09% per day, 9% of fees back to the endowment and 9% burned. Two things to be clear about. First, those are **opening proposals**, not inviolable constants, and the community can vote on them. Second, an earlier version of this document anchored the total supply to **nine squared**; that figure has been replaced, so anywhere still saying nine squared is a leftover not yet cleaned up.

### Group 2 · LOVE9 and distribution

**1. How much do the team and investors hold?**
The proposed allocation gives **9% to the team, locked four years**, and **9% to a private sale round, locked two years**. Both items sit in the table in [*LOVE9 economics*](/en/love9-economics), not in some appendix. You do not have to take the table's word for it: the table is **PROPOSED**, while what actually has force is **the genesis file of the running period** — open it and count. And because the current constitution engraves no number, changing that table means 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 [*Platform architecture*](/en/platform-architecture).

**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. [*Who uses it, and who cannot yet*](/en/who-uses-it-and-who-cannot-yet) 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 [*Platform architecture*](/en/platform-architecture): 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?**
This answer has changed from earlier versions of the document, and it changed in the harder direction. What is **settled**: **balances on a test network do not carry across** — the official network is born from a new genesis, not as the continuation of a test network. What is **not settled**: how your contribution during the testing stretch will be recognised — that is marked **LEFT BLANK**, for the community to vote on. 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.