When they are wrong, and when we are.

We published: “Nine external researchers, across three disclosure rounds — and a Hall of Fame listing nine names, in fourteen languages.”

Wrong because: Two credited researchers were missing from the site: destinyae and superagent. Both are named in SECURITY_HALL_OF_FAME.md in the DEX and staking repositories, which is the register of record, and both are credited in DEX commit 32aa8d5 ("Reported by destinyae", "credit destinyae and superagent"). The page under-credited real people for three days.

True: Eleven external researchers across four disclosure waves. Both worked on the DEX aggregator.

Root cause: The roster was written in three independent places — ROSTER in src/lib/advisories.ts, a hardcoded array on the English page, and thirteen locale blocks. Three copies drift. · fixed by The English page now renders from ROSTER, which also generates the /security/researchers profiles. Commit 76439c8.

We published: “Two facts stating the bounty count with different numbers at the same time: bounty-record said "Four disclosure waves, eleven credited researchers", disclosures said "Three disclosure rounds … Six external researchers are credited".”

Wrong because: The register built for machines to read contradicted itself. An answer engine reading it reported "21 external findings fixed" — a number that appears nowhere in our data. A contradiction does not produce doubt, it produces invention.

True: Eleven credited researchers, four disclosure waves, zero critical findings — as recorded in SECURITY_HALL_OF_FAME.md in both public repositories.

Root cause: The count was asserted in two facts instead of one. The stale one predated the second and third disclosure waves. · fixed by disclosures no longer restates a count and points at the canonical register instead; bounty-record is the single owner of the number. Commit cda0866.

We published: “Credited researchers — 9, on a page whose lead reads "Every number below is generated by CI from public source files … no manual step exists between the measurement and this page."”

Wrong because: The value was the literal 9, hardcoded in the generator. It went stale the moment two researchers were credited, and it was presented as a measurement.

True: Eleven, counted from ROSTER at build time.

Root cause: A number written by hand on a page that claims every number is derived. · fixed by gen-open-metrics.mjs counts ROSTER; if it cannot, the field is null and the page renders an em dash rather than a guess. Commit 85071f2.

We published: “"articles": 142 with a fresh timestamp, and an orphan list containing one entry.”

Wrong because: Six live articles were missing from the graph entirely, and twenty-eight link edges were discarded, so the orphan list was a confident statement about an incomplete corpus. Six articles could not be reported as orphans no matter their real state. Meanwhile /vitality.json, /geo-lint.json and the knowledge graph all said 148.

True: 148 articles, 557 edges, zero orphans.

Root cause: Two regular expressions matched single-quoted strings only, while part of the corpus is written with double quotes — one for article slugs, one for the related[] targets that form the edges. · fixed by Both patterns accept either quote style, plus a guard that fails loud if the matched count ever drifts from the declared count. Commits 85071f2 and da99914.

We published: “exitOpen: 0 on all four chains for 2026-08-27, in a dataset the /data page describes as the raw material for honeypot-prevalence statistics.”

Wrong because: No token was probed that day: exit was null for 85 of 85. The zero counted a numerator with nothing in it while listed still counted every token, so "we probed everything and nothing could be sold" was indistinguishable from "we probed nothing". The radar the following day showed 84 of 85 tokens as open, so the published figure was wrong by roughly 84 — in the direction that makes the ecosystem look worse than it is.

True: Zero tokens were measured on that date. The row carries no information about how many had an open sell route.

Root cause: The aggregation had a numerator and no denominator, and the probe counters that exist precisely to supply one were computed and then dropped before publication. · fixed by The daily row now records exitProbed, exitOpen, exitClosed and exitUnknown, and probeStats ships in the public radar feed. Commit d1dc208. The 2026-08-27 row is left as published — this dataset is never backfilled — and this entry is its annotation.

We published: “ok: true with totalFills: 0 and totalSurplusPayouts: 0, while zero of five chain scans had succeeded. Ten consecutive rows of /datasets/history.ndjson recorded the same shape.”

Wrong because: A failed chain scan contributed the same 0 as a scanned chain with no swaps, so the response asserted a measurement that never happened — on the endpoint that feeds a public dataset, and against our own written rule that an unreachable endpoint leaves the figure blank rather than filled.

True: Across the ten published rows, 21 of 50 chain-days were measured and 29 failed: 42% coverage. The measured days genuinely recorded zero swaps, which is expected before launch.

Root cause: The aggregate had no coverage field, so absence and zero were the same value. · fixed by chainsOk, chainsTotal, coverage and measured are now in the response, and /api/tape gained chunksScanned/chunksOk/measured for the identical defect. Commits b51d0bb and d1dc208. The ten existing rows are left as published and annotated here.

We published: “"50,000,000 BZPX (4% of supply) is reserved for the community airdrop" — as the answer text of the FAQPage JSON-LD emitted from the root layout, and therefore in the machine-readable layer of every English page on the site, plus the same sentence in prose on /faq.”

