Project Overview

My Real Story, Step by Step (No Magic, Just a Lot of Work!)

Introduction: From Falcon to the Real Thing

After building Falcon, a fully automated trading bot that interacted with Pump.fun through a third-party API, I learned a lot about token sniping, automation, and trading logic. But that experience also showed me the limitations of relying on someone else’s infrastructure.

Falcon worked but i was still at the mercy of whatever the third-party API allowed. I didn’t control the transaction generation, the speed, or the internal logic. And that got me thinking…

What if I stopped using someone else’s API, and started talking to the real thing. The Pump.fun website itself?

That’s when I decided to go deeper.
This time, no abstractions.
No wrappers.
No shortcuts.

I wanted to reverse engineer Pump.fun directly from the frontend, through the network layer, all the way down to the raw transaction structures.
I wanted to understand how it really works when you click “Buy”.

And so this post documents exactly that: my full step-by-step journey to uncover how Pump.fun creates, signs, and sends transactions and what the fastest bots out there are really doing to skip all the noise.

Let’s get started.

Chapter 1: The Idea

It all started when I noticed a bunch of websites and bots trading new tokens on Pump.fun at lightning speed.
They were buying faster than any normal user could, sometimes even before the token had a price on the site.
I was curious. I wanted to know how it worked. Was there some secret API? Did they have special access?
I decided to figure it out myself.

Chapter 2: Watching the Network

The first thing I did was simple:
I opened my browser’s developer tools and started watching the Network tab while I tried to buy a token on Pump.fun.

But honestly, just looking at the browser wasn’t enough for me.
So I decided to take things further.
I fired up Fiddler, which is a tool made for analyzing and editing web traffic.
Fiddler lets you see every single request and response between your computer and the internet.
You can capture, replay, and even modify requests on the fly.
It’s perfect for reverse engineering how web apps talk to their backend.

I set Fiddler to capture all the packets while I used Pump.fun, paying close attention to anything that happened when I clicked “Buy”.

Chapter 3: The First Discovery

Because I was using Fiddler, I could see exactly which requests were being sent and what data was inside.
I watched the stream of network packets, and I saw a bunch of noise but then I spotted something interesting:
A POST request to https://frontend-api-v3.pump.fun/send-transaction.

Thanks to Fiddler, I could see every field in the request, the full body, and even replay or edit it if I wanted.
This is the power of packet analysis it’s like looking under the hood while the app is running.

Chapter 4: What Does the Website Actually Do?

Here’s what I figured out:

1. When you click “Buy”, Pump.fun creates a transaction in the backend.
2. It sends back a base64-encoded Solana transaction to your browser.
3. Your wallet (like Phantom) pops up and asks you to sign it.
4. After signing, your wallet sends the transaction to the Solana blockchain.
5. The website waits until the transaction is confirmed.

So, the website is really just an interface

it does the setup, but you still sign the transaction yourself.

Chapter 5: What’s Inside the Buy API Call?

After capturing the network request, I took a closer look at the actual data sent to /send-transaction.

Here’s what I found inside the request body:

{
  "serializedTransaction": "<a really long string, base64 encoded>",
  "retries": 5,
  "frontRunningProtection": false,
  "captchaToken": "<a captcha token from Google reCAPTCHA>",
  "batchId": "<a random-looking ID>",
  "lastValidBlockHeight": 235588920,
  "encoding": "base64"
}

It was clear now:

• The backend makes the transaction, sends it to the frontend, and expects the user to sign it.
• You need a valid captchaToken.
• There are some cookies, and a thing called auth_token in the headers.
• Some of the cookies come from Cloudflare, for anti-bot stuff.

 

Chapter 6: The Authentication Flow

But how does the website know who you are?
I noticed before you can buy, you have to “connect your wallet” and sign a message.

When I connected my wallet, the site sent a request to /auth/login.
Here’s what was in the body:

{
  "address": "<my wallet address>",
  "signature": "<a signature created by my wallet>",
  "timestamp": <current unix timestamp>
}

So basically, the site asks you to sign a timestamp with your wallet.
That proves you own the wallet, and then it gives you an auth_token cookie.
You need this for all buy/sell requests.

Chapter 7: Figuring Out All the Pieces

At this point, I had a good idea of the main steps:

1. Connect wallet, sign a timestamp, and get the auth_token (via /auth/login).
2. When you want to buy, the site sends a POST to /send-transaction with your auth_token and a valid captchaToken.
3. The backend responds with a serializedTransaction.
4. The frontend asks your wallet to sign and send that transaction.
5. The site then waits and checks if it was confirmed.

But I still had questions.
Like: how does the site know which token you want to buy, or how much?
Are those details hidden in the serializedTransaction?

Chapter 8: Diving Deeper

