The fix is not a smarter AI. It is giving it the right data and asking the right questions. Here is how we do it.

Start with real files, not descriptions

If you describe your data in words ("I have trades with prices and times"), the AI fills the gaps with guesses about column names, units and time zones. Sometimes the guesses are right. Often they are quietly wrong, and the backtest still runs.

Give it the actual file, or at least the first few rows plus the schema. Real rows answer questions you did not think to ask: is the price in SOL or USD, is time in seconds or milliseconds, is there one row per trade or one per block.

Takeaway: paste a sample of the data, not a summary of it.

Here are the first 5 rows of trades.jsonl and the schema.
Before writing any code, tell me in one line each:
what one row means, the unit of every price, and the unit of time.

Small files first

Chat tools have upload size limits, and long files also eat the AI's working memory. Trade data gets big fast: a single full day of our graduation trades (October 12, 2026) is about 800 MB compressed. No chat window is going to read that.

So work in two steps. First, a small slice (a couple of hours, or one coin) that fits in the chat. Use it to get the code right and check a few trades by hand. Then run the same script on your own machine over the big files.

Takeaway: use the chat to build and check the script; use your computer to run it at full size.

Make it state its assumptions

The single most useful line you can add to any prompt is: "Before you run anything, list every assumption you are making." Typical answers: fills at the last seen price, no fees, coins with missing data skipped.

Each of those is a choice. Some are fine. Some make the result useless. You cannot judge them if you never see them.

Takeaway: an assumption you can see is one you can fix.

Ask for honest fills, by name

AI-written backtests nearly always fill at the signal's price, because that is the simplest code. Tell it not to, in plain words:

• every buy and sell fills at the end of the first block after the signal
• fees and slippage on both sides
• your trade size moves the pool's price
• coins that never reached your entry are counted, not dropped

Then ask it to run the same rules both ways, naive and honest, and print the two results side by side. If they are far apart, the naive one was flattering you. Our post on backtests that lie goes through each of these.

Takeaway: if you do not ask for honest fills, you will not get them.

A prompt skeleton

Here is a short version you can adapt. Fill in the brackets.

I'm testing a Solana memecoin bot's rules on real trade data.
Files: [file names], schema: [paste or attach].

RULES
- Entry: [e.g. buy 15 s after graduation]
- Exit: [e.g. sell at 3 min, or -20% from my entry]
- Size: [e.g. 0.1 SOL a trade]

