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 · c1.9chain.org | Connecting, running a node, endpoints — each branch publishes its own set |
| contact@9chain.org | Feedback · criticism · vulnerability reports | |
| Community | 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, under Operational discipline |
| Independent third-party audit | A mandatory gate of the Real assets level — not passed | 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, under Governance and who holds the keys |
| Distributing the signing set across independent failure domains | Gate not passed, with a countable threshold | 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.
Figure 25 — 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.
→ Next: LOVE9 economics — Three token layers, never to be confused