Skip to main content

Frequently Asked Questions

Is PumpPortal Fast?​

Of course. All types of trades on PumpPortal average under 1 second to execution. If milliseconds matter for your trading strategy, read on to the next question:

What is the fastest way to trade on Pump.fun and other DEXs?​

Memecoin sniping is extremely competitive: advanced bots in this space have millions of dollars of infrastructure (Solana nodes all around the world to receive and send data with the lowest possible latency). This being the case, PumpPortal can not guarantee the ability to snipe a coin first or trade before every other bot. If you need speed, you can still use PumpPortal to trade very efficiently by following a few simple recommendations. Following these guidelines the average latency from submitting a transaction to landing onchain can be as low as 1 block .

  • Use our Lightning Transaction API: The Lighting API achieves some of the fastest transactions on Solana by forwarding trades to the blockchain via many different upstreams at once (upstream SWQoS providers like Helius, and private and public Jito bundle relays, our dedicated Solana nodes, and more.)
  • Experiment with different priorityFee levels (higher priority fees are necessary under high network load).
  • Run your code on a server in New York or somewhere in the Eastern US for lowest latency.
  • Avoid using "pool": "auto" (This option occasionally requires our servers to pull additional pool data which could add up to 100 msec of delay.)

How fast is the PumpPortal realtime data websocket?​

Data from the PumpPortal websocket is at the "processed" commitment level, and will typically be less than 100 msec delayed behind gRPC data if you run a server in New York. If you need faster data you should look into Helius Laserstream or running your own gRPC node.

What are the rate limits for using PumpPortal API?​

Trading and other endpoints are limited at 25 requests per second. Our data websocket has its own limits:

Try to handle everything over one connection. You can have practically unlimited subscriptions on a single connection. You can just send new addresses to the connection and they will be added to your existing subscriptions, no need to send the whole list of addresses each time. Don't send over 200 subscription messages per second. Don't subscribe to over 5000 addresses in a single message. If you go over 15 connections they will start getting closed, and if you keep opening them you will get temporarily banned (don't worry, bans expire every hour, so if you make a mistake you can wait a bit and try again). For some reason AI coding agents love to make new connections for every token, so carefully review any AI code that might exceed our limits.

I sent a transaction that never showed up onchain. What happened?​

Transactions can fail for many reasons. Make sure you are using an adequately funded wallet, and make sure you follow the examples in our docs EXACTLY to send trade requests correctly. For Local Transactions using a paid RPC connection is recommended for reliability. For Lighting Transactions, setting "skipPreflight": "false" may be helpful for debugging failing transactions.

What does skipPreflight do?​

Preflight checks simulate the transaction before sending to the chain, so it's useful for debugging or preventing bad transactions from failing on chain and wasting fees. The biggest downside though, is that preflight checks can throw errors on transactions that are actually fine. This happens a lot when sniping new tokens, and the simulation doesn't have the new token mint yet, so the preflight checks fail even though the transaction would have succeeded on chain. Preflight checks can have between zero and mostly negligible (~50 msec) impact on trade latency depending on how the transaction is routed.

TLDR: set skipPreflight: "false" if you need to debug why txns are failing, or to prevent some bad transactions from being sent to the chain. Set skipPreflight: "true" (default) to send transactions straight to the chain with no simulation.

My transaction failed with the error "Custom Program Error"​

Top level Solana errors are often vague like this and tell you nothing. Look at the program logs for the transaction (on Solscan scroll all the way to the bottom and click "Show Details"). Often you will find something like "not enough Sol" or "insufficient funds".

What is Jito? What are bundles? Should I be using them?​

You only need to use Jito if you need to bundle multiple transactions together, where each transaction executes in sequence on the blockchain. Our Lighting API is faster and more reliable than public Jito endpoints for single transactions. The most common use case for Jito on Pump.fun is to bundle a token creation with multiple buys of that token. This ensures that the bundled buys execute immediately after creation so they are always the first buys of the token.

I'm getting these errors from Jito: 429 "Endpoint is globally rate limited"​

You are being rate limited by Jito, not us. Jito public endpoints are often congested and unstable. If you have confirmed that you really do need to use Jito (most traders do not), there are a few ways to resolve this:

  1. You can directly contact Jito in their Discord, or they have a form in their docs you can use to request a increased limit: https://docs.jito.wtf/lowlatencytxnsend/#rate-limits-form
  2. You can try multiple times or send requests to multiple Jito regional endpoints to increase the chance of landing a bundle.
  3. You can use private Jito bundle endpoint from a provider like Quicknode.

Is PumpPortal safe? How do PumpPortal Lighting wallets work?​

PumpPortal Local Transactions are signed by your code on your device, PumpPortal never has access to your wallet. PumpPortal Lighting wallets are standard Solana keypairs with a public key and a private key. Lightning wallets also provide an API key that is linked to that keypair. The API key contains the wallet private key encrypted with AES-256. When you send a Lighting Transaction it is signed by that encrypted private key in your API key. This way Lighting private keys are never stored on our servers and are safe even if PumpPortal was compromised. It is still YOUR RESPONSIBILITY to take proper precautions with funded wallets. You should always treat any trading wallets as "hot wallets" and never store large amounts of funds there that are not being used for active trading. Be very careful with your code, wallets frequently get drained because someone commits code containing a private key to public Github repo.

I lost my private key, can you help me?​

Nope, it's gone.

Does PumpPortal have a token?​

No.

Is there a Pumpfun devnet API?​

We currently don't provide APIs for devnet or testnet. You can experiment with very small amounts of SOL on Mainnet.

Do you provide historical Pump.fun token data?​

We only provide live trading data at this time, you would need to pull historical data from an RPC or other source.

Do you provide Pump.fun livestream data / chat / comments?​

No, this data is not onchain, so it is only accessible from the Pump.fun site directly.

I deployed a token through PumpPortal, but the token address doesn't end in 'pump'.​

Our token creation examples show how to generate a random address and use that to create a token. For an address ending in 'pump' you would have to grind for the vanity address ending in 'pump'. Then you would set the 'mint_keypair' in the token creation examples to that vanity keypair. Here's an example of how to grind vanity keypairs with the Solana CLI: https://www.quicknode.com/guides/solana-development/getting-started/how-to-create-a-custom-vanity-wallet-address-using-solana-cli

I got disconnected from the realtime data websocket, what happened?​

Websockets can just disconnect with network instability or when our servers rebalance load, so it's a good idea to have some reconnection logic in place, especially if you need to maintain a connection over a long period of time.