Data

The record database

The launch record as one SQLite file: the same database the service reads, rebuilt with every record build. It is licensed data, downloaded with an API key. Its schema, sample rows and the queries behind our figures are published below, so what you would be buying can be checked before you buy it.

Download

579.9 MB

Download	curl -H "Authorization: Bearer $COT_KEY" -o record.db https://chainoftitle.org/data/record.db: SQLite, 579.9 MB, one row per launch
Launches	521,493 observed from the creation transaction, in 529,620 records. The difference is launches a detector restored after the fact or rebuilt from chain history: real records, but not first-block observations.
Coverage	from 2026-09-02 12:29 UTC, 46 min of recorded downtime
Licence	the Chain of Title data licence (terms).
Rebuilt	with every record build, about every three hours. operator_wallets and operator_funders returned to the licensed record on 17 Sep 2026 under the re-derived funder graph (corrections operator-graph-infrastructure and operator-graph-republished); member counts are net of stated infrastructure exclusions. The build time is in its meta table.

Tables: tokens (the launch record), trades and hist_trades (curve buys large enough to be a buyout), pool_map, corrections, and runs (the coverage windows, so you can check what we were awake for). The licensed record adds wallet_flow; operator_wallets and operator_funders are carried under the re-derived funder graph, as above.

The collector's own database is around 7 GB and is not this. It holds every trade on every tracked token and exists to derive the record; it is a research instrument on a retention window, not the archive.

The pictures, and why most are missing

Every row carries the image URL the launch declared. image_sha256 carries the sha256 of the bytes themselves, when we hold them: the proof rather than the picture, so the archive stays a file of manageable size. On most rows that hash is NULL, and it means we did not fetch the image. It does not mean the launch had none: that case is a NULL image with meta_at set, which is a different statement and stored differently on purpose.

We fetch the bytes for launches that completed their curve. The reason is arithmetic rather than judgement. Around 24,000 launches a day declared an image when this was measured, on 2026-09-11, and they average 409 KB, which is 13.6 GB a day, the whole storage volume every 33 hours. Graduations run near 1,400 a day, about 570 MB, and that is what can actually be kept. Pictures are stored by content hash, so the many launches reusing the same image cost one copy.

This is a gap in the archive and naming it is the point. The image is the one thing here that cannot be rebuilt from chain by anyone willing to pay for archival RPC: it sits behind a pin the operator can drop. If that happens to a launch we did not fetch, the picture is gone and this file will not have it. The URLs are all in the record and nothing stops you fetching them yourself. The only reason we did not is that we could not afford the disk.

When a launch names a person

Some launches write a handle into their own metadata. In this file 12,921 descriptions contain an @ and 1,871 link to x.com or twitter.com, out of 252,881 descriptions in total. They are published exactly as the launch wrote them.

The reason is that those are the creator's words, not ours and not the named account's. When a launch claims someone is behind it, that claim is the evidence, and when the claim is false it is usually the only surviving evidence that the impersonation happened at all. A launch can be edited or unpinned at its source; what it said at the moment we read it cannot be recovered anywhere else. Redacting the sentence would remove the thing a reader most needs from the record.

A handle appearing in this file is not a statement by us about the person who owns it. We do not say who is behind a launch, and we publish no conclusions about intent. If a launch used your name, tell us and we will publish your statement on that record.

What is in the file

generated from the record itself

Read off the published file at build time, not maintained by hand, so this cannot drift from what you download. The kind matters more than the type: it says whether you could reproduce the value yourself, and whether it is a fact or a snapshot.

Kind	Meaning
live	recorded at the creation transaction; not readable from the token's present state afterwards
chain	reproducible from chain history by anyone
reading	one measurement, carrying the moment it was taken
ours	our own bookkeeping or an aggregate we computed
opaque	computed from data that is not in this file, so you cannot check it here

Anything marked opaque is a defect on our side, not a category we are content with: this file is meant to carry its own evidence, and a number you cannot check against it does not belong in it. There are none in this build. Every figure here can be recomputed from rows in the same file.

