Corrections
Corrections
When this record is wrong, the correction is published here: dated, saying what the record said before, what a reader relying on it would have concluded, and what was done. Nothing is silently edited and no page is deleted.
Dispute a record
Write to corrections@chainoftitle.org with the mint or wallet and the transaction that shows the error. We aim to respond within five business days.
| We correct | Any statement of fact the chain does not support: a wrong number, time or wallet, or an event recorded that did not happen. |
|---|---|
| We do not remove | An accurate record because it is unwelcome. We record what the chain shows, never intent, and we do not claim to know who controls a wallet. |
| Statements | If a launch wrote your name into its description, we publish your statement on that record beside the text. If you control a wallet on a record, sign a message from that address and we publish your statement on its page, in full and unedited. You do not need a wallet to ask about your name. |
Corrections issued
16-
operator-graph-republished
What was wrong. The funder graph withdrawn on 2026-09-13 (correction operator-graph-infrastructure) was re-derived under predicates that refuse infrastructure by measurement: a funder at or above 3,000 signatures and 200 transactions an hour is not enumerated; a group whose members scatter across unrelated mints is demoted as probable service customers and never counted as members; a weaker trade window never overwrites a stronger measurement. The funding time of every groupable wallet was then traced to completion: 30,148 of 35,308 hold a measured funding time, and the remainder are marked definitively untraceable rather than left unknown. Measured on 2026-09-17 against the labeled cases, in both directions: the two hand-traced farms remain whole and undemoted, no platform-profile funder holds a member wallet, and the batch-seeding coefficient separates the populations - among funders with five or more dated members, the median share of members funded inside one hour is 0.58 for retained groups against 0.02 for demoted ones.
What a reader would have concluded, and what was done
What a reader who trusted it would have concluded. While the graph was withheld, no surface, paid or free, showed cluster membership. From this correction it is shown again, with 10,107 of 35,308 grouped wallets (29 percent) excluded as sitting under demoted funders; every published member count is net of that exclusion and the exclusion is stated beside it.
What was done. operator_wallets and operator_funders return to the licensed record and the wallet API. Grouping by shared infrastructure remains refused, membership never asserts identity or intent, and this measurement is republished whenever the derivation rule changes.
-
dbc-coverage-overclaimed
What was wrong. The record built 2026-09-16 15:30 UTC carried a Meteora DBC coverage window starting 2026-09-11 23:56 UTC. The chain scanner only began decoding that program at its 2026-09-14 10:58 UTC deploy. Earlier that day an archival backfill re-read 273 slots from 2026-09-11 and extracted the DBC launches in them, and the window start was computed from the earliest launch on file rather than from when decoding began, so it followed those rows back. Between the claimed start and the real one lie 671,844 slots holding 45 DBC launches, where the venue's own rate over the following days implies thousands.
What a reader would have concluded, and what was done
What a reader who trusted it would have concluded. A reader comparing a Meteora DBC launch from 2026-09-12 or 2026-09-13 against this table would have read it as inside a watched window, and so read the archive's silence about that launch as evidence it did not happen, when the scanner was not decoding the program at all. No launch record was wrong; the coverage claim around it was.
What was done. The window now starts no earlier than the first slot read with DBC decoding running (446,958,940), a fixed value rather than an inference from the table's contents. The 45 backfilled launches remain in the record and their window is not claimed. Coverage for the two watched venues is unaffected.
-
findings-queries-not-verbatim
What was wrong. From 2026-09-13 to 2026-09-15 the findings page printed two queries under the sentence 'These are the queries above, verbatim', and the denominator was not verbatim. The population predicate had been repaired on 2026-09-12 as part of the curve-buyers-undercounted remedy: it gained a clause that keeps a launch in the denominator when its trade rows were pruned but a creation-block buyer proves it had one, and a clause excluding venues whose trade events name no wallet. The printed copy was not updated. Run against the record built 2026-09-15 15:10 UTC, the printed denominator returned 14,028 where the page's figure, computed with the repaired predicate, was 8,548.
What a reader would have concluded, and what was done
What a reader who trusted it would have concluded. A reader who ran the printed queries got a denominator 64% larger than the page's, a no-outside-buyer share of 32.2% against the published 52.8%, and no way to tell whether the page's figure or the page's instruction was the wrong one. No published figure was wrong: the page's numbers were computed with the repaired predicate throughout, and the numerator query agreed between the two forms, since a zero outside-buyer count already implies the evidence both missing clauses require. What was wrong was the published claim that the printed queries reproduce the figures.
What was done. The page now prints the predicate from the same constant the figures are computed with, so the printed query and the computation cannot diverge again, and a test executes the SQL exactly as printed on the rendered page and fails unless it returns the page's own numbers. Corrected 2026-09-15.
-
operator-graph-infrastructure
What was wrong. From 2026-09-07 the published record's operator_wallets and operator_funders tables presented wallets that share a funder as operator clusters: 27,761 wallets under 2,123 funders in the archive deposit of 2026-09-12, and 30,936 under 2,675 by 2026-09-13. A re-derivation on 2026-09-13 measured that 9,214 of those 30,936 wallets sit under 77 funders whose on-chain activity matches trading or exchange infrastructure: throughput at or above 200 transactions an hour, with funded wallets scattered across thousands of unrelated mints. A further 9,885 wallets under 189 funders could not be behaviourally confirmed either way. The tracer imported every recipient of a traced funder as a member, so one unguarded exchange or terminal funder brought in hundreds of its ordinary customers.
What a reader would have concluded, and what was done
What a reader who trusted it would have concluded. A reader was shown ordinary customers of shared infrastructure as members of an operator cluster. Funding by shared infrastructure is not evidence of coordinated operation. The correction cluster-policy-published kept these two tables on the ground that who funded a wallet is a chain fact; that fact stands, but presenting it as cluster membership did not, for roughly thirty percent of the wallets measured.
What was done. Both tables, and wallet_flow, which describes the same wallets, were removed from the published record and from a corrected revision of the 2026-09-12 archive deposit on 2026-09-13. Grouping by funder is withheld from every surface, paid or free, while it is re-derived under a stricter rule that refuses members imported from infrastructure-profile funders. Who funded a wallet remains a chain fact, readable from the chain itself.
-
cluster-policy-published
What was wrong. The record carried a table, operator_policy, holding this project's own grade of each wallet cluster - one of follow, watch or avoid - written while this was a trading project and kept after that hypothesis was tested and rejected. 55 rows were published: 34 avoid, 17 watch, 4 follow. Two carried hand-written notes characterising named groups from a sample of one or two launches each. The grade was also rendered on every wallet and cluster page under the heading 'Cluster behaviour', and served by api/v1 as operatorPolicy.
What a reader would have concluded, and what was done
What a reader who trusted it would have concluded. A reader of the record, the API or those pages was given our opinion of a group of addresses as though it were part of the archive, with no caveat attached to it and no way to tell it from an observation. The cluster pages themselves say a shared funder is a lead and not a finding, and that trading terminals fund their users exactly as a wallet farm does - so the grade contradicted, on the same page, the sentence written to qualify it. It is the failure this archive reports in others: a characterisation of a party stated as record. The file is public domain and mirrored under a DOI, so copies taken before this date carry it.
What was done. operator_policy is no longer published and is dropped from the record on the next build. The grade is gone from the wallet and cluster pages and from api/v1, and the two hand-written notes are removed from the code that seeded them into every database. Nothing observed was deleted: operator_wallets and operator_funders stay, because who funded a wallet is a chain fact, and the funder note records where a cluster is a trading terminal rather than a farm. What was withdrawn is only ever our conclusion about a party.
-
curve-buyers-scope-restated
What was wrong. The curve-buyers-undercounted correction published earlier today is right in its finding, its remedy and its count of 43, and wrong in three things it says about itself. FIRST, it bounds its own scope with bundled_buyers and presents that as an independent check: 'of the 3,504 rows that contradicted their own bundled_buyers, 3,504 are now NULL and not one new contradiction was created.' bundled_buyers is incremented inside the same onTrade handler as the buys counter, so it is zero by construction for exactly the rows where buys is zero - which is the cohort the rule certifies as complete. On that cohort the check cannot fail, and a check that cannot fail during the failure it exists to catch has established nothing. SECOND, '616 had counts taken from an incomplete set of rows and 43 of those were published as zero' counts the launches the new rule turns to NULL. It does not count the launches whose PUBLISHED SENTENCE CHANGED, which is the only figure a reader has any use for: nobody cares which internal branch fired, they care how many pages said a thing that is now withdrawn. THIRD, it quotes the headline share as a fixed pair of numbers - 'the published share RISES from 42.8% to 46.9%' - for a population that is still being defined. It has moved twice since it was written, on the same day it was written: the record built 2026-09-12 22:37 UTC publishes 55.4% of 6,634 confirmed curves.
What a reader would have concluded, and what was done
What a reader who trusted it would have concluded. A reader who checked the correction's own reasoning would have found its validation argument circular on the cohort that mattered, and been right to trust their reading over ours. A reader who quoted 46.9% as the archive's finding would have been quoting a number already superseded when they read it - and the original correction exists because figures were published as though fixed, so restating that error inside the correction for it is the failure repeating one level up. Nothing published about any individual launch was wrong on these grounds, and no launch record changes because of this row.
What was done. The independent instrument for that cohort is neither bundled_buyers nor snap30_buyers but the paired halves of the creation TradeEvent itself: 85.005359 SOL against 793,100,000 tokens is the integral of the curve from 30 vSOL to 115, so the pair is coherent at the curve's own pricing and a misread field could not produce both. That is what establishes the 79.31% cohort - 3,694 launches on the 2026-09-12 22:37 UTC record - as real whole-curve buyouts rather than a decode artefact. It was challenged as an artefact while this row was being drafted, and the pairing is what settled it. The 43 stand. Scope is restated here in the terms a reader needs, as a RULE rather than a count, because the count moves every day: the sentence appeared on every page whose graduation was confirmed and whose outside-buyer count read zero, and it is withdrawn from every one of those whose count was taken over rows this project had already deleted. Measured on the record built 2026-09-12 22:37 UTC, that population was 5,293 pages and the withdrawal reached 43 of them. Both numbers were different yesterday and will be different tomorrow. And the share is quoted as a DATED measurement with its rule beside it rather than as a standing fact, because the population grows daily and curve_buyers_live moves launches from unknown into the denominator as they are observed. Any figure here is recomputable from the published file for the date it names, and a different answer next month is the measurement working rather than either figure being wrong.
-
curve-buyers-undercounted
What was wrong. curve_buyers, the distinct outside-buyer count, was recomputed after the fact by counting wallets in the trades table. That table is not a history of a launch and was never meant to be one: finalize keeps a sample of 100 to 400 curve trades per token and retention prunes what is left on a timer, both deliberately and both documented. The count was taken over whatever had survived and published as a measurement. SQL's COUNT over no rows returns 0 rather than NULL, so a launch whose only surviving row was the creator's own first buy was published as having had zero outside buyers. Across the 206,018 launches in the published record, 3,504 carried an outside-buyer count lower than their own bundled_buyers - the distinct non-creator buyers in the creation block, recorded live at launch by a different code path, and necessarily a floor on the total. Those rows disagreed with themselves on their own pages. Of the 5,878 confirmed graduations watched from creation, 616 had counts taken from an incomplete set of rows and 43 of those were published as zero. One example: EFSy2VB3gymYe6tmTzkvqVuqcYQziqogCN4jcN23pump recorded 1,160 curve buys and 15 distinct non-creator buyers in its creation block alone, and its page said it completed its bonding curve with zero outside buyers on record.
What a reader would have concluded, and what was done
What a reader who trusted it would have concluded. Zero outside buyers is the strongest thing this archive says about a launch. It raises a DANGER finding, it is the front page's headline, and it is the sentence a reader repeats. For those launches it was asserted from the absence of rows this project had itself deleted - absence of data published as a finding, in the direction that accuses, which is the one direction the method page says we will not go. A reader who checked such a page against the chain would have found the buyers and been right to trust the chain over us. Separately and in the opposite direction, launches carrying counts that were floors sat in the denominator of the headline share, diluting a finding that is in fact stronger than the one published.
What was done. The collector now counts distinct non-creator curve buyers as the trades arrive and stores the result in curve_buyers_live, which no sampling or retention can reach; that is the published figure for every launch from 2026-09-12. For launches before it, the trade rows are counted only where they are demonstrably all still present - at least as many surviving curve-buy rows as the buys counter recorded live - and the answer is NULL otherwise. NULL means unknown: it never certifies and never accuses. The rule was checked against the independent instrument rather than assumed, over the whole archive: of the 3,504 rows that contradicted their own bundled_buyers, 3,504 are now NULL and not one new contradiction was created. The scope was bounded with bundled_buyers and with the buys counter, both of which count bonding-curve trades only, and deliberately NOT with snap30_buyers, which counts every buyer in the first 30 seconds including market buyers after a fast graduation. 409 published zeros look contradicted by that column and 366 of them recorded no curve buy whatsoever, which is a buyout followed by a market and not a hidden buyer. Read correctly it leaves the same 43 rows this correction withdraws. 14,022 launches move from a number to unknown and 4,772 lose a zero. The headline population falls from 5,878 to 5,262 confirmed graduations and the no-buyer count from 2,513 to 2,470, so the published share RISES from 42.8% to 46.9%. No launch that was correctly reported changes. What cannot be recovered is the true count for a launch whose rows were already pruned; those stay NULL permanently, and that is the cost of having counted them late rather than as they happened.
-
curve-check-rate-unsplit
What was wrong. findings.html briefly reported the on-chain curve readings as a single rate - 'of the curves we read, 83% had not completed'. The sweep that produces those readings is targeted: it reads graduations we could not independently confirm almost exhaustively (98%) and only about a third of the confirmed ones, so the checked population is selected for being the doubtful half.
What a reader would have concluded, and what was done
What a reader who trusted it would have concluded. A reader would have taken 83% as the share of reported graduations that never happened. It is not: it is the share within a population we chose precisely because it was already in doubt. The figure described our own sampling and was published as a property of the market.
What was done. The rate is now split by population and each is labelled with the population it belongs to. Of confirmed graduations re-read, 31 of 2,717 were disproved (1.1%); of unconfirmed graduations, 5,187 of 5,378 had not completed (96.4%). The page states that neither is a rate over all graduations and why. The split figures were always the ones in the record - no reading changed, only what we said about them.
-
disproved-conflated-with-unreadable
What was wrong. curve_complete encodes four states and the pair with curve_checked_at is what tells them apart: no reading, read and the account was already gone (NULL), read and incomplete (0), read and complete (1). The predicate that excluded disproved graduations from every count on the site was written `curve_checked_at != null && !curve_complete`, and in JavaScript `!null` is true, so the second state was folded into the third.
What a reader would have concluded, and what was done
What a reader who trusted it would have concluded. 191 launches were excluded from every graduation count, page and total on the site because our own read found the curve account gone - our RPC result published as a finding about someone else's token. It is the same fault this archive reports in others, with the sign flipped, and the schema comment beside the column had been written specifically to prevent it.
What was done. The predicate now requires an explicit 0. A reading that settled nothing is counted as neither disproved nor confirmed, record pages say so in those words, and findings.html publishes all three counts. Graduation totals rise by 191 against any figure taken before 2026-09-11; that is a correction and not a change in the market.
-
disproved-fix-did-not-travel
What was wrong. The correction below said the predicate that folded 'we read the curve account and it was gone' into 'we read it and it had not completed' now requires an explicit 0. That was true of the shared helper and false of the two callers that had written the test out longhand instead of calling it: the token page in provenance.ts and launch.graduated in api/v1. Both kept `curve_checked_at != null && !curve_complete`, and !null is true in JavaScript, so both went on reporting an unreadable account as a disproved graduation.
What a reader would have concluded, and what was done
What a reader who trusted it would have concluded. The remedy clause of a published correction overstated what had been fixed, on the two surfaces most people actually read. For the same 191-launch population, a record page said we do not state that this curve graduated, and api/v1 returned launch.graduated: false. A reader who took the correction at its word - which is what a corrections register is for - was told the field had been repaired on 2026-09-11 while the API served the unrepaired answer until 2026-09-12. A test existed and passed throughout, because it pinned the helper and nothing asserted that the callers used it.
What was done. Both callers now share the one spelling, so the copies cannot diverge again. Two tests rather than one, because they fail differently: a source check rejects the longhand predicate in any file that could carry it, and a behavioural check runs assess over an account-gone row and asserts it produces no disproof. Verified by reintroducing the fault and watching the first fail. No stored value changed; what changed is that the published answer now matches the correction that promised it.
-
overstated-unrecoverability
What was wrong. The front page said of the launch-time facts: "All of it is visible for about thirty seconds and unrecoverable afterwards. Once the float has been spread across wallets none of it can be read off the chain any more." The data dictionary said the same of every column marked `live` - "unrecoverable afterwards ... nobody can go back and measure it, including us." The chain retains those events permanently. What a present-tense check cannot do is read them from the token's current state, which is a narrower claim and the one this archive actually rests on. This repository's own src/backfill.ts reconstructs those same figures from a bonding curve's transaction history, and the history job has done it for 2,729 launches aged up to four months.
What a reader would have concluded, and what was done
What a reader who trusted it would have concluded. The overstatement ran in the direction that flattered us: it presented the archive as the only possible source for figures a reader with archival RPC could derive independently. Anyone deciding whether to depend on this project - a researcher, a grant reviewer, a journalist citing the record - was given a stronger reason than the facts support. The method page had carried the accurate version throughout, that only the off-chain metadata behind a creator-controlled URI is genuinely unrecoverable, so the site disagreed with itself in public and the wrong half was the louder one.
What was done. The front page now says the launch cannot be read from the token's present state, that the events stay on chain and can be decoded again from an archival node as a rebuild rather than an observation, and that this record was taken as it happened. The dictionary's `live` kind is defined the same way and points to `chain` for reconstruction. No figure in the record changes - only what was claimed about how else they could be obtained. What this file adds is that the reading was contemporaneous, which is a smaller claim than the one withdrawn and the one that is true.
-
reconstructions-published-unqualified
What was wrong. hist_trades carries buyout evidence reconstructed from chain history rather than watched live, and backfill.ts states the rule those rebuilds follow: one that could not read every transaction is partial, however many it did read, and certifies nothing. That rule was enforced in hist_tokens, a table history.ts only ever wrote on a laptop and which the seed never exported. So the reconstructions reached this file through a merge and the qualifier that says whether to trust them did not.
What a reader would have concluded, and what was done
What a reader who trusted it would have concluded. 1,072 reconstructed buyout rows were published with nothing distinguishing a rebuild that read a whole curve from one that read a fortieth of it. Measured on the source database: 188 of 2,729 rebuilds were truncated, reading on average 38.7% of their own history and at worst 2.5%, and 24 of the published rows come from those. Operator figures derived from them, including the curves taken and the SOL spent shown on wallet and operator pages, are floors rather than counts. The bias understates an operator rather than overstating one, which is the harmless direction and still leaves a figure a reader cannot audit.
What was done. hist_trades now carries rebuild_complete: 1 where the rebuild read the whole curve, 0 where it did not, NULL where this file cannot say. meta.hist_trades_qualified distinguishes a file that knows from one that cannot, because a column of NULLs means different things in each and looks identical. The seed now exports hist_tokens and the merge imports it, so the qualifier travels with the evidence. Rebuilds mis-stored as complete were re-marked partial and are eligible for another pass. As of this build the record carries 1,048 complete, 24 truncated and 0 unattributable. No trade row was added, removed or altered: what changed is that each one now states how much of its curve was read.
-
graduated-not-asserted-when-disproved
What was wrong. The correction above published the on-chain check beside the flag and told readers to count differently. That left every consumer who did not read it - the API, the pages, and anyone branching on the field - still being told a curve graduated when we had read the curve account and found it had not. 3,195 records in the published archive were in that state.
What a reader would have concluded, and what was done
What a reader who trusted it would have concluded. api/v1 `launch.graduated` returned true for those 3,195, and the front page counted them as graduations: over one 24-hour window the headline figure was 1,273 where the disproved rows account for 455 of it. A field that is knowably wrong is worse than a missing one, because a reader cannot tell which rows to distrust.
What was done. `launch.graduated` is now our best knowledge rather than our first observation: false where the check disproved it. The raw feed event is published beside it as `launch.graduationObserved`, and the reading as `launch.graduationCheck`. The stored column is still left exactly as recorded, for the reason given above. Site counts exclude disproved graduations. Integrators reading `graduated` before 2026-09-10 were getting the observation; they are now getting the finding.
-
graduated-inferred
What was wrong. tokens.graduated is written when the collector's own feed sees a decoded trade reach the graduation threshold. Curves cross that mark and fall back, and until 2026-09-09 nothing ever re-read the curve account to check.
What a reader would have concluded, and what was done
What a reader who trusted it would have concluded. A reader counting WHERE graduated = 1 gets roughly 1.8x the number of curves that actually completed. Measured on 2026-09-09: of 12,351 rows carrying the flag, 6,945 are confirmed, and 5,187 unconfirmed graduations were read directly and returned complete = 0 — disconfirmed, not merely unwitnessed.
What was done. graduated is left exactly as recorded, because repairing it would overwrite an observation with a later reading and destroy the evidence that the error happened. The reading is published beside it as curve_checked_at and curve_complete, and the graduations view carries the confirmed set. Count with graduated_confirmed_by IS NOT NULL, or select from graduations.
-
uncheckable-figures
What was wrong. Every record page carried the sentence "Everything here is read from the Solana chain and can be checked against it", and until 2026-09-09 the record withheld what was needed to check it. No launch row cited the creation transaction its figures were computed from, so dev_pct, the outside-buyer count and the graduation were checkable in principle and take-our-word-for-it in fact.
What a reader would have concluded, and what was done
What a reader who trusted it would have concluded. A reader who relied on that assurance — a grant reviewer, a journalist, anyone citing a figure — was relying on our decoder rather than on the chain, and had no way to tell the difference. That is the opposite of what the sentence promised and it was on every page we published.
What was done. create_sig and create_slot now cite the transaction each launch is decoded from, backfilled to 181,474 of 206,019 launches from the creator's own first-block trade, which is that same transaction. 24,545 launches and 1,529 confirmed graduations — WOFI among them — had those trade rows pruned before the column existed and are permanently unbacked here; they are recoverable only from an archival node. A NULL means we did not record a signature. It never means the launch has no creation transaction, and it is not a statement about the launch at all. The assurance above still overstates the position for those rows.
-
zero-buyers-ungated
What was wrong. The rule that flags a launch for having no outside buyers was never made conditional on the curve having completed. It was written for graduations and applied to every launch, including the great majority that simply die without a buyer, which is the ordinary end of a token and not evidence of manufacture.
What a reader would have concluded, and what was done
What a reader who trusted it would have concluded. Up to 34,242 launch records were in a state where a page could say the token completed its bonding curve with zero outside buyers, and that its graduation was funded by the creator rather than by demand. For a launch that never completed a curve the first statement is false and the second asserts conduct the record does not establish.
What was done. The rule is now gated on confirmed completion. Launches carrying a danger flag fell from 866 to 457, which is a correction and not a change in the market.
Each correction is also a row in record.db under its own citable id, so any copy of the file carries the corrections with it. Amending one means adding a row that names it; nothing here is ever silently reworded.