Reports

Evidentiary report on a single launch where the launch-record tests did not fire

Published 15 September 2026. Every figure below was read on 2026-09-12 from the two files section 7 names, by the session that wrote this document, and none is recomputed when this page is built. Section 9 is the only later text: it lists, with dates, what has moved since the read that bears on a figure here. The live view is here.

This is a specimen. It is the published version of an internal report of the same date, on a launch nobody commissioned, selected for completeness of record (the selection is step 1). A commissioned report has the same structure and discipline, is scoped to the client's subject under a written engagement, is dated, addressed and signed, and carries in full the per-wallet particulars that section 8 lists as withheld here. The method is published and never varies by customer. Engagements.

Subject: mint 5NP3pTMgbvioJaki2Sdxm7DiaA2tt3BFkqTJyYNF5EwQ, name and symbol PurpDrop, venue pumpfun, created 2026-09-09. This document accuses nobody, and section 6 states precisely what that does and does not mean. The internal version is retained unaltered; section 8 lists every excision and the reason, so that nobody reading this document mistakes it for the complete one.

Why this version exists. The internal version's section 4 named individual wallet addresses, including the address whose buy completed the curve, and set each one beside this archive's own seeded and buyout vocabulary and a funding cluster written into the register after the launch. Every individual clause of that was a measurement. Assembled on a page whose finding is that nothing fired, about a launch nobody is accusing, it functioned as an accusation against a named address. The governing rule, decided 2026-09-11: what is true about this launch may be published; what is true about a pattern of launches belongs in a commissioned document with a named recipient and a human in the loop. Section 4 below is therefore aggregate only.

Register discipline. This document records observations and the times they were made. It states no intent, no purpose, no identity behind any address, and no conclusion about conduct. Where a figure is not held, it is named as unknown together with the reason it is unknown. Labels in quotation marks (buyout, seeded) are values stored in this archive's own tables; they are internal vocabulary, defined mechanically where used, and they are not findings about anyone. Nothing below grades a person or an address.

All figures were read on 2026-09-12 from two files, both opened read-only with PRAGMA query_only=1:

immutable=1 on the collector database is a custody fact, not a convenience: that file declares WAL journalling and had live -wal/-shm sidecars beside it at read time, so every figure taken from it is as of its last checkpoint and any row committed since is outside this read. All times are UTC. All stored timestamps are milliseconds since the Unix epoch.

The criteria are read from assess() and cleanAtBirth in src/provenance.ts rather than assumed, so this report speaks in the same terms the site does. cleanAtBirth is the conjunction of: watched (the creation falls inside a recorded coverage window for its venue, and the launch is not late_discovery), no buyout (findBuyout: any single curve buy of BUYOUT_SOL = 40 SOL or more), dev_pct under MAX_DEV_PCT = 20, dev_sold falsy, a non-null curveBuyers of at least MIN_BUYERS = 30, completed (a graduated_confirmed_by value or a known pool, never the vSOL inference alone), a curve life longer than MIN_GRAD_MS = 60,000 ms, and no FINDINGS-class flag from the launch-record tests (that class was named DANGER until the vocabulary migration of 2026-09-14; section 9). The liquidity test is deliberately not part of cleanAtBirth, because a balance decays; see section 6.

The funnel, over the collector database's 206,019 launch rows at read time: graduated_confirmed_by IS NOT NULL → 7,045; plus late_discovery = 0, never rebuilt, a creation signature on file and a captured metadata document → 3,231; plus curve_buyers >= 30, dev_pct < 20, dev_sold = 0 and a curve life over 60,000 ms → 160. Those 160 were then screened on four things: whether the curve trade ledger is demonstrably complete, how soon after creation the off-chain document was captured, whether an image hash is held, and the size of the largest single curve buy. 36 of the 160 have a demonstrably complete curve ledger; 6 of those 36 also captured their metadata document within 60 s of creation. The subject is one of those 6, and was selected for completeness of record - not for any property of its participants, and not because it returned a negative in preference to some other launch that did not.

The completeness test, and why a naive one is wrong. curve_rows_dropped - the column that answers this directly - is empty on this launch. It was added on 2026-09-12, and for a launch finalized before that date it means "predates the column", never "nothing was dropped". Completeness therefore has to be established from counters instead: tokens.buys and tokens.sells are incremented in memory as curve trade events arrive and are independent of what the trades table retains. The creator's buy inside the creation transaction is written to trades by the create path and is not counted by buys, so a ledger holding every curve trade satisfies curve buy rows = buys + 1 and curve sell rows = sells exactly. A first pass of this screen compared non-creator rows against buys and wrongly rejected complete ledgers as six rows short; the corrected test is the one used below and in section 2.