tokens

43 columns

One row per launch. This is the record.

Column	Type	Kind	What it is
mint	text	chain	The token's mint address. Primary key.
name	text	ours	Name the launch declared off-chain. The operator can change it after launch; this is what it said when we read it.
symbol	text	ours	Ticker the launch declared. Tickers collide constantly and are not an identifier; use the mint.
creator	text	live	Wallet that sent the creation transaction.
created_at	integer	live	Creation time, epoch ms.
late_discovery	integer	ours	1 when we found the token after it was already trading, so its first block was never observed. A launch with this set never reads as no markers found.
dev_pct	real	live	Percent of total supply the creator held after the first block. The single most load-bearing number in the file.
dev_sold	integer	ours	1 if we saw the creator sell while watching. 0 means we did not see it, which is not the same as it not happening. Recorded only where the venue's trade events name the wallet that traded; NULL where they do not, which is not zero and not a clean result. See venue.
unique_buyers	integer	ours	Distinct buyers across the token's whole life, INCLUDING post-graduation market buyers. This is NOT the outside-buyer count the markers use; use curve_buyers. Recorded only where the venue's trade events name the wallet that traded; NULL where they do not, which is not zero and not a clean result. See venue.
curve_buyers	integer	live	Distinct wallets, not counting the creator, that bought on the bonding curve. NULL means unknown, which never certifies as clean and never accuses. Unknown has three causes and none of them is zero: we did not watch the launch; we watched it on a venue whose trade events carry no wallet; or the launch predates 2026-09-12 and its trade rows had already been sampled at finalize or pruned by retention before anything counted them, so any count over the survivors would be a floor. From 2026-09-12 the collector counts these live as the trades arrive, which no sampling or retention can reach. For earlier launches the rows are counted only where at least as many curve-buy rows survive as the buys counter recorded, which is the test for their being all still present. This is the column an absence hurts most - zero outside buyers is the strongest thing this archive says against a launch - and it was published from the absence of rows we had deleted ourselves: see the curve-buyers-undercounted correction.
snap30_buyers	integer	live	Distinct buyers within the first 30 seconds. Meaningful only for an observed launch. NOT a bonding-curve count: like unique_buyers it is taken from the whole buyer set, so for a launch that left the curve inside those 30 seconds, or that we picked up again after it was already trading on a market, it includes market buyers. 366 launches in this archive carry a snap30_buyers above zero and recorded no curve buy at all, which is that case and not a contradiction. Do not use this column to check curve_buyers - two sessions reading this archive did, and read a buyout with market interest afterwards as a curve with hidden buyers. bundled_buyers is curve-only and is the column for that. Recorded only where the venue's trade events name the wallet that traded; NULL where they do not, which is not zero and not a clean result. See venue.
bundled_buyers	integer	live	Buyers landing in the creation block itself, bought before anyone outside could have seen the token exist. Recorded only where the venue's trade events name the wallet that traded; NULL where they do not, which is not zero and not a clean result. See venue.
graduated	integer	ours	1 if the curve is recorded as having completed: an inference from decoded trade volume, not a reading of the curve. Measured 2026-09-09: of rows where graduated_confirmed_by IS NULL, the curve account was read directly and returned complete=0 on 5,187 of them. Count graduations with graduated_confirmed_by IS NOT NULL; this column alone overstates them by about three quarters.
graduated_at	integer	ours	When the curve is recorded as completing, epoch ms. Subject to the same caveat as graduated.
pool	text	chain	The PumpSwap pool address, once discovered. NULL is not evidence a curve did not complete: pool discovery has its own coverage gaps.
vault_sol	real	reading	SOL in the pool at the last successful read. One value, not a history. Always read it with vault_at.
vault_at	integer	reading	When vault_sol was read, epoch ms. A balance without its age is not a fact. These two move together or not at all.
last_price	real	ours	Last price we decoded for the token, in SOL per token. Present for research; the site makes no claim from it. NULL where the launch's curve is not quoted in SOL (see quote_mint): a quantity of some other asset published in this column would be read as SOL, and 0 would be read as a token that trades at nothing.
rebuilt_at	integer	ours	When we reconstructed this launch from chain history rather than watching it, epoch ms.
rebuilt_complete	integer	ours	1 when a rebuild read the curve's entire transaction history. 0 or NULL means signature paging hit its cap or transactions could not be fetched, so the rebuild is partial and its counts are floors.
updated_at	integer	ours	Last time any field on this row changed, epoch ms.
venue	text	chain	Which launchpad the token came from, as the collector's own venue id. It decides what else on this row can exist: a venue whose trade events name the trading wallet supplies dev_sold and every buyer count, and one whose events name only a pool supplies none of them, leaving those columns NULL. The creator, the share of supply, the launch's own claim about itself and whether the curve completed are recorded on every venue. Coverage in `runs` is per venue too, so a launch is answered as watched only against windows recorded for its own venue.
graduated_confirmed_by	text	ours	How graduation was confirmed: 'pool' (a PumpSwap pool was found), 'curve_complete' (the venue's own completion state: the bonding curve account's complete bit, or a pool status field the program emits with its trades, which is the same authority), or NULL for an inference from decoded trade volume that nobody ever confirmed. NULL means we say less, never that we say the opposite, but it is not neutral: where the curve account has since been read, the great majority of NULL rows returned complete=0. This column, not graduated, is the graduation flag.
create_sig	text	live	Signature of the transaction this launch was decoded from: the one carrying the creator's initial buy, and therefore the transaction dev_pct is computed from. Fetch it and you can check every launch figure in this row against the chain rather than trusting us. NULL means we did not record one: the launch predates the column (2026-09-09), or we found the token late and never saw its creation, or its trade rows were pruned before the backfill reached them. NULL is never a claim that no creation transaction exists.
create_slot	integer	live	The slot create_sig landed in. Present exactly when create_sig is.
uri	text	ours	Metadata URI the launch declared.
image	text	ours	Image URL from that metadata. A NULL here with meta_at set means the launch declared no picture, a different statement from us not fetching one.
description	text	ours	Description the launch declared off-chain, at the time we read it.
meta_at	integer	ours	When we read the off-chain metadata, epoch ms. Set with a NULL image means the launch genuinely declared none.
image_sha256	text	ours	sha256 of the image bytes, when we hold them: the proof rather than the picture. NULL means we did not fetch it, which is a disk-budget decision and not a finding about the launch.
image_bytes	integer	ours	Size of the fetched image in bytes.
image_at	integer	ours	When the image bytes were fetched, epoch ms.
curve_checked_at	integer	reading	When we last read this token's bonding curve account directly, epoch ms. NULL means we have never read it, not that anything was found. Read this column before curve_complete: together they distinguish four states, and only two of them say anything about the token.
curve_complete	integer	reading	The curve account's own `complete` bit at curve_checked_at. 1 = we read the account and the curve had completed. 0 = we read it and it had not. NULL WITH a curve_checked_at = the account no longer existed when we looked, which tells you nothing about whether the curve filled. NULL WITH NO curve_checked_at = we never looked. A 0 here is a direct observation and is the basis for the correction against `graduated`; the two NULL cases are our coverage and are never evidence about a launch.
meta_bytes	integer	ours	Size of the metadata document as served, in bytes. The document itself is kept by the collector but is not published here: at roughly a kilobyte a launch it would add tens of megabytes a day to a file whose whole point is its manageable size. This column is what lets you tell 'we never fetched it' from 'we fetched it and it exists'.
meta_sha256	text	live	sha256 of the metadata document as we received it at launch: the commitment, not the document. The document itself stays in the collector because publishing it would add tens of megabytes a day to a file whose value is its manageable size. This lets anyone who later obtains that document prove it is the one we read, before the creator could repoint the URI. NULL means we hold no document to commit to.
meta_lag_ms	integer	ours	How long after the launch we read its document: meta_at minus created_at, in milliseconds. Derived from the two columns beside it on this row, never copied, so it cannot disagree with them. This is what separates a document captured as the launch happened from one recovered days later. The URI belongs to the creator and what it served on the 10th is not necessarily what it served on the 2nd. The distribution is sharply bimodal and deliberately not thresholded here: 80,448 rows under a minute, 2,174 in the whole span from one minute to a day, and 69,597 over a day. Any cut a reader picks between ten minutes and a day selects the same population, which is why we publish the measurement instead of a boolean built on a threshold we chose.
peak_price	real	live	The highest price we ever observed for this launch, in SOL per token. A peak only ratchets, so unlike a pool balance it is permanent once true, which is why it is published and last_price, which carries no timestamp, is not. Read it as a floor rather than a measurement: it is what we SAW, so a spike between observations is not here, and a launch we stopped following has a peak that stops with us. Multiply by 1e9 for an implied market cap in SOL, against the roughly 411 SOL at which a pump.fun curve completes.
peak_at	integer	live	When that highest price was observed, epoch ms. The peak is only a fact with the moment attached, exactly as vault_sol is only a fact with vault_at; the record refuses to publish either half alone.
peak_source	text	ours	Where the peak came from. 'curve' or 'amm' mean we decoded an on-chain transaction that executed at that price. 'external' means a third-party price feed reported it and no trade was witnessed, which is a materially weaker claim and the one that produces peaks this archive cannot corroborate: of the four largest peaks on file, two hold a pool with zero decoded AMM trades and an implied cap over 2.9M SOL, while the two beside them are backed by 122 and 211 trades and reconcile exactly. NULL means we did not record the source, which is every row written before 2026-09-10, and never that the peak was unsourced. Deliberately not backfilled: the source is knowable only when the price arrives, and inferring it later from whichever trade rows survived retention would be manufacturing provenance.
curve_account	text	chain	The account holding this launch's curve state, where the mint does not determine it. NULL is the pump.fun case and means the address is derivable: its bonding curve is a program-derived address computed from the mint, so anyone can recompute it and storing it would add nothing. A venue whose curve address is seeded with more than the mint - Raydium LaunchLab's pool takes the platform config and the quote mint as well - has it written down here, because it is otherwise unrecoverable and the curve could never be re-read. NULL is never 'we could not work it out'.
quote_mint	text	chain	The asset this launch's curve is priced in. NULL means wrapped SOL, which is every pump.fun launch and every row written before this column existed. A Raydium LaunchLab pool names its quote asset per pool and most name something else, in which case no SOL figure is published for the launch at all: last_price is NULL and no trade rows are written, because a quantity of some other token in a column named for SOL is how a 40 SOL rule fires on 40 of something else. The launch, its creator and its share of supply are recorded either way.
curve_rows_dropped	integer	ours	How many of this launch's bonding-curve trade rows THIS PROJECT deleted when the launch was finalized. Finalize keeps the first and last 100-400 curve rows and drops the middle, because trade rows are the bulk of the database and launch-time facts are the scarce material. Until 2026-09-12 that deletion left no trace, so a launch with 40 surviving rows looked identical to a launch that only ever had 40 - a difference that matters most to the reader who matters most, anyone citing the ledger as evidence. 0 means the complete watched ledger is present and is a statement of completeness, not an absence. A positive number means that many rows were sampled away, and which ones is knowable: the middle. NULL means the launch predates the column or was never finalized, never that nothing was dropped. It accounts for the finalize sample ONLY - retention prunes later and independently, so surviving rows can be fewer still; read this beside buys and say so. The trade that completes a curve is the last curve trade, and it was among the rows finalize deleted until 2026-09-12: see the curve-buyers-undercounted correction for what counting over the survivors published.

