Methodology

Claimed: Reported to the operator that cNGN was UNDERSTATED at $290k against CoinGecko's implied $1.70M, and attributed the gap to a missing Solana leg.

Now: cNGN is NOT understated. All 6 CoinGecko-listed chains are now read and the total is 396,396,760 NGN = $290,238, with BSC carrying 99.6% and Solana genuinely holding only 250,023 NGN, about $183. CoinGecko's circulating_supply of 2,378,549,226 NGN overstates our on-chain totalSupply sum by roughly 6x.

Why it was wrong: I inverted this page's own trust hierarchy: I took an aggregator's figure as the truth and treated our direct chain read as the deficient one. totalSupply is a CEILING on circulating supply, so an aggregator reporting 6x our ceiling across the same six deployments is arithmetically impossible rather than merely higher. The correct reading is that the aggregator is wrong. This is the second measured instance of CoinGecko overstating a local-currency stablecoin, after IDRT at about 1.94x.

Claimed: Headline read 'deviation +0.02% (6-CEX avg)'.

Now: The figure was not the 6-CEX deviation at all. The template interpolated a per-cell loop variable from the exchange-pulse price table, meaning 'one venue's price versus that pair's average', so it displayed whatever the last cell of the last row left behind, under an authoritative label.

Why it was wrong: One-token slip, `_dv` where `dev` was intended. The code comment directly above it already stated the correct intent, so the bug was in the expression and not in the thinking.

Claimed: Paired 'TOTAL ON-CHAIN' with the label 'vs 22.4M investors'.

Now: Relabelled to '22.4M OJK regs', with an on-card line stating the figure is registered accounts including dormant ones, and is neither users nor holders.

Why it was wrong: Our own ADOPTION panel already said that number is an account count including dormant registrations and that neither figure is a user count. Calling it 'investors' beside a thin supply rail invited a per-person supply reading that neither panel makes.

Claimed: Stamped as an observed-class reading, listing Bitwyre and Ajaib Kripto as 'REST + WS + Trade' at high confidence, Reku as market-data-only, and Mobee as app-only.

Now: Badge downgraded to REPORTED, not reachability-tested. The panel now computes and displays its own contradictions against what the volume fetcher actually managed to read.

Why it was wrong: The table was dated 2026-07-10 and our own later audits (07-12, 07-13, 07-17) had already found Bitwyre's documented API dead, Ajaib walled with no public volume endpoint, Reku's ticker carrying volume after all, and Mobee shipping an Open API. The panel counted venues the same page elsewhere showed were unreachable.

Claimed: Supply figures were presented under a 'circulating' framing.

Now: Relabelled 'ON-CHAIN SUPPLY, totalSupply, NOT free float', with an unconditional disclaimer that the figures include issuer treasury, unissued balance-sheet inventory, and blacklisted balances.

Why it was wrong: We read totalSupply(), which is minted minus burned. That is a ceiling on free float, not circulating supply, because a blacklist freezes a balance without burning it.

Claimed: Called IDRX on Base the busiest deployment.

Now: Withdrawn. 8 of 19 chains were unmeasured at the time the claim was made.

Why it was wrong: Generalised from a measured subset to the whole set. The comparison could not have been made from the data in hand.

Claimed: Stated that all five previously-unreadable chains were reachable at a call-volume price, and that the constraint was range rather than endpoint.

Now: Holds for ONE chain of five. Harmony now reads at 500-block width. Etherlink and Monad serve only 100-block ranges, needing 793 and 2,787 calls, so they stay unread by policy. Gnosis and WorldChain refuse eth_getLogs at every width down to 100, so for them the endpoint is the limit and chunking cannot help.

Why it was wrong: Inferred availability of an expensive method (eth_getLogs, an index scan) from success at a cheap one (eth_call, one state read). Providers gate and price per method, not per endpoint.

Claimed: Relayed CoinGecko's IDRT supply figure of about 9.63M USD.

Now: Direct multichain contract reads put IDRT at about 5.02M USD. CoinGecko overstates it by roughly 43 percent. The on-chain read is now the published figure and the aggregator number is shown only as the contrast.

Why it was wrong: Trusted an aggregator on a quantity that is directly verifiable on chain.

Claimed: Reku was excluded as market-data-only, and Mobee as app-only with no public API.

Now: Both beliefs were stale. Reku's /v2/ticker does carry IDR-quote volume. Mobee had shipped an Open API, wired 2026-07-17.