peak_source was struck from the criteria because it is empty on this launch and on every row written before 2026-09-10, and is deliberately not backfilled. It is carried into section 6 as an absence instead. The two runner-up candidates are not named here: naming them would mean publishing the particulars on which each was rejected - one creator's supply share, one launch's unclosed watch window - which are adverse figures about launches this document does not otherwise report, with no commission behind them.

Every field below is read from the published record.

On publishing the creator's address - the decision, and the reason for it. It is published. Four reasons, and one thing it is not. (1) It is a chain anchor, not a characterisation. This section exists so that a third party can re-derive every figure here from the chain without trusting this archive's decoder, and the creator's supply share is not a checkable statement unless the report says whose share it is and in which transaction. (2) It is not new exposure. The address is in the creation transaction, which this report names by signature - a reader who wanted it would be one getTransaction away, and withholding it would be cosmetic rather than protective. It is also on the venue's own public launch page and on this project's own published page for this mint. (3) The finding attached to it is negative. The register rule forbids grading, intent and endorsement; it does not forbid identification. Nothing in this document characterises this address, states who controls it, or says what it was for. (4) Nothing in the register is juxtaposed against it. The creator's address carries no row in the operator register, no cluster, no funder and no wallet_flow row, so there is no pattern claim in this archive to set beside it. What it is not: the absence of a register row is not a clearance. It is a statement about this archive's record, at this date, under the sampling described in section 4 - not about the address.

What a third party can pull independently. The pump.fun program 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P emits the create and trade events this launch was decoded from, as Anchor Program data: log lines. The bonding curve account for this mint is EA9YV84ooPNR1Bnqi22WwBNY8YM1J5wrXicwaWiCZ2Jv, derived in the reading session as PDA("bonding-curve", mint) under that program by calling bondingCurveAddress in src/rpc-http.ts; its layout is discriminator 17b7f83760d8ac60, five u64s, then a complete byte at offset 48. The PumpSwap program pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA is the market the pool above belongs to.

Nothing in this section depends on this archive's decoder being correct: each figure names a transaction or an account a third party can fetch and decode independently.

When the collector was connected. The published record's runs table records the intervals during which a collector was subscribed to a venue's feed: 142 rows, 140 pumpfun and 2 launchlab, of which 4 carry no stop time. Four intervals contain this launch's creation. Two are bounded and each covers the launch whole:

This launch therefore sits wholly inside a single unbroken subscription - twice over, in two independently bounded intervals - and not merely inside a merged window. No collector restart occurs anywhere across its curve life. observationSpan in src/provenance.ts returns spans: true for it: the coverage covers the whole of the launch record and not only its creation.

Four custody defects in the coverage record itself, stated plainly. (1) Four intervals are unbounded, and two of them contain this creation - the archive carries intervals it cannot bound, overlapping the ones it can, so a query for "which subscription contains this creation" returns four answers, two of them unbounded. (2) The intervals overlap because more than one collector writes to the same table, and the table does not say which process wrote which row, so "who was watching" is answered by inference and not by the data. (3) runs records feed subscriptions only: the image fetch and the pool balance reading are not represented in it, so for those figures the archive holds a capture time but no record of what was connected when they were taken. (4) The collector database carries no build, version or provenance stamp of its own; the published record does carry a full build stamp, which is the stronger of the two.

How each class of figure was captured. Creation, creator, supply share and the creation signature and slot are decoded from the program's create event. Individual curve and AMM trades are decoded trade events, batched to trades. The live counters (buys, sells, volumes, unique_buyers, curve_buyers, bundled_buyers, snap30_*) are counted in memory as events arrive, independently of what trades retains. Graduation is flagged when a decoded trade reaches the curve threshold or reports a pool; graduated_confirmed_by = 'pool' is set where a pool address had been discovered for the mint. The pool balance (vault_sol, vault_at) is read from the pool's vault accounts, and vault_at is when the read happened, never inferred. The metadata document (meta_at, meta_bytes, meta_sha256) is an HTTP fetch of the uri, hashed over the stored UTF-8 bytes; the image is a separate HTTP fetch of the image URL. The published outside-buyer count is one SQL expression, gated on ledger completeness. Cluster and funder rows are RPC tracing of a wallet's first incoming SOL, then sampling of that payer's outgoing transfers.