meta_checks

6 columns

The latest re-reading of each checked launch's document, against the launch-time capture. Confirmed graduations are re-read at 24 hours and 7 days; a rewritten document is kept beside the original in the collector. One row per checked mint.

Column	Type	Kind	What it is
mint	text	chain	The launch whose document was re-read.
checked_at	integer	ours	When the latest conclusive reading was taken, ms since epoch. A reading has a time or it is not a reading.
outcome	text	ours	'same': the address served bytes hashing to the launch-time meta_sha256. 'changed': it served different bytes, and a second immediate fetch returned the same new bytes. 'unstable': two immediate reads disagreed with each other - an address like that supports no claim about what it holds, and this row says so rather than picking one. 'gone': a definitive refusal (404 class). Transient errors are not published; they conclude nothing.
confirmed	integer	ours	1 when the change was confirmed by a second immediate fetch. Only a confirmed 'changed' may be described as a rewrite.
sha256	text	ours	What the address served at this reading, hashed the same way as the launch-time capture. Compare against tokens.meta_sha256 yourself. NULL for 'gone'.
changed_at	integer	ours	The first confirmed 'changed' reading ever taken for this mint, ms since epoch. Empty means no rewrite has been observed - which is a statement about our readings, not a promise about the document.

wallet_flow

5 columns

