Building a memecoin trading bot: what the data said, and what real money said

This autumn I built a bot to trade memecoins: brand-new tokens that launch by the thousand every day, mostly on hype, and mostly die within hours. The original idea was the one everyone has. Find new tokens that look safe, buy, sell at 2x.

That idea failed in the first simulation. What came after is the interesting part: a month of recording every new token forward, pre-registering every rule before testing it, killing candidates that looked brilliant, and a week of real-money trading that lost 92% per trade while the same strategy made money on paper, on the same tokens, at the same moments.

This is a private project and a strategy is still running, so I won’t say what the surviving rule does. Everything else is here: the method, the dead ends, and the post-mortem.

Why I didn’t backtest on history

The obvious move is to download price histories and backtest. For memecoins, that gives you a lie. Free data sources quietly drop tokens that rugged or were delisted, so every rule you test only ever meets the survivors. Any “buy new tokens” strategy looks great on data where the dead ones have been removed.

So the first thing I built was a recorder that runs forward:

• It logs every new trading pool on two chains as it appears, then the token’s price every minute for its first two hours, every five minutes to six hours, and every 15 minutes to 24 hours.
• It checks each token’s security flags once, at discovery, and stores when it checked, so a later simulation can only use flags that were actually known at entry time.
• Dead tokens stay in. A token with no trades for 20 minutes is marked dead and any open position in it counts as a total loss.
• Launchpad tokens, about 65,000 a day on one chain alone, are far too many to track, so it keeps a fixed 5% random sample with a weight to scale back up.

The aggregator feed I started with missed about half of all new pools at busy times: it ran around six minutes late, out of order, and rate-limited. I added an on-chain listener that watches pool-creation transactions directly, tested against real saved transactions. The recorder has since run for weeks finding well over a thousand new pools an hour.

The kill rule, before any results

Before the first simulation I wrote down when to stop: if, after filters, fewer than about 35% of entries reach 2x, or the average trade loses money after realistic slippage, fees, token taxes and failed sales, the project ends.

The simulator charged for all of that: a 0.5% fee and 1% slippage per side, the price impact of the trade on the pool’s actual reserves, and each token’s own taxes. Data was split by time, first 60% to choose settings and last 40% to test them, never randomly.

The 2x idea died on day one

With about a day of recorded data and 1,728 rule settings per market segment:

• Sell at 2x lost money everywhere. On one chain, 32% to 35% of entries hit 2x, but the rest lost almost everything: stops gapped straight through between snapshots. That came to −26% to −35% per trade. On the other chain, −72% to −78%.
• Selling half at 2x and riding the rest was worse, not better.
• In two of the three segments with enough data, zero settings made money on the test half. Not few. Zero.

A small cluster of settings in one segment did make money on both halves. They were best-of-1,728, every confidence interval included zero, and I said so in the log: leads, not edges. I locked two of them as candidates C1 and C2, with a pass mark for data recorded after the lock: at least 100 trades, a positive mean, and a 95% confidence interval whose lower bound is above −5%. No retuning. A changed rule is a new candidate with its own clock.

A second batch of ideas produced a third candidate, C3. By then the simulator also assumed every fill happened one snapshot after the signal, because these tokens swing 30% to 50% in a minute. Several close neighbours of C3 died under that assumption; only the exact rule survived, so only that rule was locked. It was best-of-224 and the batch had been designed after seeing the first one, so it got the same treatment.

The candidate that passed and was fake

A day later, C1 passed its test mechanically: 107 post-lock trades, +47% per trade, a confidence interval comfortably above zero.

It was fake. All of its profit came from 27 trades on one small exchange, and those pools’ reported liquidity was invented. One pool shown at $1.46 million held 98.7 SOL, about $12,000. The memecoin side of the pool was being valued at a manipulated price, so the “liquidity” was mostly the token pricing itself. Without that exchange, C1 was 80 trades at −58% per trade, median −99%.

Checking further, about 10% of new pools on that chain reported at least five times their real liquidity in their first ten minutes, on major exchanges too. The fix was in the data, not the rule: from then on the recorder stored the real reserve on the money side of each pool, and the simulator priced fills and liquidity filters off that.

C2 failed its pass mark honestly. C3 passed, having shrunk by more than half from its pre-lock number, which is what best-of-many picks do.

Paper trading, and teaching paper about honeypots

C3 moved to paper trading: real signals, quotes from the exchange’s live reserves, re-quoted three seconds later to model block inclusion, minus taxes, an extra margin for slippage and front-running, and real gas. Exits were managed on live sell quotes.

The gap between simulator and paper started at 9 points per trade at about 100 trades. At about 1,900 trades it was down to 2 points, with the same outcome on 85% of tokens. That was the first time I trusted the simulator.

Paper trading has one blind spot that matters a lot in this market: a paper sale can’t fail. Honeypots are tokens you can buy but not sell. Paper books them as wins. When the live bot later hit two of them, paper had booked both as take-profit wins.

So before every entry, both paper and live now simulate the full buy, approve and sell against the chain. If the simulated sale reverts, the bot doesn’t buy, and paper doesn’t record a trade either. A paper loss the bot could never have taken would distort the results in the opposite direction.

The veto model

Of the simulated C3 trades, about a quarter were rugs. So instead of a new signal I built a veto: a model that scores a trade C3 already wants, using only data from the first minutes of the token’s life, and skips the riskiest ones.