How complete the trade ledger is. The published column first: curve_rows_dropped states this directly - 0 means the complete watched ledger is present, a positive number means that many rows were sampled from the middle, empty means the launch predates the column or was never finalized. For this launch it is empty, and the cause is that the launch predates the column. That is not a guess: the published record carries a value for it on 7,861 of 288,092 launches, so the column works - its emptiness here is the launch's age, not the column's failure. The report therefore cannot cite it, and says so rather than reading its emptiness as a zero.

What can be cited instead is an exact reconciliation against counters that retention cannot reach. Two reductions apply to the trades table and neither touched this launch's curve rows. (a) Truncation at finalize did not apply: finalizeTokenTrades deletes all but the first and last N curve rows unless keepAll is set, and keepAll derives from a term that includes t.graduated - this launch graduated, so it was true on that term alone. The retained row counts show the same thing arithmetically:

The SOL figures reconcile to the last recorded digit: retained curve buy SOL is 353.728569137, which is buy_vol_sol 353.234741978 plus the creation buy of 0.493827159 exactly; retained curve sell SOL equals sell_vol_sol to all nine digits. The retained curve rows span the creation millisecond to the graduation millisecond - the whole curve life - and the largest interval anywhere in that span with no curve trade row is 384,214 ms (6 m 24.214 s). (b) Age-based retention has not reached this launch, and no longer threatens its curve: since 2026-09-12 the pruners exempt the entire curve ledger of any launch carrying graduated = 1 or a graduated_confirmed_by, which this launch does, so on the present policy its curve rows are exempt permanently. The 2,385 retained AMM rows are exempt only where their wallet took a 40+ SOL curve buy on the same mint, which none did. One row exists in legal_holds, carrying its own note that it is a verification test and not a real hold; no hold is open on this launch.

The archive's own published test agrees, and that is the strongest form this statement takes. The record publishes an outside-buyer count only where the trade rows are demonstrably all still present - at least as many surviving curve-buy rows as the buys counter recorded live - and publishes nothing otherwise. 729 ≥ 728, so this launch's count of 428 is published because the completeness test passed on it. In the published record read here, 150,369 of 288,092 launches publish nothing on that column instead.

Where the ledger is NOT complete: the post-graduation market. The 2,385 retained AMM rows run from 2026-09-09 09:02:33.189 to 13:53:42.765. The first of them is 1 h 06 m 04.147 s after the graduation timestamp, and the archive holds its own proof that AMM trades existed before it: a detector row written 13 m 35 s after graduation records "+26.5 SOL net, 132 buyers, 1.95x in 5 min, top buyer 8%". The AMM ledger for this launch therefore does not begin at the pool's creation and is a partial record of the market. The curve ledger is complete; the market ledger is not; and no count in this report is taken over AMM rows. The lifetime wallet population is not closed either: the collector database retains rows for 1,152 distinct wallets on this mint, while the published unique_buyers counter reads 1,241 - production went on watching after the local copy stopped. Any ratio taken over the 1,152 is a ratio over retained rows, not over the launch's lifetime participants. The 428 curve buyers are not affected - that population closed when the curve completed, and its ledger is complete.

Offsets below are from 1788938126154, the creation millisecond in the collector database, because every trade row cited carries its timestamp on that clock. The published record's own created_at is 1788938126027, 127 ms earlier (section 6 lists this and the other inter-copy disagreements). No offset in this table shifts by more than 127 ms under the other anchor, and no test outcome in section 6 changes under either.

Creator's activity on this mint, as retained - the complete set of rows, since the curve ledger is complete: curve buys 7 (1.229921 SOL), curve sells 0, AMM buys 1 (0.474249 SOL), AMM sells 0. Counts on the row, each checked against the retained rows: curve_buyers 428 = 428 distinct non-creator curve-buy wallets; buys/sells 728/475 = 729 − 1 creation row / 475; buy_vol_sol/sell_vol_sol reconcile as above; bundled_buyers 0 = no non-creator curve buy row in the creation slot or the next (earliest two are at +2); snap30_* 4/4/0/0.428904896 both ways; dev_sold 0 = 0 sell rows carrying the creator's address, on either market.

The pool balance, with the age of every reading. A balance is a reading with a timestamp, never a standing fact. Four readings of this pool existed in this archive at the read:

