Pump.fun Create Instruction Discriminator & IDL Analysis

In the competitive landscape of Solana DeFi, being first is not just an advantage—it is the entire game. For developers building sniper bots, arbitrage systems, or monitoring tools for the Pump.fun ecosystem, the ability to detect a new token launch the instant it hits the mempool is the difference between a 100x return and being exit liquidity.

This guide provides a rigorous technical analysis of the Pump.fun smart contract, specifically focusing on the create instruction. We will dissect the Anchor discriminator, the account structure, and how to implement a detection engine that operates at the speed of the network.

Understanding Anchor Discriminators

Solana programs built with the Anchor framework use a unique 8-byte identifier called a "discriminator" to route instructions to the correct handler. This discriminator is calculated as the first 8 bytes of the SHA-256 hash of the string global:<instruction_name>.

For the Pump.fun program, identifying this sequence of bytes within the input data of a transaction is the most reliable way to filter for specific actions, such as a new token creation.

The Create Instruction Discriminator

Based on the official Pump.fun IDL (Interface Description Language), the discriminator for the create instruction is:

"discriminator": [24, 30, 200, 40, 5, 28, 7, 119]

In hexadecimal representation, this byte array corresponds to:

0x18 0x1E 0xC8 0x28 0x05 0x1C 0x07 0x77

Why This Matters for Snipers

When you are streaming transactions via a high-performance gRPC connection (like those provided by AllenHark Infrastructure), you receive a flood of data. You cannot afford to fully parse every transaction to see what it does.

Instead, you apply a byte-level filter. If the first 8 bytes of the instruction data match the sequence above, you know with 100% certainty that this is a Pump.fun create call. This allows you to trigger your buy logic immediately, often before the transaction has even been fully processed by the rest of the network.

Deep Dive: The Instruction Structure

Detecting the instruction is step one. To execute a buy, you need to know what is being created. This requires parsing the accounts passed to the instruction.

The create instruction expects the following accounts in this specific order:

1. mint (Signer, Writable): The public key of the new token being created. This is the most critical piece of information.
2. bonding_curve (Writable): The PDA (Program Derived Address) that manages the token's price curve.
3. associated_bonding_curve (Writable): The associated token account that holds the bonding curve's reserve of the new token.
4. global: The global state PDA of the Pump.fun program.
5. mpl_token_metadata: The Metaplex Token Metadata program ID.
6. metadata: The PDA for the token's metadata (name, symbol, image).
7. user (Signer, Writable): The wallet address of the creator.

Rust Implementation Strategy

Here is a robust implementation pattern for a detection engine written in Rust. This snippet demonstrates how to efficiently check for the discriminator and extract the mint address.

use solana_sdk::pubkey::Pubkey;

// The 8-byte discriminator for the 'create' instruction
const PUMP_FUN_CREATE_DISCRIMINATOR: [u8; 8] = [24, 30, 200, 40, 5, 28, 7, 119];

pub struct TokenLaunch {
    pub mint: Pubkey,
    pub creator: Pubkey,
    pub bonding_curve: Pubkey,
}

pub fn parse_transaction_instruction(
    program_id: &Pubkey,
    accounts: &[Pubkey],
    data: &[u8]
) -> Option<TokenLaunch> {
    // 1. Verify this is the Pump.fun program
    if program_id.to_string() != "6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P" {
        return None;
    }

    // 2. Check the discriminator (first 8 bytes)
    if data.len() < 8 || data[0..8] != PUMP_FUN_CREATE_DISCRIMINATOR {
        return None;
    }

    // 3. Extract accounts based on the IDL schema
    // Account index 0 is the Mint
    // Account index 6 is the User (Creator)
    // Account index 1 is the Bonding Curve
    
    if accounts.len() < 7 {
        return None; // Malformed instruction
    }

    Some(TokenLaunch {
        mint: accounts[0],
        bonding_curve: accounts[1],
        creator: accounts[6],
    })
}

Optimizing for Zero-Latency Execution

Knowing the discriminator is only half the battle. To actually win the block, your infrastructure needs to be as fast as your code.

1. The Need for Speed (0-Slot)

In the current Solana meta, "0-Slot" execution is the standard. This means you are identifying the launch transaction while it is still in the TPU (Transaction Processing Unit) stage of the leader, or immediately upon propagation. Standard RPCs introduce 200ms+ of latency. You need a direct feed.

2. Co-Location is Mandatory

Light takes time to travel. If the current leader is in Frankfurt and your bot is in New York, you are adding ~80ms of latency purely due to physics. Hosting your bot in TeraSwitch Frankfurt (where a significant portion of Solana stake resides) eliminates this variable.

AllenHark Co-Location puts your bare metal server in the same rack as the validators.

• Network Latency: Under 1ms (internal datacenter cross-connects).
• Jitter: Virtually zero.

3. Private Network Interconnect (PNI)

Public internet routing is unpredictable. BGP updates can reroute your packets through slower paths without warning. Using a PNI ensures your transaction packets travel over a dedicated fiber line directly to the validator's ingress, bypassing the public internet entirely.

Conclusion

Building a successful sniper bot on Pump.fun requires a mastery of both software and hardware.

• Software: Use the [24, 30, 200, 40, 5, 28, 7, 119] discriminator to filter streams efficiently.
• Hardware: Deploy on AllenHark Co-Location to ensure your buy transaction arrives before the competition.

Ready to deploy? Check out our Infrastructure Documentation for connection details.