Token launch data: deployments, liquidity, and the first trades
Onchain, a token launch is three records: a CREATE trace, an LP creation event, and the first wave of trades. On launchpads it is one instruction stream, keyed by program ID and discriminator. SQD serves both shapes from one endpoint across 225+ networks, with history back to genesis, so a screening pipeline reads a launch as the chain recorded it.
A token launch is an onchain record before it is a score, and screening reads the record
On EVM chains that record is spread across three types: a create trace for the deployment, a PairCreated or PoolCreated log for the liquidity, and the token's first Transfer logs. On a launchpad it collapses into one instruction stream, keyed by a program ID and an 8-byte discriminator: the token name and creator wallet decode from each create instruction's data, and the same filter with the buy and sell discriminators returns its trades. Read the naive way, each piece comes from a different tool, and eth_getLogs never sees a CREATE at all. It is all onchain already; the work is in reading both shapes through one query.
The launch feed is one filter: program ID plus discriminator
On a launchpad, a new token is not an event log; it is an instruction sent to the launchpad's program. pump.fun (6EF8…F6P) is an Anchor program, so the first 8 bytes of each instruction's data name the call. Filter the solana-mainnet instruction stream by the program ID and the launch discriminator, and every new token streams back. Two hundred pinned slots, about 80 seconds of chain time, return 11 launches:
- 013 Kittenwifhat 2nZS…pump
- 024 Fenix Flexin 4YWj…pump
- 036 catwifouthat not committed E15D…pump
- 054 GOKS 26Ew…pump
- 084 RED BULL 2ERJ…pump
- 105 Kittenwifhat 9kEx…pump
- 111 THE EARLY BULL HAhd…pump
- 155 name withheld 2v6A…pump
- 156 name withheld 76s5…pump
- 158 name withheld Diun…pump
- 161 how is this not flying 88fv…pump
data; the mint is the first entry in its accounts list. Three rows share one name that attacks a named individual: the query returns it, we do not reprint it, and the linked mints resolve it.
The decoded creator field is where screening starts. The three withheld rows above carry one identical name, launched within three slots of each other, and all three decode to the same creator wallet, CuHY…W3wG: one wallet stamping out three copies of one name, visible in the raw feed with no enrichment.
Ten of the 11 committed. The one that did not (slot 431,950,036) came back with error: null and isCommitted: false: the create itself did not fault, its transaction failed elsewhere and rolled it back. The two flags are independent, and a feed that drops uncommitted rows undercounts launch attempts.
The query is a program ID, a discriminator, and a slot window. No IDL registration, no deployed indexer:
Trades are the same filter with the buy and sell discriminators, pinned to one mint by its account position ("a2"). For the first launch above (2nZS…pump), the first 200 slots return 239 trade instructions: 132 buys and 107 sells, with committed buys from 92 distinct wallets and 19 attempts uncommitted. The creation transaction itself (2zup…XmxY) carries the creator's own first buy, the create at instruction address [2] and the buy at [4], and the next three transactions in the same slot are three more wallets buying. On a launchpad, deployment and first trade are one transaction; join on the transaction, not on time.
One gotcha: the discriminator older walkthroughs compute returns nothing. sha256("global:create"), 0x181ec828051c0777, matched zero instructions over 2,000 slots of this window; launches now arrive as create_v2, 0xd6904cec5f8b31b4. A discriminator filter is an exact byte match, so verify it against the live stream, not against a cached IDL or a tutorial.
EVM launch forensics: the token, the pool, and the deployer's past
On EVM chains a launch is spread across three record types the Portal serves side by side: a create trace, an LP creation log, and the token's first transfers. At Ethereum block 25,495,121 (2026-07-09), wallet 0x2b6a…3bfb sent three consecutive transactions: the first deployed token 0x93b1…375f, and the third, a call into the new token, created its Uniswap V2 pair, logged by the factory as PairCreated number 515,228. The surrounding 5,000 blocks, roughly 17 hours, carry 11 PairCreated logs from that factory, each one a new pool. The deployment record of any token is one trace filter:
The request filters with flat names, the response nests: createFrom arrives as action.from, createResultAddress as result.address. A trace also carries no transaction hash of its own; "transaction": true joins the parent transaction, whose from is the wallet that signed. The distinction matters on launchpads: for a factory-deployed token, action.from is the factory contract and transaction.from is the person. Flip the filter to createFrom and the same stream is the deployer's history: scanned across the million blocks up to the chain head, this wallet has exactly two deployments, this token and a second one (0xfb1c…d679) 1,023 blocks later, also paired against WETH in its own deployment block. A fresh wallet repeating one launch pattern twice in an afternoon is exactly the record a screening model runs on, and it took two queries to establish.
Early-holder concentration is a fold over the token's first Transfer logs. The deployment block alone has 16 of them, and they reconcile exactly: one mint of the full amount to the deployer, 92% of it moved into the token contract, 69% seeded into the pair, then six wallets bought 8.82% back out of the pool before the block ended, with another 2.94% flowing from the pool back to the token contract along the way. The ledger at the end of the block:
- Uniswap V2 pair 0x0e1f…a11b 57.24%
- The token contract itself 0x93b1…375f 25.94%
- Deployer wallet 0x2b6a…3bfb 8.00%
- Six buyer wallets, combined 8.82%
Getting the same picture from raw RPC means three different node facilities at once: trace_block or debug_traceBlock on an archive node for the deployment (standard eth_getLogs cannot see a CREATE), log pagination for the transfers, and a per-launch loop over both. Here the three record types answer the same declarative query shape on one endpoint, across 225+ networks, with history back to genesis, so the deployer scan above did not need its own infrastructure.
Where the data stops: SQD serves the record, not the verdict. Deployments, LP events, transfers, and launchpad instructions arrive with block and transaction evidence; rug and scam scoring, wallet attribution, and market-cap or price data are built downstream on those rows. There is no reconstructed state: holder balances are a fold over transfer history, metadata lives at the URI the contract points to, and the only prices are the amounts swap events themselves carry.
Try the Portal API
Live queries against real blockchain data. Pick a network, choose a query, hit run.
The public endpoint is free for development. See plans for dedicated portals and higher limits.
Solanasolana-mainnet/streamBuilt for Memecoins & Token Launches at scale
Launchpad instruction streams
Filter Solana instructions by the launchpad's program ID and an 8-byte discriminator and every launch streams back: name, symbol, metadata URI, and creator wallet are borsh fields in each create instruction's data. The same filter with the buy and sell discriminators, pinned to a mint by account position, is that token's trade stream.
Deployments from CREATE traces
On EVM chains every deployment is a create trace carrying the deployer and the new contract address, including factory and CREATE2 deployments a transaction list never surfaces. Filter by createResultAddress to find the trace that deployed a given token, or by createFrom to list everything an address ever deployed.
LP creation and first-trade flow
A PairCreated or PoolCreated log on the DEX factory marks the liquidity moment, and the new pool's Swap events are queryable from the block it appeared. Both are ordinary log filters, factory address plus topic0, so a launch monitor is two filters on one stream rather than a per-venue integration.
The raw record for screening
Deployments, LP events, first transfers, and launchpad instructions arrive as decoded rows with block and transaction evidence, the inputs a screening model runs on. SQD serves that record; rug and scam scoring, wallet attribution, and price data are built downstream in your stack.
What you would build yourself
The deployment, the pool, and the first trades are all public onchain; the work a provider saves is in reading records that live in different places the same way.
- Launchpad feed Yourself Register the program's IDL and run an Anchor-aware indexer, then rebuild it when launches move to create_v2 and the old create discriminator matches nothing.With SQD The feed is a program ID, an 8-byte discriminator, and a slot window on the instruction stream; the buy and sell discriminators on the same filter are that token's trades.
- New deployments Yourself eth_getLogs cannot see a CREATE, so deployments come from trace_block or debug_traceBlock on an archive node, and factory or CREATE2 deploys never show up in a transaction list.With SQD Filter the trace stream by type create and each match carries the deployer and the new contract address; the deployment record of any token is one trace filter.
- Deployer history Yourself A transaction list does not reveal which contracts an address deployed, so a wallet's launch history is not readable from transactions alone.With SQD createFrom lists every contract a wallet deployed, so the deployer scan is one more filter on the same trace stream, with history back to genesis.
- Early holders Yourself Page through the token's first Transfer logs and repeat the loop for every launch, on a separate call path from the deployment trace.With SQD Early-holder concentration folds over the token's first Transfer logs in the same query shape as the trace and the LP event, on one endpoint.
See this on your own contracts
Tell us the chains and contracts you care about, and we will show you the query that returns them.
What teams build with SQD
- New-token deployment feeds from CREATE traces
- Launchpad launch and trade streams by discriminator
- LP creation alerts from factory events
- First-blocks trade flow and early-buyer analysis
- Deployer history screening from trace queries
- Early-holder concentration from first transfers
Frequently asked questions
How do I get pump.fun data from an API?
How do I track new token deployments on EVM chains?
Does SQD score tokens for rugs or scams?
Other ways teams use SQD
See all solutionsTransfers, mint and burn, and peg signals read from DEX trades.
Issuance, transfers, and the issuer control events a token API omits.
Pool discovery from factory events, and every trade the pools emit.
Item ownership, game currencies, and marketplace settlement onchain.
Registrations, delegation, and the social graph that stays onchain.
Your blockchain data infrastructure, handled.
Private Portal. Dedicated. Validated. Managed. Tell us what you're building, we'll show you what it looks like on SQD.
validated data
for Enterprise
serving data