Rules this document holds itself to on these figures. The 105.4 SOL reading may not be quoted without its date, and may not be quoted without the readings that follow it - an earlier version of this report quoted it alone, which would have been the single most misleading sentence on the page. The published reading of 30.792441074 SOL was the freshest this archive held at the read, and it was 2 h 33 m old when this document was written; it is older than that now, and section 9 carries the freshest reading as of publication. Nothing in this archive supports quoting any of these as a present balance. The hourly series is not carried in the published record, so the trajectory above is reproducible from the collector database only (section 6). The consequence for the finding is in section 6: the published reading is below the liquidity threshold, and the liquidity test fires on it.

What this section is, and why it holds no addresses. It reports, in aggregate, how many of this launch's buying wallets this archive had already recorded as sharing a funding source, and when those records were written. It names no wallet, no cluster and no funder. It makes no statement about who controls any address, about coordination, or about purpose. Absence of a record here is not evidence of anything, and presence of one is not a finding about anyone. The internal version named these addresses individually, including the one whose buy completed the curve; that is withheld here for the reason at the head of this document. Cluster names are withheld for a second reason worth stating plainly: a cluster name in this archive is the first six characters of the funding address, so publishing one publishes a searchable fragment of an address, not a label.

The register these aggregates were joined against was withdrawn from publication the day after the read, and that bears on every count below. On 2026-09-13 the correction operator-graph-infrastructure recorded that roughly 30% of the register's wallets sat under funders whose on-chain activity matches trading or exchange infrastructure - shared plumbing, not a shared operator - and a further 32% could not be behaviourally confirmed either way. The tables are withheld from every edition while the layer is re-derived under a stricter rule. The counts below are therefore counts of rows in the register as it stood on 2026-09-12, not validated groupings, and they are no longer reproducible from the published record. They are kept in this specimen because a commissioned report must show where its evidence later moved, not hide that it did; a report issued today would compute this section against the re-derived layer or state that none exists.

The population. 1,152 distinct wallets hold a retained trade row on this mint; 950 of those have a buy row, 866 a sell row; 428 distinct non-creator wallets bought on the bonding curve; the published unique_buyers counter reads 1,241 (it exceeds the retained 950 - section 2). The 428 is the population this section reasons over, because it is the only one that is both closed (it stopped growing when the curve completed) and complete (section 2). Concentration among the 428, over the complete curve ledger: the largest single wallet bought 17.811902 SOL, 5.05% of the 352.498648 SOL of non-creator curve buys; the top ten bought 17.812, 10.522, 9.191, 8.395, 7.901, 6.985, 6.859, 6.123, 4.889 and 4.889 SOL.

The creator had no row in the operator register, holds no wallet_flow row, and is the creator of 1 of the 288,092 launches in the record read - this one. What the archive holds about this address is therefore this launch and nothing else. That is a statement about this archive's record, not about the address, and specifically not a clearance: the register is built by tracing and sampling, and a wallet it has not reached is a wallet it has not reached.

How many of this launch's buyers appeared in the register as it stood. Over the 428 - the closed, complete population: 11 of 428 (2.6%) appeared, across 6 named funding clusters with 4 rows carrying no cluster; the largest number in any one named cluster is 2; 5 carried role = 'buyout' (a 40+ SOL curve buy on some other launch) and 6 role = 'seeded'; 6 of the 11 rows were written before this launch's creation and 5 after; a funding time (seeded_at) was known for 1 of the 11. Over the wider 1,152 wallets with any retained row: 16 appeared, across 10 clusters, largest cluster contribution again 2, 8 of 16 written before the launch, 1 of 16 with a known funding time, and 1 of 16 carrying a wallet_flow row - built from a curve outright on a different launch, and a record about that launch, not this one.

What these aggregates do and do not support, stated at the strength the data carries. Six named clusters touched this launch's curve and none of them contributed more than two wallets to it. That is the whole of it. This report draws no conclusion from those numbers in either direction: it does not say that eleven register wallets among 428 buyers is many or few, because it holds no baseline - the distribution of register overlap across comparable launches is a statement about a pattern of launches, and under the rule at the head of this document it belongs in a commissioned document with a named recipient.