Wrong because: 50,000,000 of a fixed 1,000,000,000 supply is 5%, not 4%. The sentence contradicted its own arithmetic, and it contradicted every other surface: /facts.json states 5% in five separate facts, /llms.txt and /capabilities.json state 5%, the allocation table only sums to 100% with 5%, and all thirteen translations of the same FAQ answer already said 5%. English was the only surface carrying the old figure.

True: The airdrop is 50,000,000 BZPX, 5% of the fixed 1,000,000,000 supply. It was raised from 40,000,000 (4%) out of the market allocation; the English copy was never updated to follow.

Root cause: The percentage is written as prose in many places with no single source, so raising the allocation required editing every copy of it by hand and one was missed. Same defect as RET-2026-002: a value stated in two places will eventually disagree, and a machine reading a self-contradicting file does not report doubt — it reports a number. That is how "21 findings" was cited. · fixed by Corrected in src/app/layout.tsx and src/app/faq/page.tsx, commit 7282eed, verified live. A test now reads the percentage out of the airdrop-allocation fact in /facts.json and requires the prose across layout, /faq and all thirteen translations to agree with it, rather than hardcoding the figure a fourteenth time. It was verified in both directions: reintroducing 4% makes it name the file and the value.

We published: “That the security programme had run three disclosure rounds with nine external researchers. The figure appeared in the FAQPage JSON-LD of the root layout ("Eight findings … reported by three external researchers", answering "Is BlazePhoenix audited?"), in /llms.txt twice, and in /topics.json three times.”

Wrong because: The register credits eleven researchers across four disclosure waves, which /facts.json, the /bounty page and the Hall of Fame in both repositories already stated. The root-layout figure was worse than stale: it was a claim scoped to the eight staking disclosures — where three named researchers is correct — promoted into an answer about the whole project and then left behind by three further waves. Unusually for this class, the error UNDERSTATED the record, by eight researchers and three waves, in the machine-readable layer of every English page.

True: Four disclosure waves, eleven credited researchers, zero critical findings. Five are published as advisories at /security/advisories.

Root cause: A scoped historical sentence was reused as an unscoped current claim, and nothing compared it against the register that decides the number. §29 of the whitepaper still carries the scoped version — "by the close of the third disclosure round" — which is true as written and was deliberately left alone. · fixed by Corrected in src/app/layout.tsx, /llms.txt and /topics.json, commits 5927b98 and 4a080e7, verified live. Found by the claim census (/claims-census.json), which now fails the build on a disagreement of this shape.

We published: “That the engineering corpus holds 65 articles — in the meta description and intro of every language hub, thirty-one strings across about thirty languages — and, in /site-index.txt, that the entity graph holds 128 nodes.”

Wrong because: There are 148 articles and the graph holds 272 nodes. Each page contradicted itself: the hub footer and its CollectionPage JSON-LD counted the real array while the description search engines display did not, and the index that tells machines what to fetch described a graph less than half the size of the one they receive.

True: 148 articles, each with a hand-written abstract in the full hubs; 272 nodes in the knowledge graph on the day of writing, and the figure moves as the graph grows.

Root cause: A count written as a literal next to the same count derived from data. The derived one tracked reality and the literal did not, which is the whole defect: whichever copy a reader happens to read decides what they believe. · fixed by Neither number is a literal any more. The hub strings carry {n}, filled from LEARN_ARTICLES.length at render, and /site-index.txt counts the graph it links to. Commits 5927b98 and 4a080e7, verified live. "Nodes" is deliberately NOT a census quantity — the word also means RPC endpoints here, and a check that cannot tell them apart would fire forever and end up muted.

We published: “Two different Critical award bands in the same file. The fact bug-bounty-programme said Critical findings pay 2,000,000-6,000,000 BZPX; the fact bounty-tiers said 2,500,000-7,500,000. §29 of the whitepaper carried the old band too, alongside an old pool of 40,000,000 BZPX.”

Wrong because: Every band was scaled by 25% when the research pool was raised from 40,000,000 to 50,000,000, so the current Critical band is 2,500,000-7,500,000 — which the /bounty page and bounty-tiers already stated. One fact kept the pre-raise figure. This is the same defect as RET-2026-002 and in the same file: a register that contradicts itself does not make a reader doubtful, it makes a machine confident about a number nobody wrote.

True: One shared pool of 50,000,000 BZPX (5% of the fixed supply) across both repositories. Critical 2,500,000-7,500,000, High 625,000-2,500,000, Medium 125,000-625,000, Low up to 125,000.

Root cause: The award bands are prose in several places and the raise updated some of them. The whitepaper compounded it: its assembled text had been updated to the new pool and bands while the pipeline's source part had not, so the document and the part it is built from disagreed. · fixed by bug-bounty-programme corrected, the whitepaper's §28 and §29 brought level with the assembled text in both the source part and the assembler, and the paper re-rendered. The claim census now reads the Critical floor out of bounty-tiers and requires every other surface to agree, verified by reintroducing the old band and confirming the build stops.