Pump.fun Historical Data: How to Get Token Creations, Trades, Bonding Curves and Wallet Activity

If you need Pump.fun historical data, start by defining the question you need the data to answer.

Do you want every token ever created? Every buy and sell on a bonding curve? The first wallets to buy a mint? The point at which a coin completed its curve and migrated to PumpSwap? Or a dataset you can use to backtest a signal without accidentally using future information?

Those are different jobs. They need different records, and a generic list of Solana transactions is rarely the most convenient starting point.

This guide explains what Pump.fun historical data exists, how a token moves through its lifecycle, where the data comes from, and how to build a dataset suitable for research, analytics, wallet analysis and causal backtesting.

#Quick answer: what data do you need?

The common mistake is treating “Pump.fun data” as one table. It is a connected set of events that describes a token's lifecycle.

#What is Pump.fun historical data?

Pump.fun historical data is the record of activity created by the Pump program on Solana. Depending on the dataset, it can include:

• token creation and metadata references;
• buyer and seller addresses;
• buy and sell quantities;
• SOL amounts, fees and creator fees;
• bonding-curve and reserve values;
• completion and migration events;
• post-migration PumpSwap pool and trade activity.

Pump.fun coins begin on an on-chain bonding curve. Pump.fun describes that curve as a constant-product AMM using virtual SOL and token reserves: trades adjust the reserves, buys move the quoted price up, and sells move it down. It is not an order book with resting market-maker quotes. Pump.fun’s bonding-curve documentation is the primary reference for the current mechanism.

When the curve reaches its graduation threshold, liquidity is migrated atomically to PumpSwap. That transition is automatic and irreversible, so a complete history often has two distinct trading regimes:

create → bonding-curve buys/sells → curve completion → PumpSwap migration → AMM trading

If your analysis stops at the curve-completion event, it is not a full post-launch price history.

#The Pump.fun token lifecycle, explained

#1. Creation

A launch establishes the token mint, bonding-curve account and token metadata references. A useful creation record should let you identify at least:

• mint address;
• bonding-curve address;
• submitting user and stated creator;
• name, symbol and metadata URI;
• on-chain timestamp/slot and transaction signature;
• initial virtual and real reserves, where available.

Do not assume that the transaction submitter and the economic creator are always identical. Pump.fun’s public program documentation explicitly notes that the user and creator fields can differ in some flows. That distinction matters if you are measuring creator activity or trying to identify the launch wallet.

#2. Bonding-curve trading

Before graduation, each Pump.fun buy or sell occurs against the bonding curve. The key observations for a research-grade trade row are:

• token mint;
• trader wallet;
• buy or sell direction;
• token amount and SOL amount;
• trade timestamp and deterministic chain ordering fields;
• transaction signature and instruction path;
• virtual and real reserve values after the trade;
• protocol fee and creator fee, when emitted.

The actual execution price for a row is normally derived from the amounts exchanged, after clearly documenting whether it is gross or net of fees. Do not substitute a later chart price for the price that was observable at the event.

#3. Completion and migration

Completion means the curve has run out of real token reserves. Migration is the on-chain move into a PumpSwap pool. These are related events, but they should not be collapsed into one timestamp without checking the chain records.

Pump.fun's public program documentation describes complete as occurring when real token reserves reach zero. It also describes migration to PumpSwap as permissionless and idempotent after completion. In data terms, this means a token can have a clear curve-completion event and a separately identifiable migration instruction/event.

#4. PumpSwap trading

After migration, the token is no longer trading on its original Pump.fun bonding curve. You need PumpSwap trade and pool data to measure post-migration price, liquidity, volume or wallet activity.

This is a crucial modeling boundary. A backtest that buys on the curve and exits using a post-migration AMM price must join two protocol datasets and define how it handles migration timing and execution.

#Where can you get Pump.fun historical data?

There are three practical approaches.

#Option 1: Build from raw Solana history

You can collect or backfill Solana transactions, filter the Pump program, decode instructions and events, parse inner instructions, derive token/SOL movements, and store the result yourself.

This gives you the most control, but it is a real data-engineering project. A correct implementation must handle:

• program instruction versions and upgrades;
• nested/inner instructions and emitted events;
• failed versus successful transactions;
• transaction and instruction ordering within a slot;
• replayed or duplicate ingestion records;
• token decimal handling;
• protocol transitions from Pump.fun to PumpSwap;
• long-term storage, backfills, schema changes and reprocessing.

Raw history makes sense if you are building a universal Solana indexer or require fields outside a prepared schema. It is often unnecessary if your objective is research on Pump.fun itself.

#Option 2: Query an API or RPC provider