Two limits that apply to every number in this section. (1) seeded_at is unknown for 10 of the 11, and for 15 of the 16: archive-wide it was populated for 2,784 of 26,251 register wallets at the read. The comparison a litigator would ask for - when each wallet was funded, set against the launch time - cannot be made from the data held. added_at is a substitute answering a different question: when this archive wrote the row, a fact about the record and not about the address. (2) Five of the eleven register rows were written after this launch happened, from a funding sample taken after this launch happened. A record created later cannot be evidence about an earlier event, and this report does not use it as any.

The metadata document the launch pointed at, as captured. Read from the published record except where marked.

Claims inside the stored document, as parsed onto the row: name and symbol PurpDrop; description "Hold and earn $PURP"; a website URL stated twice, once at top level and once under extensions; createdOn names the venue; showName true; an image URL at gateway.irys.xyz/6dKgvPzPtyEh4p5ECfm9AVhXjVk2QZLLsw4kXEA3j5p1. twitter and telegram are absent from the document - the columns are empty, distinguishable from "never looked" because meta_at is present. The document itself is 371 bytes, held by the collector and served beside the launch's page; it is deliberately not carried in the published record (below).

The stored hash was re-derived at the read rather than quoted: the 371 stored bytes were piped to shasum -a 256 and returned 76d15cc3504a4974dc315cb000ffb7714eaff5ee59537e7f595168191462e73e, byte count 371, identical to the meta_sha256 published in the record. The commitment is internally consistent, independently of this archive's own hashing code path, and consistent across both files.

The image, and two independent retrievals. image_sha256 093f8bcf652cf53081e7bf366bff20448ca6dde2d3180e568d953e42ab12c75d and image_bytes 7,846 are identical in both files; image_at differs - 2026-09-09 08:15:52.918 in the published record against 2026-09-09 21:24:50.579 in the collector. These are two separate fetches of the same URL, 13 h 08 m 57.661 s apart, and they hash to the same value - the image bytes served under that URL were unchanged across that interval. It remains weaker than the metadata commitment, and the difference matters: the metadata document was fetched 1.441 s after the creation transaction, the earliest image fetch 1 h 00 m 27 s later. The metadata hash commits to bytes served at the moment of launch; the image hash commits to bytes served an hour in, and whether those were the bytes served at launch is unknown.

What a hash captured at launch permits that a later retrieval does not. Both URLs are served by a gateway a third party operates, and an HTTPS host can serve different bytes under the same URL at any time with no record that it changed. A sha256 recorded at a stated time converts an unverifiable assertion - "the document said X at launch" - into a checkable one. Anyone who later comes into possession of 371 bytes claimed to be this document, from any source, can hash them and compare: a match establishes that those are the exact bytes this archive read 1.441 s after the launch existed. A retrieval performed today establishes only what the URL serves today and cannot distinguish an unchanged document from a replaced one. The hash also survives the document: if the URI stops resolving, the commitment remains.

The limits of that, stated. The hash commits to bytes, not to authorship. meta_sha256 is computed over the UTF-8 bytes as stored by this archive rather than over the raw HTTP response, so it certifies what this archive received and retained. This particular uri is a gateway path keyed to a storage-network transaction id, which is content-addressed at the source - a property of that storage network, not something this archive verified. And the published record carries the hash while deliberately not carrying the document: at roughly a kilobyte per launch, carrying documents would multiply the file against the archive's whole volume. The consequence for a commissioned report is that the document quoted above is reproducible from the collector database, not from the published record. Correction overstated-unrecoverability (2026-09-11) bears directly on how strongly that may be put: the on-chain events behind sections 1 and 3 are permanently re-derivable from an archival node, and only the off-chain document behind a creator-controlled URI is genuinely unrecoverable once the URI changes.

This is the most important section in this document. A report whose finding is negative is worth only as much as its statement of what the negative excludes. A reader who takes anything from this document and not from this section has taken the wrong thing.

What the finding is, exactly. cleanAtBirth returns true for this launch. That was measured rather than reasoned: assess, cleanAtBirth, coverageFor and observationSpan from src/provenance.ts were imported and run against this row, returning watched: true, completed: true, curveBuyers: 428, buyout: null, cleanAtBirth: true. cleanAtBirth is a claim about the launch's birth and nothing else. The code says so in its own comment: "Facts about the past: once true, always true. The liquidity gate is deliberately NOT here - it decays, so the caller applies it against a balance it has just read." The renderers settle the birth claim before any pool reading is allowed to add a flag, and that ordering exists because mixing the two once produced a live disagreement between two pages of this site.