HOW TO TEST
- Fill every signal at the end of the next block, never at its own price.
- Charge [my real costs] on the buy and on the sell.
- My size moves the pool price (use the pool's reserves).
- Count coins that never reached my entry; don't drop them.

BEFORE CODING: list every assumption you're making.
AFTER: print win rate, median and mean return a trade, total,
the 3 worst trades, and the same rules at signal price with no
costs, for comparison. Then a plain verdict, including how small
the sample is.

Our Test your bot page has a longer, complete version that already knows our file formats.

Takeaway: a good prompt reads like a spec. If a stranger could not run your test from it, neither can the AI.

Check one trade by hand

When the results come back, pick one trade, open the raw rows for that coin, and follow it yourself: when the signal fired, which block the buy filled in, what it cost, when it sold. If you cannot match what the script says, something is off.

Takeaway: one trade checked by hand is worth more than a hundred trusted blindly.

The hopeful part

An AI is a fast, tireless helper for this kind of work, as long as you hold it to the same standard you would hold a person. Better rules might exist for your bot. Give the AI real data and honest instructions, and it can help you find out.

If you want real files to start with, the free sample is two hours of pump.fun graduations, small enough to try today.

Originally published at launchtape.io/blog. We run Launch Tape: every pump.fun graduation on Solana, recorded trade by trade from the chain, as daily files. There is a free sample at launchtape.io.

This post is about what happens in those first couple of minutes, and the practical things that decide whether your bot is early, on time, or the exit liquidity for someone else.

What graduation actually is

On pump.fun, a new coin trades on a bonding curve: a price formula, not a pool. When enough SOL has gone in, the curve completes, and the coin "graduates" to a PumpSwap pool where it trades like any other token.

From a bot's point of view, three things change at once. There is now a pool with real reserves. Lots of people are watching the same event, because graduation is easy to detect. And everyone who bought on the curve now has a clear chance to sell into the new buyers.

Takeaway: graduation is not a calm starting line. It is a crowded doorway.

Big holders do not wait long

Some of the wallets that bought on the curve hold a big share of the supply. When one of them sells hard, the price can fall a long way in one block.

We looked at this on our own recordings. Of the pump.fun graduates from October 10 to 12, 2026, 894 had a big-holder dump by our recorder's size rule in the first 10 minutes. The median time of that dump was 2.2 minutes after graduation.

That is the median, so half came even sooner. If your bot needs a minute to notice the graduation, another minute to decide, and some seconds to land a transaction, it can arrive right as the selling starts.

Takeaway: your whole plan, entry and exit, may have to fit inside a couple of minutes. Design for that from the start, not as a tweak later.

Why reaction time matters more here than anywhere

On a slow chart, a few seconds of delay costs you a little. Right after graduation, a few seconds can be the difference between buying before a dump and buying into one, or between selling at a stop and selling after the pool has been drained.

There are two separate delays, and it helps to measure them separately:

1. Seeing: how long between the graduation landing on chain and your bot knowing about it.
2. Acting: how long between your bot deciding and its transaction landing in a block.

Takeaway: "my bot is fast" is not a measurement. Two numbers are.

Websocket vs polling

Many first bots poll: every few seconds, ask an API "anything new?". It is easy to write, and AI tools often suggest it. The cost is that, on average, you see every event half a polling interval late, plus the request time.

A websocket (or another streaming subscription) pushes events to you as they happen. It is a bit more work: you need to handle disconnects, reconnect, and notice gaps. But for anything that happens in the first two minutes, polling every few seconds throws away a real slice of the window.

# polling: you learn about an event up to POLL_SECONDS late
while True:
    for ev in api.get_new_graduations():
        handle(ev)
    time.sleep(POLL_SECONDS)

# streaming: events arrive when they happen
async for ev in ws.subscribe("graduations"):
    handle(ev)

Takeaway: if your strategy lives in the first minutes, stream. Then log every disconnect, because a silent gap looks exactly like a quiet market.

Measure your own latency

You do not have to guess how slow your bot is. Log three timestamps for every trade:

• the block time of the event you reacted to (from the chain)
• the time your bot received it (your clock)
• the block time your transaction landed in (from the chain)

seen_delay   = received_at - event_block_time
landed_delay = tx_block_time - received_at

Run it for a day, then look at the median and the slow tail, not the best case. Keep your server clock synced, or the numbers will lie to you.

Takeaway: once you know your real delays, put them into your backtest. If your bot really lands six seconds after the signal, test entries at six seconds, not at zero.

Then test the window honestly

Knowing the window is short is only useful if your tests respect it. A backtest that fills at the graduation price, or checks prices every 30 seconds, will miss most of what happens in the first two minutes. You need every trade, block by block, for each coin, including the ugly ones.

The hopeful part: short windows are exactly where careful, honest testing can find things that lazier bots miss. Better rules might exist here. The way to find out is to replay them on what actually happened, with your real delay built in.

If you want to look at those first minutes yourself, the free sample has two hours of graduations, trade by trade.

Originally published at launchtape.io/blog. We run Launch Tape: every pump.fun graduation on Solana, recorded trade by trade from the chain, as daily files. There is a free sample at launchtape.io.

A first backtest usually tests a bot that could never exist: one that buys at the exact price it saw, pays nothing to trade, and never moves the market. Real bots do none of that. Below are the five fixes we make before we believe any result, our own included.

1. Fill at the next block, not at the signal price

Your bot sees a price, decides to buy, signs a transaction, and that transaction lands in a later block. By then the price has moved. On fresh memecoins it usually moves against you, because other bots saw the same thing you did.

So the honest rule is simple: a signal at time T fills at the end of the first block after T. Never at the price that triggered it. The same goes for sells and stops: a stop that "triggers at -20%" fills wherever the price is one block later.

Takeaway: if your backtest uses the signal's own price as the fill, it is grading you on a trade you could not have made.

# wrong: fill = price_at(signal_time)
# right: fill at the first block after the signal
fill_slot = next(s for s in slots if s.time > signal_time)
fill_price = fill_slot.last_price

2. Charge fees on both sides

Every swap pays the pool's fee. On top of that you pay a priority fee to land quickly, and you lose a bit more to slippage. All of that happens on the way in and on the way out.

It sounds small per trade. But a strategy that aims for small, quick wins lives or dies on those few percent, because they come off every single round trip, win or lose.

Takeaway: put a cost on the buy and a cost on the sell, and use real numbers from your own transactions, not a guess.

3. Your size moves the pool

A new coin's pool is shallow. If you buy with a meaningful amount of SOL, you push the price up as you buy, so your average fill is worse than the price you saw. When you sell, you push it down.

Most backtests ignore this and assume you can buy any amount at the quoted price. Use the pool's own maths instead: for a constant-product pool, the tokens you get for x SOL depend on the pool's reserves at that moment.

Takeaway: test at the size you will actually trade. A rule that works at 0.01 SOL can fail at 1 SOL on the same coins.

4. Count the coins that never filled

This one is sneaky. If your entry is "buy 15 seconds after graduation", some coins will have no trades at all after 15 seconds, or the pool will be gone. If your code quietly skips those, fine. But if it skips coins because they went badly (no data after a crash, a missing price after a rug), your results only include the survivors.

The same thing happens when you test on a list of coins you picked later, like "coins that hit the trending page". Those coins already survived something.

Takeaway: decide the list of coins before you look at outcomes, and report how many never reached your entry, as a separate number.

5. Look at the gap, not just the result

Once you have fixed the four things above, run your rules twice: once the naive way (signal price, no fees, no size impact) and once the honest way. The difference between the two runs is the part of your "edge" that was never really there.

Here is what that looked like for us. We took one simple rule set (buy 15 seconds after a pump.fun graduation, sell at 3 minutes or at -20%, 0.1 SOL a trade) and ran it on 67 coins from October 10, 2026, 14:00 to 16:00 UTC. The naive backtest showed +2.3% a trade. The same rules, filled a block late, with fees on both sides and the size moving the pool: -0.9% a trade. Same coins, same rules, opposite answer. The full method is on our Test your bot page.

That is two hours of data, so it does not tell you the rule is bad forever. It tells you that the first number was not a measurement of the rule at all.

Takeaway: if your naive and honest runs are far apart, trust the honest one, and be suspicious of any idea that only works in the naive one.

Why bother

None of this is meant to talk you out of building. Better rules than ours might well exist. The point is to find out cheaply, on data, before the market finds out for you with real SOL.

A good habit: every time your AI writes or changes the backtest, ask it to list exactly how fills, fees, size and missing coins are handled. If it cannot tell you, the backtest is not done yet.

If you want to try this on real graduations, the free sample has two hours of every trade, and Test your bot has a prompt that runs the honest version for you.

Originally published at launchtape.io/blog. We run Launch Tape: every pump.fun graduation on Solana, recorded trade by trade from the chain, as daily files. There is a free sample at launchtape.io.