One row per wallet that has bought a curve outright.

Column	Type	Kind	What it is
wallet	text	chain	A wallet that has bought at least one bonding curve outright. One row each.
curve_sol	real	chain	SOL this wallet spent buying bonding curves.
amm_buy	real	ours	SOL this wallet spent buying back on the open market, on the curves it took. Sum the market='amm', side='buy' rows in trades for this wallet and you will get this number.
amm_sell	real	ours	SOL this wallet received selling on the open market, on the curves it took: the tokens it bought the float of, not everything it ever traded. Sum the market='amm', side='sell' rows in trades for this wallet and you will get this number. It used to count every token the wallet touched while the pages around it said 'sold after taking the curve'.
tokens	integer	ours	Number of curves this wallet took. Count the distinct mints in trades for this wallet and you will get this number.

trades

9 columns

Curve buys large enough to count as a buyout. Not every trade on every token.

Column	Type	Kind	What it is
mint	text	chain	Token traded.
wallet	text	chain	Wallet that traded.
side	text	chain	'buy' or 'sell'.
sol	real	chain	Size of the trade in SOL.
ts	integer	chain	When we decoded the trade, epoch ms. Events arriving together carry the same timestamp, so ordering within a batch is not established.
slot	integer	chain	Solana slot, where known.
market	text	chain	'curve' for a bonding-curve trade, 'amm' for one on the open market. This table holds two things and nothing else: curve buys large enough to count as a buyout, and the market trades those same wallets made on those same tokens afterwards. The second set is here so wallet_flow can be checked against it rather than believed.
is_dev	integer	chain	1 when the trading wallet is the token's creator.
sig	text	chain	Signature of the transaction this trade was decoded from. Fetch it and you can verify the buyout for yourself: the single fact this record states most seriously about a launch, and the one it should least ask you to take on trust. NULL where retention removed the row before this column existed (2026-09-09); never a claim that no transaction exists.

