Detecting a new Pump.fun mint from raw transactions requires identifying a create instruction and resolving its mint account. A program subscription alone also delivers buys, sells, and other interactions. Treat the subscription as a candidate feed, then decode with the current program IDL.
Use raw decoding when instruction detail matters
Choose Datastream launch events for indexed token objects. Choose gRPC when you need instruction-level timing, custom fields, or independent decoding. Raw streaming adds parser maintenance and recovery work; it does not guarantee that every observation becomes finalized chain history.
Configure the Pump.fun subscription
Start with the Yellowstone setup. Read the Pump program address and IDL from the official Pump public documentation. Keep the IDL revision with your deployed parser so changes are reviewable.
Use failed: false and vote: false for successful non-vote candidates. Keep processed observations provisional and preserve slot plus signature for later reconciliation.
Decode both create variants
The parser needs to recognize the create variants present in its pinned IDL, including create and create_v2. Read each discriminator from the IDL rather than defining one constant and referencing an undefined second discriminator.
For each transaction:
- Build the effective key list from static keys, loaded writable keys, then loaded readonly keys.
- Visit top-level and inner instructions while preserving their positions.
- Resolve
programIdIndex; skip instructions from another program. - Match the discriminator against supported create instructions.
- Decode using that instruction's IDL and resolve its named mint account from its account layout.
- Emit every supported create, including mint, signature, slot, and instruction path.
This is a parser algorithm, not a claim that all instruction variants have identical account positions. The linked companion contains the broader project structure; compare its bundled IDL with upstream before use.
Treat metadata as untrusted input
A token name, symbol, and URI can be empty, duplicated, long, or maliciously formatted. Use the mint as identity. Escape text in the UI and limit length. Fetch metadata URIs through a controlled service with timeouts, response-size limits, and protections against private-network URLs.
Do not block the transaction callback while fetching images or metadata. Emit the mint immediately and enrich it asynchronously. Unknown metadata should not cause the create event to disappear.
Test the cases that lose mints
Keep fixtures for each supported create variant, an unrelated instruction with similar bytes, a CPI create, a versioned transaction using loaded addresses, a malformed body, and multiple creates in one transaction. Replaying the same fixture twice should not create two durable records.
The September changelog notes Pump.fun Transaction V1 and holder-reward support. Those platform updates are a reason to review assumptions in a custom parser; they do not automatically update a locally bundled IDL.
Follow the mint through its lifecycle
Creation, curve completion, migration, and destination-pool availability are separate observations. Use the graduation guide to model those states. Do not label every curve account update as a graduation or assume a Raydium destination.
FAQ
Can a single transaction create more than one token?
Design the parser to retain every matching instruction instead of returning after the first.
Does accountInclude validate the instruction program?
No. Resolve and check programIdIndex for each candidate instruction.
What happens during a disconnect?
Record the gap, reconnect once, restore filters, and recover missed state through an appropriate historical source.
References
Companion project
The companion example contains a fuller project layout. Check the companion dependencies and bundled program layouts against the versions described here before use. Keep credentials in a local environment file, never in a shared browser workspace.