An API or RPC is useful for a narrow time range, current state, one token or a small number of wallets. It is usually a poor architecture for repeatedly scanning years of all Pump.fun activity.

For large studies, paging transaction responses and repeatedly decoding generic instructions creates avoidable operational work. It can also make it harder to prove exactly what historical data was used in a research run.

#Option 3: Use a prepared decoded dataset

A decoded historical dataset is designed for analysis rather than for recreating an indexer. It should expose typed records for launch, trade, completion and migration events, retain chain join keys, document its schema, and make coverage and corrections explicit.

datastore.sh’s Pump.fun dataset is delivered as 45 typed, date-partitioned Parquet tables: 32 instruction tables and 13 event tables. The documented schema includes decoded create, buy, sell, completion, migration and trade-event records, alongside newer instruction variants. Files are versioned, delivered with manifests and SHA-256 checksums, and corrections are republished as new versions.

#What should a good Pump.fun dataset contain?

Not every question needs every table. But a usable historical dataset should make the following joins possible.

Two implementation details deserve special attention.

#Preserve both instructions and events

Instructions describe the requested action and its accounts/arguments. Events often contain the realized trade amounts and reserve state. You should retain both when possible.

In the datastore.sh Pump.fun schema, events can be joined to their decoded parent instruction using both the transaction signature (sig) and instruction path (ix_path). Joining only on transaction signature can be wrong when a transaction contains more than one relevant instruction.

#Deduplicate with a documented business key

Data pipelines can replay records after a restart. A simple DISTINCT(sig, ix_path) is not universally safe because one instruction can emit more than one meaningful event.

The datastore.sh delivery documentation explicitly says its rows are delivered at least once and instructs users to compare all business columns excluding the ingest timestamp and internal replay flag when deduplicating. Adopt the rule for the actual source you use; do not silently assume every provider has exactly-once delivery.

#How to reconstruct a Pump.fun bonding curve

You can estimate prices from trade amounts, but a curve reconstruction needs the reserve state.

Pump.fun's public documentation describes a constant-product relationship between virtual SOL reserves and virtual token reserves. In simplified form:

virtual_SOL_reserves × virtual_token_reserves = invariant

Each buy increases the virtual SOL reserve and decreases the virtual token reserve. Each sell moves those values in the opposite direction. The immediate marginal price is related to the reserve ratio; the average price paid by a trade depends on how far the trade moves along the curve.

For historical work, do not hard-code a single set of initial reserves or fee parameters for every time period. Protocol parameters and instruction variants can change. Instead:

1. start with the creation event/instruction for the mint;
2. retain the actual reserve fields emitted with each trade;
3. calculate prices and progress using the parameter/version appropriate to that row;
4. flag missing or inconsistent reserve transitions instead of filling them with future state;
5. retain the raw units and decimals used in each calculation.

The TradeEvent documented by datastore.sh includes sol_amount, token_amount, is_buy, the user, timestamp, virtual reserves, real reserves, fee fields and creator-fee fields. That is enough to build a detailed curve-state timeline when the data is correctly ordered.

#How to find first buyers and wallet activity

“First buyer” sounds simple, but it needs a precise definition.

For a token mint, a defensible definition is:

A first buyer is a wallet whose earliest successful buy event for that mint is among the first N distinct buyer wallets ordered by deterministic on-chain event order.

Use a deterministic order, such as slot, transaction index and instruction/event path. Timestamps alone can tie or fail to capture the order of multiple actions inside one block.

You should also decide how to treat:

• the creator’s own buy;
• buys in the same transaction as creation;
• multiple buys by the same wallet;
• wallets funded by a common parent;
• token-account addresses versus wallet owners;
• failed or reverted attempts;
• buys executed after the curve has completed.

For wallet research, calculate separate measures instead of one vague “smart-money score”:

• launches created;
• first-buy frequency;
• median entry delay from launch;
• buy/sell notional;
• holding duration, if balance history is available;
• realized trading result under a defined accounting method;
• creator-fee collection;
• token graduation rate conditional on a wallet's early entry.

None of these proves a wallet is informed. They are behavioural measurements that need validation on a held-out time period.

#Pump.fun data for backtesting: avoid the usual traps

Pump.fun is an excellent backtesting use case because the lifecycle is visible on-chain. It is also easy to produce an unrealistic result.

Suppose your rule is:

Buy a token when it reaches 50 unique buyers in its first 60 seconds. Sell ten minutes after it migrates to PumpSwap.

At the decision time, the model may use only the facts that existed then:

• creation time and launch metadata already emitted;
• trades ordered no later than the decision event;
• unique buyers observed no later than that event;
• the price/reserves available at that time;
• costs and execution assumptions available at that time.