hist_trades

13 columns

Trades read from chain history during a rebuild, each with its transaction signature.

Column	Type	Kind	What it is
mint	text	chain	Token traded.
sig	text	chain	Transaction signature. Take this to any explorer and check the row yourself.
idx	integer	chain	Instruction index within the transaction.
ts	integer	chain	Block time, epoch ms. Read from chain history, so unlike trades.ts this is the real block time.
slot	integer	chain	Solana slot.
wallet	text	chain	Wallet that traded.
side	text	chain	'buy' or 'sell'.
sol	real	chain	Size in SOL.
tokens	real	chain	Token amount moved.
vsol	real	chain	Virtual SOL reserve after the trade: how full the curve was.
vtok	real	chain	Virtual token reserve after the trade.
is_dev	integer	chain	1 when the trading wallet is the token's creator.
rebuild_complete	integer	ours	Whether the rebuild this row came from read the WHOLE curve. 1 complete, 0 truncated, NULL not knowable in this file. These rows are reconstructions, and a rebuild that read a fortieth of a curve produces real trades and a false total: measured on the collector, 188 of 2,729 rebuilds were truncated, averaging 38.7% of their own history, and the undercount lands squarely on buyer counts and creator share. NULL is not a quiet 'probably fine' - it means this file was built from a source carrying no completeness metadata at all, which is how 1,072 buyout rows came to be published unqualified. meta.hist_trades_qualified says which of those two a given file is, and correction reconstructions-published-unqualified records the episode.