Why it was wrong: A one-time capability check was treated as permanent. Venue API surfaces change.

Claimed: Relayed a paid research figure of 9 licensed VASPs.

Now: 8 active, per Bappebti's own directory.

Why it was wrong: Took a secondary source over the primary register it was summarising.

Claimed: A fixed 5,000-block sweep window was treated as comparable across chains.

Now: 5,000 blocks is about 16.7 hours on Ethereum and about 37 minutes on BSC. The window is now time-denominated at 24 hours per chain, with the block width derived per chain.

Why it was wrong: Held the block count constant when the quantity that needed holding constant was elapsed time. Every cross-chain flow comparison built on it was measuring different durations.

Claimed: Bybit Indonesia rendered as 'rebranding, awaiting OJK clearance'.

Now: Status is live. OJK clearance granted and Bybit Indonesia operating. Recorded with status_source and status_checked so the row's freshness is separable from the file's generated_at.

Why it was wrong: NOT simply a stale read. The fact was already held: memory/Context/indo-cex-ma-landscape.md has carried 'Bybit Indonesia live 2026-07-15' in its headline block since 2026-07-15, from the editor's own interview. The deal table EIGHT LINES BELOW that sentence, in the same file, still said 'awaiting final OJK clearance', and this dashboard's data file was never reconciled against either. So one fact lived in three places, one was updated and two were not, and the page kept rendering the stale one for 15 days. The brain-first gate covers what I read before ANSWERING; nothing covered what a build reads before RENDERING.

Claimed: The y-axis shipped earlier the same day was reported as verified on five charts.

Now: Chart and x-tick row now share one inset container, so both axes resolve against the same origin.

Why it was wrong: The y gutter was a padding-left on the chart wrapper while axisrow() stayed an outside sibling. Padding does not move an absolutely positioned child, so the plot shifted 52px and its x labels did not: every tick sat about 50px from the point it named. The y-label CSS carried a comment stating that exact rule, so the fact was known, written down, and not applied one function away.

Claimed: The volume axis floor sat at about -150B.

Now: Floor clamped to zero. Traded volume is a non-negative magnitude and this axis is where the Total-to-Core ratio is read.

Why it was wrong: The scale spans every venue at once, so 8% padding on a range from Rp30B to Rp2,000B was larger than the smallest series' entire value and walked the floor through zero. Invisible for as long as the chart had no y labels, which is the second time today that adding an axis exposed a wrong value rather than a cosmetic one.

Claimed: Two panels presented as separate views.

Now: Merged into one. The graph read nothing but cex_manda.json's five rows, so it was the same table with the columns swapped; its finding and its declared-missing relationship types moved into the board.

Why it was wrong: Built as a roadmap item without checking that its only data source was already fully rendered elsewhere on the same page. A reader met the identical five rows twice.

Claimed: Rp1.96T for 'Crypto tax, Feb 2026 (cum)' printed directly above Rp796.73B for 'Crypto tax revenue, 2025', with no basis label on either, and both five months stale.

Now: Rebuilt from data/djp_tax.json. Every row now states its basis, the cumulative is current to Jun 2026 at Rp2.09T, and the annual series 2022 to 2026 carries a real line with the two partial years flagged. The cumulative-vs-calendar-year basis is confirmed verbatim from DJP's own press release: 'terkumpul sebesar Rp1,96 triliun sampai dengan Februari 2026'.

Why it was wrong: Two correct numbers on different bases, adjacent, unlabelled. No range check catches that because neither value is wrong. It implied two months of 2026 at 2.5x the whole of 2025. The identical misread happened on 2026-05-01 against this same dataset and the editor caught it then too; the rule went into Learnings and the dashboard shipped the pair anyway, because a rule in memory does not gate a build. Now gated by fetchers/validate_djp_tax.py, whose cross-release check forces the cumulative and the annual series to reconcile.

Claimed: POJK 27/2024 listed as simply 'Active', with POJK 23/2025 absent from the library entirely.

Now: POJK 23/2025 added and the POJK 27/2024 entry cross-linked to it. Confirmed from OJK's own Siaran Pers SP 210/GKPB/OJK/XII/2025, 4 Dec 2025: it amends the keystone rule, brings AKD derivatives into scope, adds margin and consumer knowledge-test obligations, and via Art. 87 restricts segregated accounts to OJK-licensed commercial banks while deleting the BPDK approval concept.