It may not use later graduation status, later wallet labels, end-of-day token metadata, future liquidity, a price chart generated after the fact, or a final list of “successful” tokens.

#A causal backtest needs these components

#Example: calculate the first-minute buyer count

The following is illustrative DuckDB-style SQL. Adapt names and decimal conversions to your delivered schema.

WITH launches AS (
  SELECT
    mint,
    timestamp AS launch_time
  FROM pump_fun_create_event
),
first_buys AS (
  SELECT
    t.mint,
    t.user,
    MIN(t.timestamp) AS first_buy_time
  FROM pump_fun_trade_event AS t
  JOIN launches AS l USING (mint)
  WHERE t.is_buy = TRUE
    AND t.timestamp >= l.launch_time
    AND t.timestamp < l.launch_time + INTERVAL 60 SECOND
  GROUP BY t.mint, t.user
)
SELECT
  mint,
  COUNT(*) AS unique_buyers_first_minute
FROM first_buys
GROUP BY mint;

In production, add deterministic slot/instruction ordering, source-specific deduplication, successful-transaction filtering and a documented policy for events whose timestamps coincide.

#API vs raw transactions vs Parquet

Parquet is particularly useful for large research workloads. It is typed and columnar, so an engine such as DuckDB, Polars, ClickHouse or Spark can scan the relevant columns rather than repeatedly parsing entire transaction JSON documents.

For example, a query that needs only mint, user, timestamp, is_buy, sol_amount and token_amount should not need to read a generic transaction’s full instruction list, logs and account arrays for every scan.

#Questions to ask before using Pump.fun data

Before you buy, download or build a dataset, confirm:

1. What exact start and end time does each table cover?
2. Which Pump.fun instruction versions are decoded?
3. Are both instructions and emitted events available?
4. Are failed transactions excluded or explicitly labelled?
5. Which fields identify chain ordering within the same slot/time?
6. How are duplicate or replayed records handled?
7. Are reserve and fee fields included on trades?
8. Can I distinguish creator, transaction submitter and trader?
9. Are completion and migration separate, documented events?
10. Is PumpSwap data available for post-migration history?
11. Are schema changes versioned?
12. Are files partitioned, checksummed and accompanied by a manifest?

The answers matter more than a headline row count.

#Frequently asked questions

#Can I download Pump.fun historical data?

Yes. You can reconstruct it from raw Solana history, use an API for narrower queries, or use a prepared decoded dataset. For large-scale analytics or repeated backtests, a typed bulk dataset is normally more practical than repeatedly paging and decoding transaction history.

#How do I get every Pump.fun token created?

Use decoded Pump.fun creation instructions/events and treat the mint as the token identifier. Retain the bonding-curve address, creator fields, signature, slot and event time so launches can be joined to later trades and migrations.

#How do I get Pump.fun buys and sells?

Use decoded buy/sell instructions or trade events. For analytics, prefer fields representing realized amounts and reserve state, and preserve the wallet, mint, transaction signature and deterministic instruction/event ordering.

#Can I calculate Pump.fun bonding-curve progress?

Yes, provided your data includes the appropriate reserve state and you apply the protocol parameters that were valid for the historical event. Do not infer progress from a current curve state or assume old and new instruction variants share identical parameters.

#How do I know a token migrated to PumpSwap?

Look for the documented completion and PumpSwap migration records, then join the migration record to the PumpSwap pool. Completion and migration should be treated as separate lifecycle events unless the chain data establishes they occurred together.

#Can I use Pump.fun data for trading backtests?

Yes, but only if the backtest restricts every feature to information available at the decision time and models trading costs, execution and the curve-to-PumpSwap transition. A strategy tested only against later chart prices is not an execution-quality backtest.

#Does datastore.sh provide Pump.fun historical data?

Yes. datastore.sh provides Pump.fun historical data as typed, date-partitioned Parquet tables with documented schemas. The current catalog describes 45 tables covering decoded instructions and events, including creation, buys, sells, trade events, completion and migration records. Delivery includes versioned manifests and SHA-256 file checksums.

#The key takeaway

The right way to think about Pump.fun historical data is not “Where do I get old token prices?”

It is:

“Which on-chain events do I need to reproduce the token lifecycle and answer my question without hiding assumptions?”

For launch research, start with creation records. For trading behavior, add ordered bonding-curve trades and reserve state. For graduation studies, add completion and migration. For a token’s full market life, join PumpSwap. And for a credible backtest, enforce causal event time from the first feature to the final exit.

If you need documented, analysis-ready Pump.fun history rather than a raw Solana decoding project, explore the Pump.fun historical dataset on datastore.sh.