To answer that, I captured several buy requests for different tokens and amounts.
I noticed that the only thing that changed in the request body was the serializedTransaction itself.
That meant all the important details (mint, amount, slippage, etc.) were already inside that transaction, encoded by the backend.

The frontend just passes it along, and your wallet signs it.

Chapter 9: What About Captcha?

This part was annoying!
Every buy request needed a valid Google reCAPTCHA token (captchaToken).
Without it, the backend would reject the request.

Solving captchas manually was a pain, and it stopped me from fully automating the process.
I looked into using captcha-solving services, but that’s a whole topic on its own.

For now, I realized:

• You MUST have a valid captchaToken to buy.
• Skipping captcha will get your request blocked.
• Cloudflare cookies (cf_clearance, __cf_bm) are also checked to stop bots.

 

Chapter 10: Putting It All Together

Here’s a step-by-step summary of what I learned and how the process works:

1. Login:
   Sign a timestamp with your wallet and POST it to /auth/login.
   Get the auth_token from the response cookies.
2. Get Ready to Buy:
   Get or solve a captcha to get a captchaToken.
3. Send Buy Request:
   POST to /send-transaction with:
   • Your serializedTransaction (from the backend)
   • captchaToken
   • auth_token and other session cookies
4. Sign and Submit:
   Decode the serializedTransaction, sign it with your wallet, and send it to the Solana blockchain.
5. Check Confirmation:
   Poll the Solana network to see if your transaction was confirmed.

Chapter 11: All the Code I Used

To automate this, I started writing code in Node.js.

Here’s a very basic example of how to POST to /auth/login:

const axios = require('axios');
const nacl = require('tweetnacl');
const bs58 = require('bs58');

const wallet = ...; // Your wallet object

const timestamp = Date.now();
const message = Buffer.from(timestamp.toString());
const signature = bs58.encode(wallet.sign(message));

const loginBody = {
  address: wallet.publicKey.toBase58(),
  signature: signature,
  timestamp: timestamp
};

axios.post('https://frontend-api-v3.pump.fun/auth/login', loginBody)
  .then(res => {
    // Save cookies from res.headers['set-cookie']
    // Use them for next requests
  });

And here’s a snippet to send the buy request:

const buyBody = {
  serializedTransaction: "<the string you got from the backend>",
  captchaToken: "<your captcha token>",
  batchId: "<some uuid>",
  lastValidBlockHeight: 235588920,
  retries: 5,
  frontRunningProtection: false,
  encoding: "base64"
};

axios.post('https://frontend-api-v3.pump.fun/send-transaction', buyBody, {
  headers: {
    'Cookie': 'auth_token=...; cf_clearance=...; __cf_bm=...;',
    // Other headers to mimic browser
  }
}).then(res => {
  // You get a transaction signature back!
});

Note:
You have to use the right cookies, and get a valid captchaToken, or this will fail.

Chapter 12: What I Still Didn’t Know

Even after all this, a few things bugged me:

• How do I create my own serializedTransaction for custom amounts, or different tokens?
• Is there a way to skip the website and interact directly with the smart contract?
• Why do some third-party bots seem even faster?

 

Chapter 13: The Final Missing Piece

That’s when I realized:
I was always working with what the website gave me.
I was stuck with their captchas, their cookies, and their rate limits.

But all these super-fast bots and services weren’t just copying network requests they were going deeper.
They figured out how Pump.fun actually talks to the Solana blockchain at the program level.

They weren’t reverse engineering the network anymore.
They were reverse engineering the code itself.

Chapter 14: How the Best Pump.fun Bots Actually Work

So here’s the big reveal:
The fastest bots and APIs aren’t using /send-transaction at all!

They reverse engineered how the Pump.fun smart contract works on Solana.
They looked at the instructions, the accounts, the data structure, and everything else.
They figured out how to create transactions that look exactly like what the website sends but they do it all by themselves.

No captcha, no waiting for the backend, no rate limits.
They talk to the blockchain directly.

It took me hours of digging, but I finally found the secret:
The IDL (Interface Description Language) for the Pump.fun smart contract.
This is basically a blueprint that tells you exactly how to interact with the program, what parameters to send, and what happens on-chain.

Chapter 15: My Next Step

So, if they can do it, so can I.

That’s what I’m working on next.
Instead of talking to the website and fighting with anti-bot protections, I’m going straight to the source.
I’ll be building and signing my own transactions, and sending them right to Solana.

It took a lot of time, a lot of network captures, and a lot of code, but now I know the real path:
Reverse engineering the on-chain program itself.

If you’re curious about how to do that how to use the IDL, how to create real buy/sell transactions from scratch, and how to become truly independent from the frontend stay tuned for my next post.

That’s where the magic really happens.

 

 

Thanks for reading! If you want to know more, check out Part 2 soon where I’ll show you exactly how I use the Pump.fun IDL to build bots and interact directly with the Solana blockchain, with zero middlemen and no more waiting.