runs

7 columns

The coverage windows. What we were awake for.

Column	Type	Kind	What it is
id	integer	ours	Collector run.
started_at	integer	ours	When the collector started watching, epoch ms.
stopped_at	integer	ours	When it stopped, epoch ms. NULL means still running. Launches outside these windows were not observed; this table is how you check what we were awake for.
note	text	ours	Why the run started or ended, when we recorded it.
venue	text	ours	Which launch venue this window covers. A window says we were observing THIS venue; it says nothing about any other, and a launch on a venue absent from these windows is unwatched rather than clean. Every window recorded before 2026-09-11 is a pump.fun window and carries that value.
code_sha	text	ours	The commit of the collector code that ran this window. NULL means it was not recorded, which is every window before the column existed, and is not the same as a clean tree.
code_dirty	integer	ours	1 when the deployed tree had uncommitted edits, so code_sha names the nearest commit rather than the exact code that ran. NULL where code_sha is NULL.

pool_map

3 columns

Which PumpSwap pool belongs to which token.

Column	Type	Kind	What it is
pool	text	chain	PumpSwap pool address. Primary key.
mint	text	chain	Token that pool trades.
created_at	integer	ours	When we first mapped the pool, epoch ms, not when the pool was created.

operator_wallets

7 columns

Wallets grouped by who funded them.

Column	Type	Kind	What it is
wallet	text	chain	A wallet we associate with an operator cluster.
funder	text	chain	Wallet that funded it. Trading terminals fund users the same way a wallet farm funds its own wallets, so a shared funder is a lead, not a finding.
cluster	text	ours	Our label for the group. Ours, not the chain's.
role	text	ours	What this wallet appears to do within the cluster.
seeded_at	integer	chain	When the funder first sent it SOL, epoch ms.
source_mint	text	ours	The launch that first brought this wallet to our attention.
added_at	integer	ours	When we added the row, epoch ms.

operator_funders

15 columns

One row per funding address behind a cluster. operator_wallets carries the wallet-to-cluster edge; this carries the node it points at, which is the half of the attribution that takes continuous observation to build. A shared funder is a lead and not a finding, and `note` is where we say so.

Column	Type	Kind	What it is
funder	text	chain	An address that has funded wallets we associate with a cluster. The cluster label used across this site is the first six characters of this address: it is a name of ours, not an identity.
first_seen	integer	chain	The earliest funding transaction we observed from it, epoch ms.
last_seen	integer	chain	The most recent, epoch ms. Not an assertion that it has stopped.
txs	integer	chain	Funding transactions observed from this address, within our coverage only.
wallets	integer	chain	Distinct wallets it has sent SOL to. A large number is equally consistent with a wallet farm and with a trading terminal serving many customers; see note.
seeds	integer	chain	Fundings that opened a wallet with no prior balance, as distinct from topping one up.
sampled_at	integer	ours	When we last walked this funder's history, epoch ms. The counts above describe what we had seen at that moment and are floors, never totals.
note	text	ours	Where a funder has been identified as something other than a wallet farm (a trading terminal funding its users, most often), this says so. Read it before drawing anything from the counts: it is the column that withdraws the inference the others invite.
parent	text	chain	The address that funded this funder, where we traced one. NULL means we did not trace one, never that none exists.
hops	integer	ours	How many funding steps from the cluster's wallets we walked to reach this address. 0 is the direct funder.
tx_rate	real	reading	Transactions per hour measured when this funder's history was last walked (sampled_at). The reading behind refused_enumeration.
refused_enumeration	integer	ours	1 where this funder hit the enumeration cap at throughput no hand-run farm reaches, so its recipients were never imported as a cluster. The infrastructure exclusion working, recorded rather than silent.
top_share	real	reading	Among this funder's trading recipients, the largest fraction trading any one launch, at the last measurement. Low means a customer crowd, not a crew.
trading_members	integer	reading	How many recipients the top_share reading rested on. A measurement over more members outranks one over fewer; weaker re-readings do not overwrite.
demoted	integer	ours	1 where the scatter measurement demoted this funder's group: its recipients trade so many different launches that a shared funder reads as shared infrastructure, and pages must not quote the group as a cluster.