The seven named tests, with the margin by which each did or did not fire. (Classes here are as they stood at the read; the vocabulary and one class changed between read and publication - section 9.)

The liquidity test fires, and this document says so in its own headline section. Four tests were applied to evidence and did not trip. One could not fire because its precondition is absent. One was not evaluated. One fires. The renderers push a thin_pool_now flag whenever a reading exists and is below MIN_POOL_SOL, and - this is the part an earlier draft of this report got wrong - they do so regardless of the reading's age. Freshness changes only the sentence's wording, never the flag. That flag is tagged kind: "liquidity" and is pushed after cleanAtBirth is computed, by design, so it does not alter the birth finding. Both statements are true at once and neither may be quoted without the other: about its birth, no launch-record test fired on the evidence recorded; about its pool as last read, the balance was below the liquidity threshold, and the test on that reading fires.

Therefore. (1) The birth finding means no test in a published list fired on the evidence recorded - a statement about the intersection of a list of tests and a body of evidence, both enumerated above. (2) It is not a certificate: certification additionally requires a pool reading under five minutes old holding at least 40 SOL; the newest reading is hours old at any moment this document is read, and it is below 40. This launch is not certified and this document does not certify it. (3) One test was not evaluated and one could not fire, and neither is "passed." (4) One of the seven fires, and a document headlined on a negative that omitted this would be misleading. (5) It is not an endorsement, not advice, and not a statement about any person's intent or purpose: supply shares, buyer counts, timings, balances and hashes are measurements, and nothing here says what any of them was for. (6) It is not a statement about the future or about any later moment: every balance in this document is a reading with a time. (7) It is not a completeness claim about the whole record: the curve ledger is complete, the AMM ledger is not, and the archive proves that against itself. (8) It carries no identity behind any address, including the creator's: a shared funding source is a record of a traced or sampled on-chain funding relationship and nothing more; it does not establish common control, agency, or that the same party operates two addresses. (9) Coverage bounds observation, not existence: a launch outside a coverage window is unobserved, never absent - and four of this archive's coverage intervals are unbounded. (10) It is not a statement about any other launch: section 4 is aggregate precisely so that this document cannot be read as one.

Three limits of the tests themselves, which the finding inherits. (1) findBuyout tests the largest single curve buy, not a wallet's total. On this launch one wallet made two curve buys 1.210 s apart totalling 17.811902174 SOL - 44.5% of BUYOUT_SOL - of which the larger was 9.777778 SOL. Under the published test, no buyout exists. Under a test on per-wallet totals, still none. Under a test at any threshold below 17.812 SOL, one would. The figure is stated, without the address, so that a reader applying a different threshold is not misled by this one. (2) bundled_buyers counts the creation slot and the next slot only. Its stored 0 is reproducible from the rows, and the two earliest non-creator buys are in creation slot +2, 760 ms and 769 ms after creation. That is 0 under the published heuristic and two buys inside a second under any reading; both are stated. (3) thin_pool_now ignores the age of the reading it fires on. The flag above rests on a reading taken 2026-09-12 15:21:16 UTC. It says what the pool held then, not what it holds now.

Every empty field on this row, with the cause that applies. A field that is knowably wrong is worse than a missing one, and an empty field read as a zero is the same defect.

Internal disagreements in this record, reported because a report that cited either side without the other would be citing a figure this archive cannot stand behind. (a) Between the two files: created_at differs by 127 ms, graduated_at by 158 ms, curve life by 31 ms, meta_at by 50 ms, meta_lag_ms by 77 ms; image_at differs by 13 h 08 m because it records two separate fetches (section 5); unique_buyers 1,241 against 950 retained buying wallets because production watched longer; vault_sol differs because the two files hold readings three days apart. curve_buyers (428), dev_pct, bundled_buyers (0), snap30_buyers (4), dev_sold (0), meta_bytes, meta_sha256, image_bytes and image_sha256 are identical in both files. No test outcome changes under either clock. (b) Within the row: peak_price reads 1.44620816669537e-06 and a retained AMM buy row 1 h 55 m after creation carries that price to every recorded digit, yet peak_at reads the creation millisecond exactly - a recovery-path defect the codebase documents in its own words. The peak's value is corroborated by a citable row; its stored time is not the time of that row. And because peak_source is empty, the archive does not itself state which market the peak came from - the row match is this report's arithmetic, not a stored provenance. (c) Within the launch record: the pool row's created_at precedes graduated_at by 49 ms; both are written by the same handler from different clocks. A clock-provenance note, not a contradiction.

