Most "research" on a new chain is reading someone else's conclusion. Uncomfortable version: in one evening you can read the receipts yourself and decide whether the trail holds.
We build the audit surface for MSG Chain, so treat us as biased — which is why this piece hands you the checklist, not the conclusions. Run it on us first, then on the next project that asks for your attention.
The whole method in one table
| Where you look | What it answers | What it cannot answer |
|---|---|---|
| The status file — https://msgchain.org/status.json | Is the chain live, and who flips the switch? | Whether a feature works today |
| The whitepaper master map | What exists, what is partial, what is planned | Whether its code is safe |
| The knowledge network file | How many modules, and how each is tagged | Whether the tags are honest |
| The evidence index | Source, query, receipt, negative sample | On-chain guarantees before launch |
| The role path page | Your shortest path | A second opinion |
Five stops. One evening. No priors required.
Start where the chain states its own limits
Open https://msgchain.org/status.json — the single source of truth every page on the site references, so the wording cannot drift between pages.
Read three fields first: network_status, mainnet_verdict, status_flip_condition. On our chain today they say not launched, No-Go, official_launch_announcement: the status flips only on the official launch notice, and feature status is stated separately from mainnet status.
Two lines deserve quoting: the metrics note calls the homepage figures "design targets, not measured results from the public network," and the cannot-do list forbids treating a locally implemented module as mainnet live.
Our stance: a chain that publishes what it cannot do yet is easier to trust than one that only publishes wins. No machine-readable status file? Treat the absence as data.
Read the map: five layers, seventy-three modules
https://msgchain.org/whitepaper is a topology graph, not prose. Every module page carries a status tag — implemented, partial, planned — and evidence pages carry a separate audit tag: "evidence back-reference page (not a capability status claim)".
The machine-readable version sits at https://msgchain.org/whitepaper/knowledge_network.json, where module_count and the entries list must agree — when we last pulled it, they did: seventy-three in both.
Nobody reads seventy-three pages in an evening. Read the master map, circle every planned tag, then check one implemented page against its linked source before trusting the rest.
Follow the receipts, not the summaries
The trail, in order:
- Full proof chain map — https://msgchain.org/whitepaper/modules/proof_map.html
- Strength criteria — https://msgchain.org/whitepaper/modules/evidence_strength.html
- Evidence index — https://msgchain.org/whitepaper/modules/evidence_index.html, organized as source, query, receipt, negative sample
- Reviewer walkthrough — https://msgchain.org/whitepaper/modules/review_playbook.html
The negative sample column is the one most projects never build. Anyone can publish a page about a success. A receipt wall with no negative samples is marketing, not documentation.
Pick your entrance by role
https://msgchain.org/whitepaper/modules/role_paths.html gives each reader a shortest trusted path: investors start at the credibility layer, developers at the contract execution surface, auditors at the proof chain. It gives reading order — it does not replace the proof, evidence, and receipt originals.
If you write code: https://msgchain.org/pages/docs hosts 148 site-hosted developer references, and that page states clearly the chain is not launched.
Where the honest boundary sits
An evening audit proves one thing well: that the navigation and evidence organization exist. A status file that answers No-Go. Tags that separate shipped from planned. An evidence index with negative samples beside the wins. Role paths that refuse to call themselves proof.
It does not prove the layer underneath is finished. Our own status file says so: implemented means implemented in the local build, not production; a planned page is not a timeline. Nothing here is an on-chain transaction, asset proof, or investment basis. MSG Chain is not launched — mainnet is No-Go until an official announcement says otherwise. Not financial advice. DYOR.
Questions for the community
- Which single missing receipt would kill a chain for you — no status file, no negative samples, or planned pages dressed as shipped?
- Should a machine-readable status file become a listing requirement for data aggregators?
- If a chain survives a one-evening receipt audit, what still needs a professional audit?
Pressure-test this checklist on us: ask at qa.msgchain.org · read the map: https://msgchain.org/whitepaper · argue live: https://t.me/+OrceJ-S4iJIxMzU1
Follow @msgchain — we publish the receipts, the negative samples, and the No-Go status.
Top comments (0)