corrections

8 columns

Every correction this project has issued against its own record, so a reader who holds this file and never visits the site still learns what was wrong. Append-only: a correction is superseded by a new row naming it, never edited.

Column	Type	Kind	What it is
id	text	ours	Stable slug, so a correction can be cited by name.
issued_at	integer	ours	When the correction was published, epoch ms.
scope	text	ours	What it concerns: 'column', 'row' or 'record'.
subject	text	ours	The column name or mint the correction is about; NULL when it applies to the whole record.
finding	text	ours	What was wrong.
effect	text	ours	What a reader who trusted the uncorrected record would have wrongly concluded. This is the field to read if you have already published something derived from an earlier copy of this file.
remedy	text	ours	What was done about it, and what to read instead.
supersedes	text	ours	The id of a correction this one replaces. The table is append-only: corrections are superseded, never edited or deleted.

content_edges

6 columns

Creator pairs that share byte-identical birth artifacts - the same image, the same metadata document, or the same ticker family - each edge corroborated by at least two artifacts or two instrument kinds, independent of any funding relationship. An edge states shared artifacts and cites them; it is not a finding of common control. Artifacts shared by more than meta.content_artifact_ceil distinct creators (platform defaults, famous memes) are excluded before anything is counted.

Column	Type	Kind	What it is
creator_a	text	chain	One of the pair, the lexically smaller address.
creator_b	text	chain	The other.
artifacts	integer	ours	Distinct shared artifacts between the two. The rows behind the count are in content_edge_artifacts.
kinds	integer	ours	Distinct instrument kinds among them: image, document, ticker. An edge exists only when artifacts >= 2 or kinds >= 2 - one shared artifact is a lead and gets no row.
acts	integer	ours	Independent reuse acts the evidence amounts to. Shared artifacts that ride the same launch on both sides count once: a meme's image and ticker travel together, and a document contains the name. 1 is a copied launch shape; 2 or more are independent reuses.
cluster	text	ours	The pair's component label, or NULL where the component exceeds meta.content_cluster_ceil - the edge stands on its own evidence, the grouping claim does not. See content_clusters.

content_edge_artifacts

4 columns

The evidence behind each content edge, one row per shared artifact, checkable against tokens by its value.

Column	Type	Kind	What it is
creator_a	text	chain	As in content_edges.
creator_b	text	chain	As in content_edges.
kind	text	ours	'image', 'document' or 'ticker'.
artifact	text	ours	The evidence pointer: the image or document sha256, or for a ticker the symbol and name joined by '\|' (display form; verify by querying the pair of columns). Check any edge yourself: SELECT creator, mint FROM tokens WHERE image_sha256 = the-hash.

content_clusters

11 columns

Connected groups of content-linked creators, labelled only up to meta.content_cluster_ceil members; larger components keep their edges but get no group label, and meta states how many creators that excluded. Rebuilt whole each build.

