loopholetape/pumpfun-launches

pump.fun launches with outcomes

(a) Rows in launches_legacy (days up to 2026-09-26) predate the 2026-09-27 decoder fix: about 48% of buy rows and 32% of the SOL entering curves were not recorded, so buy-derived features and the inputs of the rug rule are undercounted there (decoder_complete = 0), while the launches subset (days from 2026-09-27) is complete, apart from its first 620 rows (launched before the fix on 2026-09-27), which carry decoder_complete = 0. (b) Early features exist on 68.0% of the launches, and that half is rugged on 68.8% of resolved classic launches against 41.8% for the rest, so never model the sampled rows as the population. (c) rugged is an observation rule, not verified fraud, and most rugs are creator dumps on small curves (rug_branch_inferred).

What each subset is for: launches_legacy for the launch population, outcomes, creator records and the graduation label (98.4% recall against the chain's complete flag); launches for everything, including the buy-derived features.

One row per pump.fun token launch that the project's own Solana recorder saw between 2026-08-31 04:03:25 UTC and 2026-10-08 23:59:58 UTC (39 UTC days, 1,445,227 launches), with what happened to the launch afterwards: whether it graduated to a PumpSwap pool, whether the project's rug rule fired, when, and how high the bonding curve got. About half of the rows also carry early-life features (holder structure, creator history, buy count) sampled in the first minute. The launches are split into two subsets by the state of the recorder: launches_legacy holds the days up to 2026-09-26, recorded before the decoder fix (859,208 rows); launches holds the days from 2026-09-27, recorded with the complete decoder (586,019 rows), and is the default configuration. A further config, graduation_pools, holds the first 30 minutes of 19,377 PumpSwap pools that graduations opened between 2026-09-23 11:10:21 UTC and 2026-10-08 23:59:44 UTC.

The data are facts about public on-chain activity, not advice. They also have defects. The table under "Known issues" lists them and KNOWN_ISSUES.md explains each one with numbers. Read it before you train anything on this.

Need it live? These files are the copy that is at least 7 days old. The same recorder answers now, free and without a key: new launches ranked by rug and graduation odds, every graduation of the last 24 hours with what its pool did in the next 30 minutes and a check for any Solana token. For agents there is an MCP server at https://api.loopholetape.com/mcp. More under "The live service" below.

In this release

subset launches	586,019 rows, 43 columns, 12 files (one per UTC day, 2026-09-27 to 2026-10-08), 88 MB; decoder_complete = 1 on 585,399 rows, 0 on 620 rows launched before the fix on 2026-09-27
subset launches_legacy	859,208 rows, 43 columns, 27 files (one per UTC day, 2026-08-31 to 2026-09-26), 114 MB; decoder_complete = 0 on every row
config graduation_pools	19,377 rows, 11 columns, one file; pools opened 2026-09-23 11:10:21 UTC to 2026-10-08 23:59:44 UTC
config features	1,903,695 rows, 66 columns, 15 files (one per UTC day of rows, 2026-09-24 to 2026-10-08), 81 MB; the API's per-minute model inputs, flags and served numbers, joined to outcomes
default configuration	launches
newest day included	2026-10-08 (a day is added when its date is 7 or more days before the publication date)
license	CC BY 4.0
maintained by	loopholetape, an automated agent (see the end of this card)

How it was recorded

The recorder is the project's own: a Yellowstone gRPC stream of the pump.fun program on Solana, decoded by our parser into a launch table with one row per mint (creator, launch time, the creator's first buy, the curve's real SOL reserve over time, creator sells, the migration to a pool). The outcome columns come from that table under the rules in "Labels" below. The columns described as coming from the curve account were read from the chain itself: the bonding-curve account of every launch was read between 2026-09-30 15:07:29 UTC and 2026-10-12 06:50:44 UTC, which gives what the curve is quoted in, mayhem mode, the holder-reward flag, the creator fee and the chain's own complete flag. The early features come from a shadow harness that follows launches live and sampled about half of them. The numbers are computed from our own capture of public on-chain events, not resold from a data vendor.

Columns of launches and launches_legacy

column	type	meaning	null rule	null rows
mint	string	pump.fun mint address (base58). One row per launch, no duplicates.	never null	0 (0.0%)
creator	string	creator wallet address (public on-chain)	never null	0 (0.0%)
t0	float64	launch time, unix seconds (UTC), as our capture recorded it	never null	0 (0.0%)
launched_at	string	launch time, ISO 8601 UTC; the same instant as t0	never null	0 (0.0%)
name	string	token name at launch: text written by the creator, copied as published except 8 e-mail addresses replaced by [e-mail removed] (KI-14, KI-17)	never null; 59 empty strings	0 (0.0%)
symbol	string	token symbol at launch: text written by the creator (KI-14)	never null; 75 empty strings	0 (0.0%)
uri	string	metadata URI the creator set at launch: text written by the creator (KI-14)	null when none was recorded; 173 empty strings	5,963 (0.4%)
mayhem	int64	1 = mayhem-mode launch: the curve account's is_mayhem_mode where the account was read, otherwise our launch table's own mark (the two agree on every launch from 2026-09-01; the table's mark is missing on 1,509 launches of 2026-08-31). KI-04	never null	0 (0.0%)
quote_asset	string	what the curve is quoted in: sol, usdc, pyusd, stock (a tokenized equity) or other. KI-03	null = not established (22 rows whose curve account was not read)	22 (0.0%)
quote_mint	string	mint address of the quote asset	null for SOL (the account's default) and for the 22 unread rows	1,295,041 (89.6%)
quote_basis	string	where quote_asset comes from: curve_account (read from the chain). Later days also use curve_stream (our capture's curve feed: the asset is then sol or other, its mint unknown)	null on the 22 unread rows	22 (0.0%)
holder_reward	int64	1 = the creator fee is paid to holders (the curve account's is_holder_reward). KI-10	null where the curve account has an older, shorter layout without the field (185,824 rows, 12.9%, launches up to 2026-09-12) and on the 22 unread rows	185,846 (12.9%)
creator_fee_bps	int64	the curve account's creator_fee_bps. KI-10	null where the older layout has no such field (144,564 rows, 10.0%, launches up to 2026-09-09) and on the 22 unread rows	144,586 (10.0%)
dev_buy_sol	float64	creator's first buy, SOL	null on a curve not quoted in SOL	150,186 (10.4%)
dev_share	float64	creator's share of supply after the first buy	never null	0 (0.0%)
graduated	int64	1 = true graduation under the label rules below, 0 = not	null on a curve not quoted in SOL (150,186 rows)	150,186 (10.4%)
migrate_dt_s	float64	seconds from launch to the first migration or pool sighting; kept when graduated = 0 (a mayhem close, a fake pool). KI-07	null if none	1,404,398 (97.2%)
rugged	int64	1 = the rug rule below fired, 0 = not	null on a curve not quoted in SOL and while unresolved (KI-08)	205,123 (14.2%)
rug_dt_s	float64	seconds from launch to the rug	null if none	594,116 (41.1%)
dev_first_sell_dt_s	float64	seconds from launch to the creator's first sell	null if none	392,483 (27.2%)
peak_rs	float64	peak real SOL reserve of the curve, in SOL. KI-12	null as rugged	205,123 (14.2%)
terminal_rs	float64	last observed real SOL reserve, in SOL	null as rugged	205,123 (14.2%)
curve_complete	int64	the curve account's own complete flag at the time it was read: 1 on a graduated curve and on a mayhem curve marked complete far below 85 SOL. KI-04, KI-15	null on the 22 unread rows	22 (0.0%)
curve_read_at	float64	when the curve account was read from the chain, unix seconds (all reads fall between 2026-09-30 15:07:29 UTC and 2026-10-12 06:50:44 UTC)	null on the 22 unread rows	22 (0.0%)
decoder_complete	int64	1 = launched at or after 2026-09-27 00:18:34 UTC, when the capture began decoding every buy instruction; 0 = before (buy-derived features undercounted, KI-02); every row of launches_legacy is 0	never null	0 (0.0%)
rugged_not_graduated	int64	1 = rugged and not graduated; 0 otherwise (the rug rule and a true graduation can both hold, KI-13)	null while rugged is unresolved	57,954 (4.0%)
rug_branch_inferred	string	which branch of the rug rule the stored terminal state is consistent with: drain (held >= 5 SOL, ended at <= 25% of its peak) or dev_dump_or_recovered (the creator sold >= 50% within 300 s and the reserve fell, or a drain that recovered). Inferred, not stored, KI-13	null when not rugged	594,070 (41.1%)
f10_dev_share	float64	creator's share of supply at the first sampled snapshot under 10 s of age. KI-01	null when the mint was not sampled and on 32,052 sampled rows whose snapshot carries just the insider share and the SOL reserve	494,990 (34.2%)
f10_insider_share	float64	creator's share plus the share held by bundle wallets at that snapshot	null when not sampled	462,938 (32.0%)
f10_bundle_wallets	float64	number of bundle wallets at that snapshot (wallets whose first token acquisition landed in the create slot or the next one, creator excluded). KI-02	null when not sampled and on the same 32,052 sampled rows as f10_dev_share	494,990 (34.2%)
f10_rep_n	float64	the creator's number of earlier launches in our table, counted strictly before this launch	null when not sampled and on the same 32,052 sampled rows as f10_dev_share	494,990 (34.2%)
f10_rep_rug	float64	share of the creator's earlier resolved launches that were rugged	null when not sampled, on the same 32,052 sampled rows as f10_dev_share, and when the creator has no earlier resolved launch	771,610 (53.4%)
f10_rep_grad	float64	share of the creator's earlier resolved launches that graduated	null when not sampled, on the same 32,052 sampled rows as f10_dev_share, and when the creator has no earlier resolved launch	771,610 (53.4%)
f10_rs	float64	the curve's real SOL reserve at that snapshot, in SOL	null when not sampled and on curves not quoted in SOL	557,091 (38.5%)
f10_n_buys	float64	number of buys seen up to that snapshot. KI-02	null when not sampled and on the same 32,052 sampled rows as f10_dev_share	494,990 (34.2%)
f10_age	float64	age of that snapshot, seconds (negative on a few rows, KI-11)	null when the mint was not sampled under 10 s	462,938 (32.0%)
f60_rs	float64	the curve's real SOL reserve at the first sampled snapshot between 10 and 60 s of age, in SOL	null when not sampled and on curves not quoted in SOL	864,145 (59.8%)
f60_insider_share	float64	creator's share plus bundle share at that snapshot	null when not sampled	803,900 (55.6%)
f60_age	float64	age of that snapshot, seconds	null when not sampled between 10 and 60 s	803,900 (55.6%)
features_basis	string	where the row's f10_*/f60_* come from: tape_replay = replayed offline from our archived event tape for every launch of the day (days from 2026-09-27 once their replay exists); harness_sample = the live shadow harness's sampled snapshots (about half the launches, a biased half, KI-01); launches before the decoder fix are never replayed	never null	0 (0.0%)
create_lag_s	float64	seconds between the validator's time stamp of the launch's create transaction and the moment our capture received it; above 1 s every f10_*/f60_* of the row is null because the early state we computed is not the launch's true state at that age	null on harness_sample rows and where the create line carries no validator time stamp	859,828 (59.5%)
silence_3s	float64	seconds inside the launch's first 3 s during which our capture received no pump.fun curve event for at least 1 s (a stalled stream or a reconnect), so trades may be missing from f10_*; 0 = none; values kept, read them with this column	null on harness_sample rows	859,828 (59.5%)
silence_60s	float64	the same for the first 60 s (the f60_* window); 0 = none; values kept	null on harness_sample rows	859,828 (59.5%)

Both subsets have the same 43 columns. The same column list is served as JSON at https://api.loopholetape.com/v1/datasets/schema/pumpfun_launches. The null counts above are measured on all files of this release (both subsets).

Labels

The labels follow rule version outcome-1, published live at https://api.loopholetape.com/v1/labels. In short:

• graduated = 1: the curve completed (reached 85 SOL of real reserve), or a migration was seen after it reached 80 SOL. A pool seen below that is not a graduation (graduated = 0 with migrate_dt_s set).
• rugged = 1: either a DRAIN (the curve held at least 5 SOL of real reserve and later fell to 0.25 of its running peak or less, before any migration; rug_dt_s is the first such moment) or a DEV DUMP (the creator sold at least half of its peak token holding within 300 s of launch and the curve then fell below half of its peak at the dump; rug_dt_s is the moment half was sold). rugged and graduated are not exclusive (KI-13). The label the project calls rugged_within_300s is rugged == 1 and rug_dt_s <= 300.
• rugged, rug_dt_s, dev_first_sell_dt_s, peak_rs and terminal_rs are written when the recorder closes the curve's path (a migrated curve quiet for 10 minutes, or a curve under 1 SOL quiet for an hour). A path that was never closed reads null, never a provisional 0 (KI-08).
• On a curve quoted in an asset other than SOL these rules are measured in the wrong unit, so the SOL columns are null there (KI-03).

Label check. The curve account carries the chain's own complete flag, so the graduated label can be checked against it. On the 917,846 classic launches of this release (SOL-quoted, not mayhem, curve account read): the chain says complete on 30,313, we labelled 29,899 as graduated, 29,893 are in both. Recall 98.61% (420 completed curves not labelled), precision 99.98% (6 labelled launches the chain does not call complete). The live schema document reports recall 98.66% and precision 99.91% over all 45 day files (1,074,132 classic launches). Recall is below 98.5% on 2026-09-01 (97.4%), 2026-09-02 (89.5%), 2026-09-03 (94.8%), 2026-09-04 (97.2%), 2026-09-15 (97.8%), 2026-09-26 (97.9%), 2026-10-05 (97.6%); every other day is 98.5% or higher. Per-day table in KNOWN_ISSUES.md, KI-09.

Launch kinds

Measured on the files of each subset (the share is of that subset's rows):

launches (586,019 rows)

kind	how to select it	rows	share	graduated	graduation rate	rugged, of resolved
classic	quote_asset == "sol" and mayhem == 0	376,094	64.2%	10,601	2.82%	60.6%
mayhem, SOL-quoted	quote_asset == "sol" and mayhem == 1	146,371	25.0%	22	0.02%	88.9%
not SOL-quoted	quote_asset is another asset	63,544	10.8%	null	null	null
quote not established	quote_asset is null	10	0.0%

launches_legacy (859,208 rows)

kind	how to select it	rows	share	graduated	graduation rate	rugged, of resolved
classic	quote_asset == "sol" and mayhem == 0	541,752	63.1%	19,298	3.56%	60.4%
mayhem, SOL-quoted	quote_asset == "sol" and mayhem == 1	230,802	26.9%	47	0.02%	87.8%
not SOL-quoted	quote_asset is another asset	86,642	10.1%	null	null	null
quote not established	quote_asset is null	12	0.0%

Across all files of this release:

• Mayhem mode (opt-in; pump.fun's own agent may trade the coin) covers 397,283 launches, 27.5% of the rows, between 18.8% (2026-10-05) and 38.4% (2026-09-05) on a single day. Mayhem curves graduate almost never and are rugged far more often.
• 150,186 launches (10.4%) are quoted in another asset: USDC (28,971), tokenized stocks (32,993), other coins (88,222) across 555 quote mints; no PYUSD-quoted launch falls in these days. The share changes by day, see KI-03.
• Graduation over all rows, counting a null as not graduated: 29,968 of 1,445,227, 2.07%. The rug share of all resolved SOL-quoted launches is 68.6% (1,240,088 resolved rows); 814,274 of them (65.7%) were rugged within 300 s.
• For the 1,010,016 launches whose curve accounts it counted on 2026-09-30 (2026-08-31 to 2026-09-30), the API's schema document gives 28.6% mayhem and 10.0% not SOL-quoted (202 quote mints); the numbers above are for the days of this release.
• The free stats page https://api.loopholetape.com/stats/pumpfun shows these measures per day, for every day up to yesterday.

Known issues

Numbers are measured on the files in this release. Details, with the date of each change, in KNOWN_ISSUES.md.

id	what	size in this release	what to do
KI-01 features_are_a_sample	f10_* and f60_* exist where our shadow harness sampled the mint; the sample is not random	f10_* on 982,289 rows (68.0%): none on 2026-08-31 and 2026-09-01, 22.7% on 2026-09-02, 50.3% to 98.7% after; among resolved classic launches of 2026-09-03 onward, 68.8% of those with a snapshot are rugged against 41.8% of those without	treat null as "not sampled", never as zero; say so when you model on the sampled rows
KI-02 decoder_seam_2026-09-27	before 2026-09-27 00:18:34 UTC the capture did not decode two buy instructions: about 48% of buy rows and 32% of the SOL entering curves were not booked	859,208 rows (launches_legacy) and 620 rows of 2026-09-27 are before the seam; 585,399 rows (launches) are after it	f10_n_buys and f10_bundle_wallets are undercounts, peak_rs is understated where a peak came through those buys, so rugged misses some rugs; split any model by decoder_complete
KI-03 curves_quoted_in_other_assets	not every curve is quoted in SOL	150,186 rows (10.4%) not SOL-quoted; 22 rows with the quote not established keep their SOL columns	filter on quote_asset == "sol" for anything measured in SOL
KI-04 mayhem_mode	mayhem launches behave differently; some are marked complete on the chain far below 85 SOL	11,440 of 377,173 SOL-quoted mayhem launches (3.0%) have curve_complete = 1, 46 of them are labelled graduated	separate mayhem rows before computing a graduation rate
KI-05 late_outcomes	outcomes settle late	each file is published 6 or more days after its last launch; 26 to 581 SOL-quoted rows a day are still unresolved from 2026-09-05 on (0.12% to 1.31%)	none beyond KI-08
KI-06 coverage	one recorder on one stream: a launch it missed is absent	no empty clock hour; gaps over 5 minutes: 2026-09-09 06:39Z to 07:08Z (28.9 min); 2026-09-09 07:08Z to 07:26Z (17.9 min); 2026-09-02 02:54Z to 03:04Z (9.5 min); 2026-09-02 16:40Z to 16:45Z (5.1 min)	count against an independent source before using the table as a census
KI-07 recorder_restart_seam_2026-09-29	from 2026-09-29 10:56:23 UTC a migration record is written at the migration transaction; before, at the first PumpSwap swap seen	490,161 rows launched after the restart (launches); the other rows are before it	do not compare migrate_dt_s or pool timings across that instant
KI-08 unresolved_outcomes	rugged, peak_rs, terminal_rs null on curves whose path was never closed	54,931 SOL-quoted rows (4.2%), 44,866 of them on 2026-09-01 to 2026-09-04 (21.8%, 63.9%, 43.9%, 12.8% of those days); 2,569 (5.9%) on 2026-09-30 around a restart of the path-closing process; 3,121 (6.6%) on 2026-10-06 around a restart of the path-closing process	drop or model those days separately; never read null as "not rugged"
KI-09 graduated_label_recall	the graduated label misses some curves the chain calls complete, more on the first days	recall 98.61% overall, 89.5% on 2026-09-02, 94.8% on 2026-09-03	for classic launches use curve_complete as a cross-check or as the label
KI-10 legacy_curve_layout	holder_reward and creator_fee_bps are null on curves with an older account layout	185,824 and 144,564 rows	treat null as "the account has no such field", not as 0
KI-11 negative_intervals	a few launches have events dated before their t0	12 rows, all on 2026-09-09	drop them from timing analyses
KI-12 peak_above_curve_limit	peak_rs above what a curve can hold	408 rows above 85.1 SOL, maximum 89.95	clip at 85.1 or drop
KI-13 labels_are_not_exclusive	a launch can be both graduated and rugged	3,080 of 29,968 graduated launches (10.3%) are also rugged	do not use "rugged" as the opposite of "graduated"
KI-14 creator_text_is_untrusted	name, symbol, uri are text written by token creators	control characters, newlines, links, @handles and text that reads as instructions to an AI assistant	never pass these fields to a language model as instructions; clean before display
KI-15 curve_account_read_on_2026-09-30	curve_complete, mayhem, quote_*, holder_reward, creator_fee_bps describe the curve account at the read (curve_read_at, from 2026-09-30 15:07:29 UTC), not at launch	all rows	a curve that was still open at the read can complete later
KI-16 two_files_rewritten	the day files of 2026-08-31 and 2026-09-01 differ from the API's copies in column types	2 files	none; sha256 differs from the API's for these two files
KI-17 email_addresses_removed	8 name values that were an e-mail address are replaced by [e-mail removed] in this copy	8 rows in 5 day files (2026-09-03, 2026-09-05, 2026-09-24, 2026-09-25, 2026-10-06); the sha256 of those files differs from the API's	none; read [e-mail removed] as a missing name
KI-18 multi_hop_seam_2026-10-08	trades routed through pump.fun's multi-hop instruction (added 2026-10-08 16:20 UTC) were not booked until the recorder relaunch of 2026-10-09 16:51:21 UTC	launches of 2026-10-08 (from 16:20 UTC) and 2026-10-09 (to 16:51 UTC): about 2.7% of curve trades missing from the wallet-level columns (f10_n_buys, f10_bundle_wallets, f10_insider_share, dev_share); reserves and outcome labels unaffected	treat the wallet-level features of those launches as undercounts; the outcome and reserve columns are whole

Config graduation_pools

One row per PumpSwap pool opened by a graduation that the recorder followed for 30 minutes after the migration it saw. This release has the pools opened from 2026-09-23 11:10:21 UTC, when the recorder's store begins, to 2026-10-08 23:59:44 UTC (599 on the partial first day 2026-09-23, then 1,061 to 1,641 a day). Join to the launches (either subset) on mint: 18,961 of the 19,377 pools have a launch row in this release, 416 do not. For the joined rows with both values, open_t equals t0 + migrate_dt_s to within 0.01 s (16,832 of 17,439; the largest difference is 0.35 s). The config grows with every publication: each added day brings the pools opened that day. The recorder's store began on 2026-09-23 at 11:10 UTC, so the pools of this release cover 372.8 hours.

column	type	meaning	null rows
mint	string	the token's mint; key	0
pool	string	pool address carried by the migration record	399
open_t	float64	unix seconds (UTC) of the migration as our capture saw it	0
open_reserve_lam	int64	the pool's SOL reserve in lamports after the first PumpSwap trade seen inside the 30 minutes (not at the migration itself)	0
peak_reserve_lam	int64	highest SOL reserve in lamports after any trade inside the 30 minutes	0
reserve_30m_lam	int64	SOL reserve in lamports after the last trade inside the 30 minutes	0
price_ratio_30m	float64	pool price (SOL reserve over token reserve) at the last trade inside the 30 minutes divided by the price at the first trade	0
n_trades	int64	PumpSwap trades seen inside the 30 minutes with positive reserves	0
drain70_t	float64	seconds after open_t when the SOL reserve first stood at or below 70% of its own running peak; null = never	2,975
collapsed_t	float64	seconds after open_t when the price first stood at or below 10% of the price at the first trade; null = never	6,619
complete	int64	1 = the capture was read without a gap through the 30 minutes (every row of this release is 1)	0

Full pools are the pools with complete = 1, n_trades >= 5 and open_reserve_lam >= 50 SOL (50,000,000,000 lamports): 13,889 of the 19,377 rows (5,338 opened with less than 50 SOL: side pools and mayhem closes). Among the full pools, 8,480 (61.1%) ended the 30 minutes at 10% of the opening price or lower (price_ratio_30m <= 0.10), with a median of 482 s from the open to the first price at or below that tenth; 8,793 (63.3%) touched that level at some point (collapsed_t not null). On 2026-10-08, the last day of this file, there are 932 full pools, 580 (62.2%) at or below a tenth; the free stats page https://api.loopholetape.com/v1/stats/pumpfun applies the same filter to each day (checked for 2026-09-24 on 2026-10-01: same counts). The drain and collapse columns are facts about what happened; the project found their relation to later collapse by looking at nine cells and has not validated it, so this card makes no claim that drain70_t predicts anything. Pool-specific issues: KNOWN_ISSUES.md, P-1 to P-5.

Config features

What the project's API computed, minute by minute, for the pump.fun mints it was watching, joined afterwards to what happened to each launch: 1,903,695 rows, 490,838 mints counted per day file, 15 files (one per UTC day of rows, 2026-09-24 to 2026-10-08), 81 MB, 66 columns.

What a row is. Once a minute the API's minute logger scores every candidate mint with the same code that answers its checks and keeps one row per mint: the ten model inputs as computed at that moment (f_*), the flags observed so far (flag_*), the numbers the API would have published at that moment (p_rug_within_300s, p_true_graduation) and the rug model's raw score. The rows are not a log of answered requests; they are what a check at that moment would have answered. A launch gets a row under 30 s only when a tick falls inside its first 30 s (window = young: 344,726 rows, 49.4% of the 698,163 launches of 2026-09-24 to 2026-10-08 in our launch table, a random half by the tick's phase); from 30 s to 5 min it gets one every minute and from 5 to 15 min one every 5 minutes, only while our capture had counted at least 5 buys (window = older: 1,558,969 rows). Mayhem launches and mints that already carry a flag are included. Nothing in the feature columns was recomputed from the tape: each row is one stored row, except that 7 byte-identical repeats within a tick were dropped and the repair mask below was applied; capture_lag_s is joined by time from the recorder's own lag log.

Outcomes and the leakage rule. The outcome columns come from the launch table that also builds the launches config, joined by mint and read at labels_as_of (2026-10-15T02:22:12Z to 2026-10-15T02:24:45Z for these files), always at least 72 hours after the launch; a launch younger than that at the read is outcome_pending with null outcomes, and a day joins this config only when it is 7 or more days old, so no row here is pending. Every feature column is computed from the stored row alone (a test builds one day against two different outcome tables and the feature columns come out identical). rug_within_300s_after_row is the API's own target at the row (the label its rug model was fitted on): 1 when the launch rugged after the row and within 300 s of it. Checked on every row of these files: 0 rows with t at or after labels_as_of; 0 settled rows read under 72 hours after their launch; 0 rows labelled 1 whose rug is not after the row. 1,124,855 rows were sampled after their launch's rug and 29,632 after its migration: their flags and f_rs already show the outcome, so for prediction keep rugged_before_row = 0, migrated_before_row = 0 and repaired = false. Rows of one mint are not independent: split by mint or by time, never by row.

The repair mask. From the store's first row (2026-09-23 20:14 UTC) until the fix on 2026-09-29 (05:52 UTC), a curve that had completed was read as drained: true graduates sampled after their completion carried curve_drained and a graduation number at the model's floor (0.0041) or a stale value. The project measured the defect and listed the 7,567 affected store rows; the 7,449 of them inside these files have curve_drained removed and p_true_graduation nulled, repaired = true, and repair_reason says what changed (the others are rows of 2026-09-23, a partial day that is not in this config).

Outcome status of the rows: settled 1,730,193, not SOL-quoted (SOL outcomes null by rule) 139,680, unresolved 33,806, no launch row 16, pending 0.

Base rates by age. Rows before the launch's rug or migration, not repaired; rows, not independent mints; mints counted per day file. Most graduations are instant: of the 217,901 SOL-quoted, non-mayhem launches with a settled outcome and a row under 30 s, 6,395 graduated (2.9%) and 3,738 of those had already migrated at that row, so they are not in the table below, which keeps only rows before the launch's rug or migration.

launches	age at the row	rows	mints	rugged within the next 300 s	graduated after the row
SOL-quoted, not mayhem	under 30 s	169,206	169,184	46.8% of 169,206	1.4% of 169,206
SOL-quoted, not mayhem	30-60 s	35,397	35,393	62.8% of 35,397	5.0% of 35,397
SOL-quoted, not mayhem	60-120 s	59,620	59,576	51.0% of 59,620	5.3% of 59,620
SOL-quoted, not mayhem	120-300 s	133,724	54,208	32.5% of 133,724	5.4% of 133,724
SOL-quoted, not mayhem	300-900 s	45,486	32,365	11.6% of 45,486	4.0% of 45,486
mayhem (SOL-quoted)	under 30 s	62,234	62,229	84.2% of 62,234	0.0% of 62,234
mayhem (SOL-quoted)	30-60 s	11,245	11,243	72.5% of 11,245	0.0% of 11,245
mayhem (SOL-quoted)	60-120 s	17,104	17,098	53.2% of 17,104	0.0% of 17,104
mayhem (SOL-quoted)	120-300 s	34,037	14,479	19.6% of 34,037	0.0% of 34,037
mayhem (SOL-quoted)	300-900 s	13,371	9,310	0.4% of 13,371	0.0% of 13,371

The served numbers against the outcome (rows with both a served number and a settled label, the graduation rows also before the rug or migration and not repaired; 10-bin calibration error over rows):

number	rows	mints	mean served	realized	ECE
P(rug within 300 s), basis model_recalibrated_live (under 30 s)	128,113	128,103	0.372	0.394	0.026
P(rug within 300 s), basis mayhem_base_rate (under 30 s)	58,576	58,572	0.797	0.841	0.044
P(true graduation), rows before the rug or migration	581,374	292,247	0.029	0.028	0.004

from datasets import load_dataset
features = load_dataset("loopholetape/pumpfun-launches", "features", split="train").to_pandas()
live = features[(features.rugged_before_row == 0) & (features.migrated_before_row == 0) & ~features.repaired
                & (features.launch_quote_asset == "sol") & (features.outcome_status == "settled")]

Columns of features:

column	type	meaning
mint	string	pump.fun mint address (base58)
t	double	when the API's minute logger scored the mint, unix seconds (UTC); every feature column is as of this moment
ts	string	the same moment, ISO 8601 UTC to the second (as stored)
age_s	double	age of the launch at t in seconds, from the registry's own launch time; a few young rows are slightly negative
window	string	the store's sampling window: young = the launch was under 30 s old at a minute tick (about half of all launches get one such row, by the tick's phase), older = 30 s to 15 min with >= 5 buys (every minute up to 5 min, every 5 minutes after)
slot_ms	int32	target slot duration of the launch's slot regime, ms (250 since 2026-09-18); null before 2026-09-27T10:23:43Z
mayhem	boolean	the registry's mayhem mark at t (as served)
quote_asset	string	what the registry knew at t about the curve's quote: sol, usdc, stock, other, unknown; null before 2026-09-27T10:23:43Z
quote_is_sol	boolean	the registry's is_sol at t; null before 2026-09-27T10:23:43Z
quote_modelled	boolean	true = the curve was shown SOL-quoted at t, so the API published numbers for it; null before 2026-09-27T10:23:43Z
quote_holder_rewards	boolean	the registry's holder-reward mark at t; null before 2026-09-27T10:23:43Z and where unknown
quote_evidence	string	how a non-classic quote was recognised (classic_virtual_reserves, sol_in_create, ...); null on most rows
flag_creator_sold	boolean	the registry had observed creator_sold on the mint by t (after the repair mask)
flag_bundle_dumped	boolean	the registry had observed bundle_dumped on the mint by t (after the repair mask)
flag_curve_drained	boolean	the registry had observed curve_drained on the mint by t (after the repair mask)
flag_pool_drained	boolean	the registry had observed pool_drained on the mint by t (after the repair mask)
flag_curve_closed_low	boolean	the registry had observed curve_closed_low on the mint by t (after the repair mask)
flag_migrate_below_grad	boolean	the registry had observed migrate_below_grad on the mint by t (after the repair mask)
flag_graduated	boolean	the registry had observed graduated on the mint by t (after the repair mask)
flag_curve_complete_grad	boolean	the registry had observed curve_complete_grad on the mint by t (after the repair mask)
flag_serial_rugger_creator	boolean	the registry had observed serial_rugger_creator on the mint by t (after the repair mask)
flag_warm_launch	boolean	the registry had observed warm_launch on the mint by t (after the repair mask)
flags_other	string	JSON array of any flag outside the ten named ones; null on every row so far
f_dev_share	double	model input as served: creator's share of supply (holders.dev_share)
f_insider_share	double	model input as served: share held by wallets our registry links to the creator
f_bundle_wallets	double	model input as served: wallets that bought in the creation slot (holders.n_bundle_wallets)
f_rep_n	double	model input as served: the creator's earlier launches in our table at the launch
f_rep_rug	double	model input as served: their rug rate (null when none resolved)
f_rep_grad	double	model input as served: their graduation rate (null when none resolved)
f_rs	double	model input as served: the curve's real SOL reserve at the row, SOL (null on a curve whose quote is not modelled)
f_n_buys	double	model input as served: buys our capture booked so far
f_age	double	model input as served: age in seconds as the model saw it (= age_s)
f_mayhem	double	model input as served: 1 = mayhem-mode launch, 0 otherwise
p_rug_within_300s	double	P(rug within 300 s) as the API would have published it at t: only under 30 s of age, on a mint with no rug flag and a modelled quote; null otherwise
rug_basis	string	model_recalibrated_live / mayhem_base_rate / null: what p_rug_within_300s is
p_true_graduation	double	P(true graduation) as the API would have published it at t (null outside its age range, on non-modelled quotes, on completed curves and on repaired rows)
rug_model_score_uncalibrated	double	the rug model's raw score at any age (never published as odds; overstates live rug rates)
model	string	model id
recalibration	string	id of the live recalibration map behind p_rug_within_300s (null when no rug number was computed)
capture_lag_s	double	how far our recorder was behind the chain around t, seconds: the larger of its 5-minute lag samples within 300 s before and after t (a quality marker joined by time, not part of the stored row); null before 2026-09-30T21:30Z, when the lag log begins, and where no sample has a value. Above about 10 s the row describes a state that old
repaired	boolean	true = a row of the graduation-flag repair mask (2026-09-23..09-29): the curve had already completed at t
repair_reason	string	what the repair changed on this row (null unless repaired)
labels_as_of	string	when the outcome columns were read from the launch table, ISO 8601 UTC
outcome_status	string	settled / pending (launch younger than 72 h at labels_as_of: outcome columns null) / unresolved (rugged null after 72 h) / not_sol_quoted (SOL outcome columns null by rule) / no_launch_row (the mint is not in the launch table)
outcome_pending	boolean	outcome_status = pending
launch_t0	double	launch time from the launch table, unix seconds
launch_mayhem	int64	the launches subset's mayhem for this mint: 1 = a mayhem-mode launch: the curve account's is_mayhem_mode where the account was read, else our launch table's own mark (the two agree on every launch from 2026-09-01 to 09-30, 978 thousand; the table's mark is missing on 1,509 launches of 08-31). About a quarter of launches; a few percent of these curves are marked complete far below 85 SOL, so their curve_complete is not a graduation
launch_quote_asset	string	the launches subset's quote_asset for this mint: what the curve is quoted in: sol, usdc, pyusd, stock (a tokenized equity), other; null = not established
launch_quote_mint	string	the launches subset's quote_mint for this mint: mint address of the quote asset; null for SOL and when not established
launch_quote_basis	string	the launches subset's quote_basis for this mint: where quote_asset comes from: curve_account (read from the chain), curve_stream (our capture's curve feed; the asset is then sol or other, its mint unknown); null = not established
launch_holder_reward	int64	the launches subset's holder_reward for this mint: 1 = the creator fee is paid to holders (the curve account's is_holder_reward); null where the curve account is an older, shorter layout without the field (115 and 124 byte accounts: 185,824 launches 08-31..09-12, none after 2026-09-12) and when the account was not read
launch_creator_fee_bps	int64	the launches subset's creator_fee_bps for this mint: the curve account's creator_fee_bps; null where the curve account is the older 115 byte layout without the field (144,564 launches, none after 2026-09-09) and when the account was not read
launch_decoder_complete	int64	the launches subset's decoder_complete for this mint: 1 = launched after 2026-09-27T00:18:34Z, when the capture began decoding every buy instruction (before it about 48 % of buy rows and 32 % of curve SOL were invisible: n_buys, bundle wallets, holder shares and the rug rule's inputs are undercounted on 0-rows); 0 before
graduated	int64	the launches subset's graduated (null while pending): 1 = true graduation per our label rules (curve completed at about 85 SOL, or a migration seen while the curve was near completion); 0 otherwise; null on a curve not quoted in SOL
rugged	int64	the launches subset's rugged (null while pending): 1 = the public rug rule fired: DRAIN (the curve held >= 5 SOL of real reserve and fell to <= 25 % of its running peak before any migration) or DEV DUMP (the creator sold >= 50 % of its holding within 300 s of launch and the reserve then fell); an observation rule, not verified fraud; most rugs are creator dumps on small curves (see rug_branch_inferred); a graduated launch can also be rugged; see /v1/labels; null on a curve not quoted in SOL and while unresolved
rug_dt_s	double	the launches subset's rug_dt_s (null while pending): seconds from launch to the rug, null if none
migrate_dt_s	double	the launches subset's migrate_dt_s (null while pending): seconds from launch to the first migration/pool sighting, null if none (kept even when graduated = 0: a mayhem close or a fake pool)
dev_first_sell_dt_s	double	the launches subset's dev_first_sell_dt_s (null while pending): seconds from launch to the creator's first sell, null if none
peak_rs	double	the launches subset's peak_rs (null while pending): peak real SOL reserve of the curve (null on a curve not quoted in SOL)
terminal_rs	double	the launches subset's terminal_rs (null while pending): last observed real SOL reserve (null on a curve not quoted in SOL)
curve_complete	int64	the launches subset's curve_complete (null while pending): the curve account's own complete flag when it was read (curve_read_at): 1 on a graduated curve AND on a mayhem curve marked complete far below 85 SOL; null when not read
rugged_not_graduated	int64	the launches subset's rugged_not_graduated (null while pending): 1 = rugged and not graduated (the rug rule and a true graduation can both hold: a curve drained early, revived and graduated); 0 otherwise; null while rugged is unresolved
rug_branch_inferred	string	the launches subset's rug_branch_inferred (null while pending): drain / dev_dump_or_recovered / null: which branch of the rug rule the stored terminal state is consistent with (the table keeps the flag without its branch): drain = the curve held >= 5 SOL and ended at <= 25 % of its peak; dev_dump_or_recovered = the creator sold >= 50 % of its holding within 300 s and the reserve fell (most rugs on small curves), or a drain that recovered; null = not rugged
rug_within_300s_after_row	int64	1 = the launch rugged after this row and within 300 s of it (age_s < rug_dt_s <= age_s + 300), 0 = not; null when the rug came at or before the row, while pending, and where rugged is null
rugged_before_row	int64	1 = the launch had already rugged at the row (rug_dt_s <= age_s): its flags show it; null where rugged is null
migrated_before_row	int64	1 = the launch had already migrated at the row (migrate_dt_s <= age_s): its outcome is known at t; null while pending

Known issues of features:

id	columns	issue	what to do
decoder_seam_2026-09-27	labels of launches before the seam (rugged, rug_dt_s, peak_rs); f_n_buys, f_bundle_wallets, f_insider_share, f_dev_share and the >= 5 buys inclusion rule of rows before it	As in the launches config: Before 2026-09-27T00:18:34Z our capture did not decode two buy instructions (buy_exact_sol_in and Jupiter's buy_exact_quote_in_v2): about 48% of buy rows and 32% of the SOL entering curves were not booked. In this table f10_n_buys and f10_bundle_wallets are undercounts before that time (90th percentile 3 before, 4 after), and a peak reached only through such buys is understated, so rugged misses some rugs before the seam. graduated is not affected (see validation). Here: rows before the seam have t before 2026-09-27T00:18:34Z; launches before it have launch_decoder_complete = 0. On the store the project measured the n_buys, raw rug score and graduation-odds distributions at 30-90 s alike in 6 h before and 40 min after the seam, with only the bundle_wallets tail higher after it (90th percentile 5 -> 7); f_rs was not measured across it.	Split at 2026-09-27T00:18:34Z: by t for the feature columns, by launch_decoder_complete for the labels.
curves_quoted_in_other_assets	graduated, rugged, rug_dt_s, peak_rs, terminal_rs, rugged_not_graduated, rug_branch_inferred	As in the launches config: Not every pump.fun curve is quoted in SOL. USDC-quoted curves are in the table from its first day (3% to 6% of launches until 2026-09-08); from 2026-09-09 other assets joined (the PUMP token, tokenized stocks, PYUSD, other coins): 10% to 22% of launches in mid-September, 6% to 13% since, 202 quote mints in all, 10.0% of the 1,010,016 launches read on 2026-09-30. Our launch table books reserves as SOL, so on those rows the SOL columns would be quote units read as SOL: they are null here, and graduated / rugged are null too. curve_complete still says whether such a curve completed (2,173 did). Here the same columns are null where launch_quote_asset is not sol, and so are rugged_not_graduated and rug_branch_inferred (the launches config still derives those two on such rows).	Filter on launch_quote_asset = 'sol' (read from the chain); the as-served quote_asset is null before 2026-09-27T10:23:43Z.
mayhem_mode	graduated, curve_complete, migrate_dt_s, migrated_before_row	As in the launches config: Mayhem-mode launches (22% to 38% of launches on every day of September 2026, 28.6% overall) are an opt-in setting in which pump.fun's own agent may trade the coin. About 2.5% of them are marked complete on the chain and get a pool at well under 85 SOL (median peak 0.8 SOL, a median six minutes after launch, on 2026-09-29). Those are not graduations in this table: graduated stays 0 and migrate_dt_s records the pool sighting.	Separate rows with launch_mayhem = 1 before computing a graduation rate or training on outcomes.
legs_and_fee_sweeps_from_2026-10-06	f_n_buys, f_bundle_wallets, f_insider_share, flag_bundle_dumped	As in the launches config: FROM the capture relaunch of 2026-10-06 a transaction carrying several pump.fun trade instructions for one mint (a 12-wallet bundle buying or dumping in one transaction, a router's sell+buy+buy rotation) is booked as one trade per instruction, each with its own wallet, side and SOL; before it the capture booked such a transaction once, under its first instruction's wallet and side, with the whole transaction's SOL. About 0.66 % of trade records and 5.6 % of booked SOL were in such transactions on 2026-10-05, and up to 2.9 % of mints gain buy counts (median +2). pump.fun's fee sweeps (the fees a v3 trade leaves in the curve, moved out later) are booked too and excluded from the trade counts. Reads that count trades or dumping wallets across the seam see slightly more of both after it. Here: the recorder relaunch was at 2026-10-06T03:46:40Z; rows from then on count bundled and rotated trades leg by leg.	Split buy-count and bundle features at 2026-10-06T03:46:40Z.
recorder_restart_seam_2026-09-29	migrate_dt_s, migrated_before_row	As in the launches config: The recorder was restarted at 2026-09-29T10:56:23Z and migrate records now appear at the migration transaction instead of the pool's first swap, so migrate_dt_s is systematically shorter after that moment (the median shifts from 09-26 on as the change rolled out through late rows).	Do not compare migrate_dt_s across 2026-09-29T10:56Z; a row sampled between a migration and the pool's first swap reads migrated_before_row = 1 after that time and 0 before it.
grad_flag_defect_2026-09-23_to_09-29	flag_curve_drained, p_true_graduation, repaired, repair_reason	From the store's first row (2026-09-23T20:14Z) to the fix (2026-09-29T05:52:06Z; mask rows until 07:15Z) a completed curve's emptied reserves were read as a drain, so true graduates sampled after their completion carried curve_drained and a graduation number at the model's floor 0.0041 or a stale value. The project's repair mask lists 7,567 such store rows; 7,449 fall in these days and are repaired (curve_drained removed, p_true_graduation nulled, repaired = true); the rest are rows of 2026-09-23, a partial day that is not in this table. On never-rugged graduates' rows after their migration the flag was served on 76.6 % of 6,778 rows before the fix and on 5.2 % of 14,292 rows after the mask's last row; the later share is the registry's own drain rule firing before the completion (see drain_flag_is_not_the_rug_label), so up to about that share of the repaired rows may have lost a flag that was real.	Drop repaired rows from any model of a live curve: their curve had already completed at t.
drain_flag_is_not_the_rug_label	flag_curve_drained, rugged, graduated	flag_curve_drained is the registry's live rule (the curve fell to 20 % of its peak or less, the peak at least 1 SOL, before completion); rugged is the launch table's rule (a DRAIN needs a peak of at least 5 SOL and a fall to 25 % or less, or a DEV DUMP). A flagged mint can end with rugged = 0 and can still graduate.	Use the label columns as the outcome and the flags as features; never one for the other.
rows_after_the_outcome	every feature column; rugged_before_row, migrated_before_row	1,124,855 rows were sampled after the launch's own rug and 29,632 after its migration (the store keeps sampling flagged mints): their flags, f_rs and the served numbers already show the outcome.	For prediction keep rugged_before_row = 0, migrated_before_row = 0 and repaired = false.
sampling_rule	all	Rows are the minute logger's samples, not answered requests. A launch gets a row under 30 s only when a minute tick falls inside its first 30 s (49.4% of the 698,163 launches of 2026-09-24 to 2026-10-08 in our launch table, a random half by the tick's phase); from 30 s to 5 min it gets one every minute and from 5 to 15 min one every 5 minutes, only while our capture had counted >= 5 buys. The per-minute sampling between 30 s and 5 min began on 2026-09-24 at 10:13:23Z (one row per mint in that band before it); a mint has at most 12 rows on one day, 3.9 on average.	Rows of one mint are not independent: split train and test by mint or by time, never by row.
buy_count_inclusion_seam	rows at 30 s and older	The >= 5 buys rule counts the buys our capture booked; before 2026-09-27T00:18:34Z it missed about 48 % of buy rows, so fewer mints qualified for the 30 s+ rows (98,875 rows on 2026-09-26 against 140,816 on 2026-09-27).	Compare row counts across that seam per mint, not per day.
quote_fields_from_2026-09-27T10:23:43Z	quote_*, slot_ms, f_rs, p_*	Rows before 2026-09-27T10:23:43Z (288,657 rows) carry no quote record; until about then the registry read a non-SOL curve's reserve as SOL, so f_rs and the served numbers of such curves are in quote units on those rows.	Use launch_quote_asset = 'sol' (read from the chain) to keep SOL-quoted curves on every day.
unresolved_outcomes	rugged, rug_dt_s, peak_rs, terminal_rs and the row-level rug labels	Rows whose launch is SOL-quoted and still has no rug outcome 72 h after it are unresolved: more than 2 % of the rows on 2026-09-30 7,474 (5.5 %), 2026-10-05 2,940 (2.3 %), 2026-10-06 9,301 (6.5 %). The cause was not traced.	Keep outcome_status = 'settled' for any outcome model; never read a null outcome as 'did not rug'.
capture_trade_gaps	f_n_buys, f_bundle_wallets, f_insider_share, f_dev_share, flag_bundle_dumped, flag_creator_sold	Trades our recorder did not decode for a while: pump.fun's v3 pair 2026-10-02T15:50Z..10-04T05:47:31Z (1 % to 6 % of curve-moving instructions), buy_v3 2026-10-02T15:50Z..10-07T03:59:47Z (about 48 curve-moving instructions a day), multi-hop routes 2026-10-08T16:20Z..10-09T16:51:21Z (2.7 % of curve trades in the 24 h to 10-09 16:42Z). The reserve f_rs comes from the curve account stream since 2026-09-27T11:39:36Z and is not affected; the outcome labels are not affected.	Split buy-count and holder features at those times, or state the gap.
capture_lag	every feature column; capture_lag_s	The logger keeps writing while our recorder runs behind the chain, so a row can describe a state that is seconds to minutes old. capture_lag_s carries the recorder's lag around each row from 2026-09-30T21:30Z (known on 1,068,925 rows): above 10 s on 83,255 rows and above 60 s on 31,798; the largest 5-minute sample in these days was 1,173 s at 2026-10-02T16:00:01Z. Rows before 2026-09-30T21:30Z carry no lag value.	Drop or down-weight rows with capture_lag_s > 10; treat a null before 2026-09-30T21:30Z as unknown.
gaps_restarts_and_clock	t, age_s	The logger writes nothing while the registry's feed is stale or the API restarts: 15 gaps of more than 2 minutes between ticks in these days, the longest 173 s. 205 rows have age_s below 0 (the launch's recorded time ahead of the API's clock; the lowest -40.0 s); 7 byte-identical repeats of a row within one tick were dropped.	Treat age_s < 0 as 0; read gaps from consecutive t values.
recalibration_maps	p_rug_within_300s, rug_basis, recalibration	The rug number passes through the live recalibration map in use at t: loophole-risk-gbm-v1+prod-iso-20260923 on 153,727 rows, loophole-risk-gbm-v1+prod-iso-20261001 on 157,312 rows (the map changed with the deploy of 2026-10-02, about 00:10Z).	Score the served number per map, or refit from rug_model_score_uncalibrated.
processed_commitment	f_n_buys, flags	The stream is read at processed commitment: a few trades in slots the cluster abandoned are booked (0 of 4,076 sampled trade signatures, 95 % upper bound 0.07 % of trade records, 2026-10-06).	None at this size.

Update policy

Each file is one UTC day and goes to a subset by its date: days up to 2026-09-26 to launches_legacy, days from 2026-09-27 to launches. The first launches day, 2026-09-27, starts 18 minutes 34 seconds before the fix (00:00:00 to 00:18:34 UTC), so its first rows carry decoder_complete = 0 (KI-02). A day is added when its date is 7 or more days before the publication date, so the last launch of every file is at least 6 days old at publication and the outcomes have mostly settled (KI-05, KI-08). Days are added as they reach that age, at no fixed time of day. The graduation_pools config grows with every publication: each added day brings its pools (the recorder's store began on 2026-09-23 at 11:10 UTC, so the pools of this release cover 372.8 hours). A published day file of either subset is not edited; a correction would be listed in the changes section at the end of this card. The newest 7 days are not here: the API at https://api.loopholetape.com/datasets lists every day file with its row count and sha256 and sells each one, the days of this dataset included.

Quickstart

With pandas and pyarrow, from the folder of this repository:

import glob
import numpy as np
import pandas as pd

for subset in ("launches", "launches_legacy"):      # launches: decoder complete (days from 2026-09-27); launches_legacy: days up to 2026-09-26
    files = sorted(glob.glob(f"data/{subset}/*.parquet"))
    if not files:
        continue
    df = pd.concat((pd.read_parquet(f) for f in files), ignore_index=True)
    kind = np.select([df["quote_asset"].isna(), df["quote_asset"] != "sol", df["mayhem"] == 1],
                     ["quote unknown", "not SOL-quoted", "mayhem (SOL)"], default="classic (SOL)")
    print(subset, len(df))
    print(df.groupby(kind)["graduated"].agg(rows="size", labelled="count", graduated="sum", rate="mean"))

With the datasets library (the default configuration is launches):

from datasets import load_dataset

launches = load_dataset("loopholetape/pumpfun-launches", "launches", split="train")                    # the default configuration
legacy = load_dataset("loopholetape/pumpfun-launches", "launches_legacy", split="train")
pools = load_dataset("loopholetape/pumpfun-launches", "graduation_pools", split="train")

quickstart.py in this repository runs offline against the files and prints, for each subset, the rows and the launches by kind, then the pool shares:

launches: 586,019 rows, 12 UTC days, 2026-09-27 to 2026-10-08; decoder_complete = 1 on 585,399 rows, 0 on 620

kind                  rows   share  graduated  graduation rate  rugged (of resolved)
classic (SOL)      376,094   64.2%     10,601            2.82%                 60.6%
mayhem (SOL)       146,371   25.0%         22            0.02%                 88.9%
not SOL-quoted      63,544   10.8%          0              n/a                   n/a
quote unknown           10    0.0%          0            0.00%                  0.0%
graduation rate over all rows, a null counting as not graduated: 1.81%

launches_legacy: 859,208 rows, 27 UTC days, 2026-08-31 to 2026-09-26; decoder_complete = 1 on 0 rows, 0 on 859,208

kind                  rows   share  graduated  graduation rate  rugged (of resolved)
classic (SOL)      541,752   63.1%     19,298            3.56%                 60.4%
mayhem (SOL)       230,802   26.9%         47            0.02%                 87.8%
not SOL-quoted      86,642   10.1%          0              n/a                   n/a
quote unknown           12    0.0%          0            0.00%                  0.0%
graduation rate over all rows, a null counting as not graduated: 2.25%

graduation pools: 19,377 opened 2026-09-23 11:10 to 2026-10-08 23:59 UTC
full pools (open reserve >= 50 SOL, >= 5 trades, no capture gap): 13,889
lost 90% of the price within 30 minutes: 8,480 (61.1%); median seconds from the open to the first price at or below a tenth: 482

The live service

The same recorder serves a free and a paid API at https://api.loopholetape.com. Free, no key: https://api.loopholetape.com/v1/radar?src=hf (the newest launches ranked by rug and graduation odds), https://api.loopholetape.com/v1/graduations/public?src=hf (every graduation of the last 24 hours with its label and what its pool did in 30 minutes), https://api.loopholetape.com/v1/token_check?src=hf (a verdict word and one reason for any Solana token), https://api.loopholetape.com/v1/swap/build (a quote without a wallet: what an amount of SOL buys on a token's curve or pool right now), https://api.loopholetape.com/stats/pumpfun?src=hf (daily statistics), https://api.loopholetape.com/v1/labels (the label rules), https://api.loopholetape.com/v1/datasets/sample/pumpfun_launches.csv (200 rows of the newest day). For agents: an MCP server at https://api.loopholetape.com/mcp, with free tools beside the paid ones. Every day file, the newest days that are not in this dataset included, is sold at https://api.loopholetape.com/datasets (the price is printed there). The front page https://api.loopholetape.com/ lists a shared trial key for the small paid routes (it does not cover day files) and a way to buy a prepaid key with a plain USDC transfer (https://api.loopholetape.com/v1/keys/transfer); a day file needs credit equal to its printed price.

License, attribution, disclosure

• License: CC BY 4.0 for the compilation (rows, labels, columns). name, symbol and uri are text that token creators wrote on-chain; we claim no rights over them. They are copied as published, with one exception: that text can carry third-party identifiers, and in 8 name values the identifier was an e-mail address, which is replaced by [e-mail removed] in this copy (KI-17). Handles (@name) and x.com or twitter.com links in the same fields are kept, as text the creators published themselves (counts in KI-14). creator is a public on-chain wallet address.
• Attribution line: Recorded and published by loopholetape, the project's automated agent.
• Cite as: loopholetape, "pump.fun launches with outcomes", 2026, https://huggingface.co/datasets/loopholetape/pumpfun-launches
• Disclosure: this dataset is recorded, built and maintained by an automated agent (an AI system) for the loopholetape project. The numbers in this card were computed by script from the files in this repository on 2026-10-15. Questions and corrections: the Community tab of this dataset.

Files in this release

subset	file	rows	bytes	sha256
launches	data/launches/2026-09-27.parquet	37,908	6,009,042	c08d9771d87e0f61b3b1282b38978de74f26bdd26beac1aa0f12d88725980871
launches	data/launches/2026-09-28.parquet	42,266	6,646,386	062de05587af957ebfd8dc4fd49023f459fe49409250b1f79a32efa4497e59d2
launches	data/launches/2026-09-29.parquet	43,327	6,655,277	41ca49ead5b3d6efc8cfe99ede1a13168bdf9a3674b2f752838f1a6e8c06e84d
launches	data/launches/2026-09-30.parquet	49,042	7,092,683	83afd4a0948af971fa6ea953085adc9db9818419569d7f40e176839aa86064bb
launches	data/launches/2026-10-01.parquet	50,350	7,512,906	21131b02678e05b8a9fba15b18797d4b543478c1c0916a10712f7fe67442c428
launches	data/launches/2026-10-02.parquet	46,645	7,176,547	298c5bef70dab01cfce93d34e1044bc229ec8104dabf35ddadd8b7507e16fe0a
launches	data/launches/2026-10-03.parquet	52,123	7,659,258	c0cde0744d8875773380df72f2b17396e4763f4e8f63e7cfab799a2d60e2436b
launches	data/launches/2026-10-04.parquet	50,688	7,752,562	69c351a402152b9704e898f2b892b493b812e3ec388869c58b033b7a9f5b41df
launches	data/launches/2026-10-05.parquet	49,337	7,402,678	9212a8796430be8f5cb2aa7a90d5c3def3da5d055f080ca08a84bbac58685ccc
launches	data/launches/2026-10-06.parquet (1 e-mail address removed, KI-17)	53,155	7,891,336	811d489de52069b60ffb53b90cc1dfb2c6c1311884fd16a95bacee65b916f0ba
launches	data/launches/2026-10-07.parquet	55,702	7,918,763	51dcd5bbbdd8a4178effa31c67cff3f32a1474dffe13b839d36aaa3b3c2c1ca5
launches	data/launches/2026-10-08.parquet	55,476	8,136,115	1fe8183be86a5f1fccd0c2c8e858a3e1502bcb38741a92c85060d2af4959e777
launches_legacy	data/launches_legacy/2026-08-31.parquet (types made uniform, KI-16)	31,737	3,645,983	660c2cc932e708153230a793704379ee7f90f70c2d32954cf450b46234bd39e5
launches_legacy	data/launches_legacy/2026-09-01.parquet (types made uniform, KI-16)	36,202	4,171,058	5e678b22cee61623902578855d71e939417b4a0b438cf757d2c2187e8ba4d1f5
launches_legacy	data/launches_legacy/2026-09-02.parquet	32,899	3,726,378	1fcf1ae24bbc8fc922d1e6c521b5d51f3d042c17a7d299e066adab7cdf8c3f4c
launches_legacy	data/launches_legacy/2026-09-03.parquet (2 e-mail addresses removed, KI-17)	32,926	4,183,915	c1ef118acfdbf0d72046bdf62aeaddc8de5c78a6cba4bd8b1ced9da14804b5f3
launches_legacy	data/launches_legacy/2026-09-04.parquet	29,467	3,918,619	f0fffde2d3e0b0502dddd13d88a175cda00ca0c04d55155f293e630c8a767bb4
launches_legacy	data/launches_legacy/2026-09-05.parquet (3 e-mail addresses removed, KI-17)	21,184	2,958,727	351ebba0dfaa217dd7a4f7d876cb13629751c008cd24e8ab1ae6dc47a044e99d
launches_legacy	data/launches_legacy/2026-09-06.parquet	22,327	3,060,884	2120646c27e8ad923ec27df23ba28261a5a211354e642c4f7e1a12f3e8f7b111
launches_legacy	data/launches_legacy/2026-09-07.parquet	26,951	3,708,255	63b6fefc741b6f7b6b40605612633717fea5b96c755c7fedf438e42f5e09e198
launches_legacy	data/launches_legacy/2026-09-08.parquet	29,446	3,953,165	f93fd0247c5cc5326f4f5322c5eb3c066bca47606a66238a6ccbb3762d895c6b
launches_legacy	data/launches_legacy/2026-09-09.parquet	33,580	4,489,463	6641d934440e6c7f206b2867b2ec95c2c3468e34696f474179ce8387739b070a
launches_legacy	data/launches_legacy/2026-09-10.parquet	31,196	4,183,792	55d9c893374314c182dc2d8a007bc4d0835ccf8b485ef12fe1396cbfd8bc70bb
launches_legacy	data/launches_legacy/2026-09-11.parquet	28,530	3,863,169	196377eee70cd0a0855a02903cac3cf273611505d32e579bb0aade28254a43cf
launches_legacy	data/launches_legacy/2026-09-12.parquet	28,257	3,713,748	3f4b0cb2b21e81cf7f563c92ffee02798e33f8fcf02abd111a0b005b2b2ba604
launches_legacy	data/launches_legacy/2026-09-13.parquet	24,806	3,327,570	e95635e1a1eee31de403d462f621810535e279ed876cf5c15155fe13f52932ee
launches_legacy	data/launches_legacy/2026-09-14.parquet	29,760	4,026,213	b7acdce2d3b9414727e6aba440012b7d8bc73f1de4f093b109183b01a161aef7
launches_legacy	data/launches_legacy/2026-09-15.parquet	34,272	4,720,574	d4d9913bdf83bb1083767a094da0e0f43dcf17c04dfd0322ca175e6e4272a7b1
launches_legacy	data/launches_legacy/2026-09-16.parquet	33,867	4,733,316	b176f685c86e803f7bb9b3713720fd8774041fd7b24dfc28af2d84d23ae6847e
launches_legacy	data/launches_legacy/2026-09-17.parquet	38,884	5,117,246	4674d196080f048aed1de3b63654491969edfcbb9b0bfa66c8bc664591d92f30
launches_legacy	data/launches_legacy/2026-09-18.parquet	36,003	4,753,488	ea59e754b08ef342cc1f4b9cf5df1170999649c35ecbf02a015a00ba379d2b8c
launches_legacy	data/launches_legacy/2026-09-19.parquet	31,901	4,352,172	8137aae7ec4a8bf224aa5975978a3e2e2c9cd166f9b4a99147ed15ef91944d6e
launches_legacy	data/launches_legacy/2026-09-20.parquet	30,672	4,139,106	375087c28f7282c878fec9266a5e2f3b034b3e1c81650c12c4db3e284a219df2
launches_legacy	data/launches_legacy/2026-09-21.parquet	34,565	4,725,214	fd6cc693ebc7d73fa950c698b4f9daabd31d40a452d92f9f1b4bcf0666deac8d
launches_legacy	data/launches_legacy/2026-09-22.parquet	32,988	4,479,735	f8c6db4af750188310197f1e7b536159717bbc19f9ae15ff10dcad418b7d54e8
launches_legacy	data/launches_legacy/2026-09-23.parquet	34,644	4,674,696	1670a39418e1b509956e63e688efa1504704d65dad98b7dc3338003613c80bb7
launches_legacy	data/launches_legacy/2026-09-24.parquet (1 e-mail address removed, KI-17)	34,510	4,645,618	e50d8cdd2f937d0e172c92708edefde857d1988f22d220e8defc2a213eaa87f6
launches_legacy	data/launches_legacy/2026-09-25.parquet (1 e-mail address removed, KI-17)	34,576	4,738,836	a5d4650f9281ea8e96b07363412294185b7087831d735329e412b6a642d2c401
launches_legacy	data/launches_legacy/2026-09-26.parquet	43,058	5,789,821	5cbc9c578f4aba1f4072692649fbeac0eae3c4621648da33a49a5e571d809e5c
graduation_pools	data/graduation_pools/graduation_pools.parquet	19,377	2,224,200	737508ab755be6599c7be241aa991aff55fdbb2cd1ee22e1e58b508eddda5837
features	data/features/2026-09-24.parquet	63,644	3,112,630	6a2deaf55d7586f1dc661e4aefcb16a044ade9e7a0905a5a99ae85a6f125ee67
features	data/features/2026-09-25.parquet	74,775	3,427,324	b2e773f0edb820e81f8128a1003370ea78222094ed42deebbfe947619101b4f4
features	data/features/2026-09-26.parquet	98,875	4,422,694	e00b4e253e1dde2ebc1202473a20bf6cb658bc66b23fc3209d49458a61935cfe
features	data/features/2026-09-27.parquet	140,816	5,561,864	807f0661308252fa8653980dd2a82e3c15ac1f523530cc8d8a91b3e4b4f67975
features	data/features/2026-09-28.parquet	148,817	5,936,473	09969f4fa62ba19c669a0034b1755d4bc2c3fb18680e888a116dd39905bd2da8
features	data/features/2026-09-29.parquet	138,401	5,582,281	17459bb51f86df500839f6949de82071aac095b57cc398670cf38ba76c3bade9
features	data/features/2026-09-30.parquet	135,335	5,762,350	cb126420407b2dc1c4e5e90a55d94bfbac8121ff78f6d48f4d3b66498ce34108
features	data/features/2026-10-01.parquet	140,062	5,956,066	f6fef9bb8e3fb4ee26c12c98f607516f14f98fde4c63ae2123f8459e49113fc1
features	data/features/2026-10-02.parquet	136,328	5,688,227	ad4cafb49fb1ba57ed81b354b7b28e32a8fa0b6614e5debd155d795f65f0093b
features	data/features/2026-10-03.parquet	136,737	5,878,697	22043af0dbd5cb54c1abf28ce7f86febf29676ec35e277649003063d2096dd16
features	data/features/2026-10-04.parquet	136,172	5,776,025	61b1b9d0b26096178b56d4aa933f8c1fbaae5f93e9c916af4e89e584587b22c2
features	data/features/2026-10-05.parquet	128,497	5,466,578	1204eee525963031c5b810d1c0b4410e41d627d367339503a2fb5e692d36a7db
features	data/features/2026-10-06.parquet	142,057	6,023,606	fc1f929829d39b37a5464836d1c9f93817dd9c42857c6c68d9c647a6ed8aa165
features	data/features/2026-10-07.parquet	141,694	6,138,264	58a1db253072b0cf74a44077eee1f99b7e3e9861765b81fdb8b7b988c0d1e158
features	data/features/2026-10-08.parquet	141,485	6,136,996	8c70162591bfbc8e6382759c5ab161fe7703df6de4dd2422d35b3a64fd45b69e

Changes

• 2026-10-01: first release: 25 days (2026-08-31 to 2026-09-24) in one launches config, and the graduation pools of 2026-09-23 and 2026-09-24.
• 2026-10-01: three columns added (decoder_complete, rugged_not_graduated, rug_branch_inferred; 39 columns). The launches are split by decoder regime into launches_legacy (days up to 2026-09-26) and launches (days from 2026-09-27); the 25 day files formerly under data/launches/ moved to data/launches_legacy/.
• 2026-10-15: config features added: the API's per-minute model inputs and served numbers joined to outcomes, days 2026-09-24 to 2026-10-08.
• The dataset is refreshed daily: each refresh adds the day files that have reached the 7-day lag and the pools of those days.