A correction owed to the draft, and why it is not a published correction. An earlier draft stated that thin_pool_now was "not evaluated" because no pool reading within five minutes existed. That was wrong, and it is corrected in the table above: the flag does not require a fresh reading. It is recorded here as a dated fix to a document rather than as a row in the corrections table, because the test for a published correction is whether a published figure was wrong - and none was: the site's own code applied the test correctly throughout; only this document described it incorrectly, and only in draft.

Corrections on file that touch figures cited above. All 10 rows in the record read on 2026-09-12 are accounted for; the three issued since the read are in section 9. Bearing directly: curve-buyers-undercounted (2026-09-12) is the correction that makes this report possible - the outside-buyer count had been recomputed over whatever trade rows survived retention, so dozens of launches were published as zero outside buyers; the remedy gates the count on completeness and publishes nothing otherwise, and this launch's 428 is published because that test passed on it. graduated-inferred (2026-09-09): this report never relies on graduated alone - it cites graduated_confirmed_by = 'pool', which is that correction's own remedy. uncheckable-figures (2026-09-09): this mint carries both a creation signature and slot, which is why it was selected; a report on a neighbouring launch might not be able to make section 1 at all. curve-check-rate-unsplit (2026-09-11): this mint's unread curve is a consequence of the sweep's targeting and not a property of the launch. overstated-unrecoverability (2026-09-11): the verification table in section 1 is possible because the chain events remain re-derivable; only the off-chain document is genuinely unrecoverable. The remaining five rows (zero-buyers-ungated, graduated-not-asserted-when-disproved, disproved-conflated-with-unreadable, reconstructions-published-unqualified, disproved-fix-did-not-travel) were checked and bear on no figure here, for the reasons a reader can verify on the corrections page.

Every query was run read-only (PRAGMA query_only=1), against the published record built 2026-09-12 14:01:05 UTC (built_by names the collector's own build path; row counts at the read: tokens 288,092, of which 9,490 confirmed graduations and 150,369 with no published outside-buyer count; runs 142; corrections 10) and against the collector database (tokens 206,019; trades 3,589 for this mint; WAL, read at its last checkpoint). Throughout, :M is the subject mint, :C = 1788938126154 (the collector's creation millisecond), :CS = 445551606, :W the creator's address. The queries are printed so that anyone holding either file can run them and get the same answers for that date; the collector database is not published, so the rows behind sections 2–4 reproduce from it under engagement rather than from the public file - and the chain anchors in section 1 reproduce from the chain with no file of ours at all.

Source files whose behaviour is asserted above, for a reader checking the description against the code rather than against this prose: src/provenance.ts (the tests, thresholds, coverage and retention fragments), src/operator.ts (findBuyout), src/tracker.ts (the live counters), src/db.ts (the trade writer, finalize and the peak_at defect), src/servicedb.ts (the completeness gate and what the record deliberately does not carry), src/schema-doc.ts (the column causes quoted in section 6), src/serve.ts and src/site.ts (the liquidity flag and its ordering against cleanAtBirth), src/confirm.ts (curve readings), src/clusters.ts (funder tracing and seeded_at), src/rpc-http.ts (bondingCurveAddress), src/images.ts (image hashing).

This section exists so that a reader of the internal version can see exactly what the public version does not say, and so that nobody mistakes this document for the complete one. Each item below is held internally and is available in a commissioned document with a named recipient and a human in the loop.

One thing was added rather than removed, and it runs against the document's own headline: section 6 reports that the liquidity test fires on the record's pool reading, and that an earlier draft wrongly described that test as unevaluated. A report that is published because it can return a negative has to be the first to say where a test does fire.

The figures above are frozen at the 2026-09-12 read. Four things have moved since that bear on them, each dated:

Unchanged at publication, checked against the live record: the outside-buyer count of 428 is still published (the completeness gate still passes), the curve account remains unread (the sweep still has no cause to select a pool-confirmed graduation), and no correction on file touches any launch-record figure quoted here.

What this document is. A record of one launch, and of the limits of what this archive observed of it. It records; it does not adjudicate. It says what was measured and when, and it says what is not known and why. It is not a certificate, not an endorsement, not advice, and not a statement about anyone's intent, conduct or future. A commissioned report is this structure, scoped to the client's subject, with the particulars section 8 withholds. Engagements · The published method · Corrections