The spec went into the log before any model was fitted:

• Data: 2,190 simulated trades, 569 rugs, split 60/20/20 by time.
• Models: exactly two, a logistic regression and a gradient-boosted tree.
• Veto rule: one fixed cutoff, set on the validation block.
• To pass: remove at least 30% of rugs, keep at least 85% of winners, and improve the average trade with a confidence interval above zero.

Both passed on the simulation. Then both models were frozen and scored every live paper signal in record-only mode, without changing a single trade, for a paired comparison on the same trades:

The logistic regression improved the average trade and was still killed, for missing the 30% bar by 1.1 points. That’s what pre-registration is for. If I’d been allowed to argue with my own criteria, I would have.

Real money: −92% per trade

From 6 to 12 October the bot traded real money on a tiny wallet. It closed 24 trades and lost 92.3% per trade on average, with one winner. Two more positions could never be sold. The wallet went from $52.62 to $10.16. Over the same days, paper trading the same rule made money.

The tempting conclusion is “paper is fiction”. I took the post-mortem slowly, trade by trade, against the paper account and the recorder’s snapshots.

Execution was fine. Tokens received were within −3.8% to +1.4% of the quote taken just before the buy. Signal to buy took 7 to 23 seconds.

Our buys didn’t cause the rugs. On 21 of the 23 rugged tokens, paper had bought the same token within 12 seconds of the live buy, sent no transaction at all, and still booked the same −100%, 6 to 21 seconds after entry. Liquidity was there 10 to 20 seconds before entry and zero at the next snapshot. The creators drained those pools at the moment the signal fired.

The safety stops picked the worst possible moments. Scam creators rug in bursts, and rugs from the same burst are correlated, not independent. On a $10 to $50 wallet, the $2.50 minimum trade was 5% to 25% of equity, so two to four rugs in a row tripped the daily loss limit. The bot was then locked out for the rest of the day, which was exactly when the strategy earned its money. Over that week, paper took 412 trades the live bot was blocked from by the daily limit or my own manual pause. Those trades were comfortably profitable. Between my pauses and redeploys, the bot was started 55 times.

A replay of the stop rules on paper trades confirmed it. Run continuously at 5% sizing, none of the daily stops ever fired. The rug-burst cooldown skipped trades that earned the same as every other trade, so it reduced growth without reducing risk. The stops didn’t protect the wallet. They confined it to the bursts.

The truly live-specific loss was honeypots: 2 of 26 trades. That rate, if it holds, is a large enough haircut on every winning trade that it has to be measured with real money. Paper can’t.

The fix that came from a wrong diagnosis

On 12 October, before the post-mortem, I diagnosed the losses as our real buys springing rugs on very young pools. The fix was a variant that waited longer before entering. In dry-run it lost 11.2% per trade over 22 positions, against a backtest that had promised a healthy profit. The bootstrap put the chance of a result that bad, if the backtest were right, at under 1%.

On the same 22 tokens, the original timing made money on paper. The variant entered a median 826 seconds later and found a new way to lose: almost a quarter of its entries never bounced and drifted down until the four-hour time limit, against 2% for the original. The post-mortem then showed paper had caught the same rugs at the same pool ages, so the diagnosis behind the variant was wrong. I retired it.

The veto model told the same story from another angle. On the variant’s signals it scored only 2 of 268 above its cutoff, and the bot’s existing filters had already skipped both. It had nothing to add there, so I stopped that experiment without a verdict rather than wait two months for one.

Where it stands

The next step is a new real-money canary, under a rule I locked on 28 October, before its first trade:

• the original timing, the live bot’s skip filters and the frozen veto model;
• 5% of equity per trade, at most three positions open, $100 of starting funds and no refills;
• running continuously, with a manual pause allowed only for a kill rule, a bug or a chain-wide incident, and never for losses alone;
• four kill rules, three of them enforced by the bot itself, for example three unsellable tokens in the first 30 trades, or equity under $50;
• a verdict at 150 trades: pass if the 95% interval of the mean trade is above zero, kill if the mean is at or below zero, otherwise continue to a final verdict at 300.

Its first job isn’t to make money. It’s to measure the two things paper can’t: whether real take-profit sells fill (by late October only one had, close to paper’s price for the same token), and the real honeypot rate.

What I’d tell someone starting this

1. Record forward. Free memecoin histories are survivorship-biased past the point of usefulness.
2. Assume you fill at the next price, not this one. Several neighbours of the surviving rule died the moment I did.
3. Check what “liquidity” means. My best result ever was a manipulated price on a small exchange.
4. Pre-register, including the kill. It killed a model I liked by 1.1 points, and a candidate that passed its own test.
5. Post-mortem against paper before changing anything. My first diagnosis of the live losses was wrong, and the fix built on it lost money.
6. Size so that your minimum trade is small next to your equity. Correlated losses on a tiny wallet will trip any stop you set, at the worst time.

The engineering

The recorder, simulator, paper traders and live bot are Python, running as one service with a persistent database on Railway, with tests that replay real saved chain transactions. The live bot simulates every buy and sell on-chain before sending it, holds a capped amount, sweeps profits to a separate wallet whose key isn’t on the server, and never refills itself. A Next.js dashboard on Vercel shows live, paper and dry-run books side by side, a chart for each trade, a rug analysis page, and a pause switch and wallet transfers behind a PIN.

None of that was the hard part. The hard part was not believing my own numbers.