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.

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.

Figure 36 — 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.