Bulk datasets

pump.fun launches with outcomes and early features, one UTC day per file. Every launch our own capture saw that day, with the outcomes under the label rules at /v1/labels (true graduation, rug flag, timing); the last three days are rebuilt nightly because outcomes settle late. Facts from public on-chain activity, computed from our independent capture, not resold data and not advice. Coverage: 2026-08-31 to 2026-10-28, 59 day files, 2,378,371 launches in total.

free 200-row CSV sample · column schema (JSON) · index (JSON) · API front page · terms

Free history: every day file at least 7 days old is also published free on Hugging Face at https://huggingface.co/datasets/loopholetape/pumpfun-launches (the same files under the project's own account, with the dataset card's known issues; three day files there differ by six removed third-party e-mail addresses). The newest 7 days are sold here only.

How to buy a day ($5.00, parquet with zstd)

• HTTP + x402: GET https://api.loopholetape.com/v1/datasets/pumpfun_launches/{day} answers 402 with the payment terms (USDC on Solana or Base); the paid retry returns the parquet bytes with the sha256 in a header. Any x402 client works; in a browser with a Solana wallet the 402 shows a pay page.
• Prepaid key: buy a key once at GET https://api.loopholetape.com/v1/keys/new ($2.00 credit; add credit by buying again) and send X-API-Key; a day file needs $5.00 of credit.
• MCP: the tool buy_dataset(day) on https://api.loopholetape.com/mcp returns a one-hour download URL.

Unknown days answer 404 and nothing is charged. A day's sha256 and row count are published below and in the index before you pay.

Days available

Columns

Known issues of the data

Read these before modelling on the files; the same list is in the schema document.

• n_buys, n_sells and the buyer/seller counts inside f10_*/f60_*, bundle wallets, holder reputation counts: FROM the capture relaunch of 2026-10-06 (the time is in the backlog note NOTE_capture_multi_ix_seam_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. What to do: Split any read of buy, seller or dumping-wallet counts at the relaunch time, or restrict it to launches after it. Per-mint SOL totals move only on transactions that mixed sides (a sell beside buys was booked before as one trade on the first instruction's side); same-side bundles booked the same SOL once before and book it once in legs now.
• f10_*, f60_*, features_basis, create_lag_s, silence_3s, silence_60s: FROM 2026-09-27 (the first replayed day, features_basis = tape_replay) the early features cover every launch of the day: they were replayed offline from our archived event tape with the harness's own snapshot rule (the first buy or sell once the creation slot has passed, within 3 s of the launch, else the state at 3.0 s; f60 the first from 10 s on, else the state at 10.0 s), so there is no sampling bias in them. They are null only where create_lag_s > 1: the launch reached our capture more than 1 s after the validator stamped it (1.7 % of launches on 2026-09-28, 2.7 % on 09-29, 15.8 % on 09-30 with 57 % in its 16:00Z hour), and then the early state is not the launch's own. A launch nobody traded in its first 3 s carries the state at 3 s (n_buys 0, f10_age 3.0): 39-45 % of classic launches. A day file is harness_sample until its replay exists (about a day after the day ends); launches before 2026-09-27T00:18:34Z are never replayed (the tape holds only part of their buys) and keep what follows. harness_sample rows: feature snapshots exist only where our shadow harness sampled the mint: about half of the launches from 2026-09-03 (none on 08-31 and 09-01, a fifth on 09-02; three quarters of mayhem launches and half of the others on 2026-09-29), and f60_* only on the mints its copy strategies touched. The sampling is not random: a launch with no early activity is less likely to be sampled. MEASURED 2026-10-01 on the 25 released days: among resolved classic launches from 09-03 the recorded rug rate is 81.6 % where an f10 snapshot exists (191,635) and 39.5 % where none does (210,451): the sampled rows are a different population, not a random half. What to do: Read features_basis first. tape_replay rows: use the whole population; a null f10_* with create_lag_s > 1 is capture lag, not 'nothing happened'; read silence_3s > 0 as 'trades of this launch may be missing'; f10_age 3.0 with n_buys 0 means no trade in the first 3 s; rep_rug and rep_grad are the creator's record as it stood at the launch, which differs from the harness's lagging values on earlier days. harness_sample rows: never model the sampled rows as if they were all launches: weight by the sampling, or restrict the claim to sampled launches. A null with f10_age null means 'not sampled'. A null with f10_age present means a short snapshot (dev_share, bundle_wallets, rep_n, rep_rug, rep_grad and n_buys null together, about 8% of sampled rows, mostly snapshots at age 0.0-0.05 s), a creator with no resolved earlier launch in our table (rep_rug, rep_grad; about 27% of full snapshots) or a curve not quoted in SOL (rs). Never read a null as zero. Model on the sampled rows and say so, or use the outcome columns alone.
• f10_n_buys, f10_bundle_wallets, peak_rs, rugged, rug_dt_s: 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). What to do: Split any model or statistic at that timestamp.
• quote_asset, quote_mint, and every SOL-denominated column: 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). What to do: Filter on quote_asset = 'sol' for anything measured in SOL.
• mayhem, curve_complete, migrate_dt_s: 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. What to do: Separate mayhem rows before computing a graduation rate or training on outcomes.
• graduated, rugged, peak_rs, terminal_rs, curve_complete: Outcomes settle late: the newest three day files are rebuilt every night, and a few percent of the newest day's rows are still unresolved (null rugged / peak_rs). What to do: Use files at least three days old for labels, or re-download the newest ones.
• all: One recorder on one stream: a launch our capture did not see is not in the table, and a launch whose only trades it missed has peak_rs 0. Recorder restarts are listed in the API's changelog; the capture has run without a known multi-hour gap since 2026-08-25. What to do: Count launches against an independent source before using the table as a census.
• rugged, rug_dt_s, dev_first_sell_dt_s, peak_rs, terminal_rs: On 2026-09-01..09-04 a large share of SOL-quoted launches never resolved: null rugged / rug_dt_s / dev_first_sell_dt_s / peak_rs / terminal_rs on 21.8 % of 09-01, 63.9 % of 09-02, 43.9 % of 09-03 and 12.8 % of 09-04 (44,866 rows; 08-31 has none and later days a few percent); 462 of them are labelled graduated and 968 have curve_complete = 1 (measured 2026-10-01 on the 31 day files). The cause was not traced; the days coincide with the label recall dips below. What to do: Drop rows with a null outcome from any outcome model, or drop those four days; never read the nulls as 'did not rug'.
• graduated: Against the chain's own complete flag the graduated label's recall is 98.5 % over the month but 97.4 % on 09-01, 89.5 % on 09-02, 94.8 % on 09-03, 97.2 % on 09-04 and 97.8 % on 09-15; precision is 99.98 % on every day (measured 2026-10-01). The dips fall on the unresolved early days above. What to do: For a graduation label use curve_complete on SOL-quoted, non-mayhem launches where it is present, and graduated elsewhere.
• migrate_dt_s: 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). What to do: Do not compare seconds-to-graduation across 2026-09-29T10:56Z without allowing for the seam.

The graduation label, checked against the chain

On 1,379,897 launches quoted in SOL and not in mayhem mode (59 day files), the curve account's own complete flag is set on 42,893. Our graduated label names 42,333 of them (98.7%) and 70 launches the chain does not call complete (99.8% of the launches it names are complete on the chain).