Why it was wrong: The amendment was about eight months from promulgation (diundangkan 10 Nov 2025) and seven from OJK's announcement (4 Dec 2025) old, and the library, generated 2026-07-10, never had it. So the page presented the SUPERSEDED text of the single most load-bearing rule for a market-entry reader. Nothing flagged it because the library looked complete: 25 entries, grouped, dated, self-consistent. Absence has no shape. Three panels read this one file, so one gap surfaced in three places.

Claimed: '9 of 29 licensed venues read' and '29 licensed exchanges in the market', with 29 hardcoded.

Now: OJK's May-2026 position is 26 PAKD out of 32 licensed entities. The TWO code sites now read one variable off the new data/ojk_licensing.json. The third site, a summary string in cex_api.json, is deliberately LEFT at 29 with a note, because the numerator 8 was probed against the Dec-2025 roster and re-basing it onto 26 would invent a measurement nobody made.

Why it was wrong: One fact in three places, two of them code literals, sourced from a roster about eight months from promulgation (diundangkan 10 Nov 2025) old at the time. Every coverage ratio was dividing by a stale denominator. Worth more than the arithmetic: the PAKD count FELL from 29 to 26, so the licensed population is contracting, which the page could not show while the denominator was frozen.

Claimed: Latest 2026-04 at Rp22.982T, described as a contracting market.

Now: Appended verified 2026-05 = Rp23.01T from OJK's RDKB June-2026 release, published 7 Jul 2026. May rose 0.11% mtm.

Why it was wrong: One full month behind a MONTHLY publication that had been out for three weeks. The direction matters more than the staleness: the newest point is UP, so 'contracting' describes Jul-2025 to Apr-2026 and must not be read as still falling.

Claimed: CFX referred to as though it were the only Indonesian crypto bourse.

Now: There are TWO: CFX (PT Central Finansial X) and ICEX (PT Fortuna Integritas Mandiri). Each maintains its OWN Daftar Aset Keuangan Digital, CFX at 1,265 assets plus 40 derivatives and ICEX at 788, so 'is this token tradable in Indonesia' now has two answers. Recorded in data/ojk_licensing.json with an explicit instruction NOT to sum them, since overlap is unmeasured.

Why it was wrong: The dashboard never mentioned ICEX. A single national asset list is a reasonable prior that stopped being true.

Claimed: Exchange-sector coverage labelled 'swept', with the roster holding 14 venues and the prose citing a denominator of 29 licensed exchanges.

Now: Reconciled name by name against OJK's PAKD/CPAKD whitelist (siaran pers 19 Dec 2025). Sixteen licensed or registered venues were absent; the roster is now 30 exchanges. The label now separates venues we read live from venues present only on OJK's record, and the denominator is derived from the licensing file instead of written in prose.

Why it was wrong: 'Swept' is a claim about our own process and it was the one claim on the panel nobody audited. Holding 14 of 29 whitelisted venues while asserting a sweep inverted the panel's whole purpose, since the empty and short rows are supposed to be trustworthy precisely because the coverage label is.

Claimed: The licensed digital-asset trader population shrank by three between Dec 2025 and May 2026, 29 down to 26, read as the first direction change the dashboard had held.

Now: WITHDRAWN, not restated. OJK's Dec-2025 whitelist carries 29 ENTRIES, being 25 licensed PAKD plus 4 registered CPAKD; entries 1-25 cite izin decrees and 26-29 cite CPAKD registrations. The May-2026 figure of 26 is PAKD only. Like for like reads 25 to 26, an increase of one. Left withdrawn rather than flipped to +1 because the 25/4 split comes from a press-release table relayed through search results, not from the OJK PDF.

Why it was wrong: Mixed basis. Two individually correct numbers compared across different definitions, which no range or plausibility check can catch, and the error was large enough to reverse the direction of the conclusion. It also propagated a narrative ('runs opposite to the licences-are-hot framing') off the reversed sign.

Claimed: Earlier the same day, that the hardcoded '29 licensed venues' denominator had been consolidated into a single variable, reported as three places and two code literals.

Now: A fourth copy survived in dashboard_companies.py, in prose, in a different module. Now sourced from the licensing file like the rest.

Why it was wrong: I grepped the file I was editing and reported a tree-wide conclusion from it. The count I gave was itself produced by the too-narrow search it was describing.