Column	Type	Kind	What it is
cluster	text	ours	The label: the smallest member address. A name of ours, not the chain's.
creators	integer	ours	Members. Components larger than meta.content_cluster_ceil get no row here at all - at that size the instrument stops resolving individual hands, and the exclusion is stated in meta rather than asserted as a group.
kinds	integer	ours	Distinct instrument kinds across the component's edges.
images	integer	ours	Distinct shared images across the component's edges.
documents	integer	ours	Distinct shared documents.
tickers	integer	ours	Distinct shared ticker families (identical symbol and name).
corroborated_by	integer	ours	How many independent instruments place these members together: the content kinds, plus a shared non-infrastructure funder, plus batch-seeding in time. A count of instruments, not a grade. NULL means the scoring pass did not run for this build, never that nothing corroborates.
shared_funder	integer	ours	1 where two or more members share a funder that does NOT match the infrastructure profile. The funders themselves are in content_cluster_funders.
batch_seeded	integer	ours	1 where two members' funding times fall within one hour of each other - the axis the funding-time measurement found discriminates.
exonerated	integer	ours	1 where members do share a funder but every such funder matches the infrastructure profile: a terminal funds strangers the way a farm funds its own, so the money instrument clears this group rather than corroborating it. Stated because silence would convert a customer list into a finding.
seeded_members	integer	ours	How many members carry a funding time at all - the timing instrument's own coverage, so its silence is readable as absence.

content_cluster_funders

4 columns

The money instrument's evidence per content cluster: each funder that funded two or more members, and whether it matches the infrastructure profile - in which case it clears the group rather than corroborating it. One shared funder is a lead; this table is how a lead is checked.

Column	Type	Kind	What it is
cluster	text	ours	The content_clusters row this evidence belongs to.
funder	text	chain	An address that funded two or more of the cluster's members. The evidence pointer behind shared_funder and exonerated; its own profile is one row away in operator_funders.
members	integer	ours	How many of the cluster's members it funded.
infrastructure	integer	ours	1 where this funder matches the infrastructure profile (operator_funders.refused_enumeration or .demoted), in which case it exonerates rather than corroborates.

content_cluster_members

2 columns

Which creators each content cluster holds.

Column	Type	Kind	What it is
creator	text	chain	A creator address.
cluster	text	ours	The content_clusters row it belongs to.

Three real rows

from this build of the record

The same columns, saying three different things. Every NULL below is load-bearing: it is the file declining to state something rather than a gap someone forgot to fill.

Column	Creator took the supply	No markers found	Not observed
symbol	GOP	MERCURY	emerald
dev_pct	79.3	0.8	0.0
curve_buyers	0	61	0
graduated	1	1	1
graduated_confirmed_by	pool	pool	NULL
vault_sol	NULL	NULL	NULL
late_discovery	0	0	1
rebuilt_complete	0	0	0
what it is	creator took the supply, nobody else bought	small creator share, many buyers	found late; the first block was never seen
read it	record	record	record

Live JSON

api/v1/token/{mint}	one launch record, with an API key. How to read it, and the one rule that matters.
api/v1/status	what the archive holds and what it was awake for
api/summary.json	the last 24 hours' counts and coverage; counts only, no identities

For bulk work, download record.db with your key rather than walking the API.

Reading it

Any SQLite client. The figures on the findings page come from queries like these, and disagreeing with us is the point of publishing it.

SELECT COUNT(*) FROM tokens WHERE graduated_confirmed_by IS NOT NULL AND dev_pct >= 50;	graduations where the creator took at least half the supply
SELECT symbol, dev_pct, curve_buyers FROM tokens WHERE graduated_confirmed_by IS NOT NULL AND curve_buyers = 0;	curves that completed with no outside buyer at all
SELECT t.wallet, COUNT(*) curves, ROUND(SUM(t.sol)) sol FROM trades t WHERE t.market='curve' AND t.side='buy' GROUP BY t.wallet ORDER BY curves DESC;	who takes the most curves, counted from the trade rows in this file rather than from an aggregate you cannot check
SELECT COUNT(*) FROM tokens WHERE graduated=1 AND graduated_confirmed_by IS NULL;	graduations our feed inferred but never confirmed against a pool or the curve account, where we say less

Column	Type	Kind	What it is
k	text	ours	Key. The published record carries built_at (when this file was assembled), built_by (which machine and script: 'local' or the cloud service name, never a personal hostname), built_pid, and watermark (how far the incremental copy had reached).
v	text	ours	Value, as text. Timestamps are epoch ms.