I paper-tested an AI memecoin trading bot for 2 days. Here's what the safety checks caught, and what they didn't

Timothymycompc — Tue, 03 Nov 2026 11:35:07 +0000

On November 1 a post went around X claiming an AI agent had turned $280 into $3,412 overnight trading Solana memecoins. It came with the prompt that supposedly built it:

Build me a fully autonomous Solana memecoin trading desk that prioritizes capital preservation.
Six agents with hard handoffs: SCOUT, FILTER, ANALYST, EXECUTOR, RISK, LOGGER.
Paper trade first. Run overnight. Recap in the morning.
Do not skip any risk management rules. If a condition cannot be verified, reject the token rather than assume it is safe.

I couldn't verify the $3,412. So I built the desk from that prompt, word for word, and ran it on paper money with real prices, out in the open. I call it the deskbot. This is what it does, and what two days of it taught me.

Nothing here is real money and nothing here is advice. There is no live mode. The desk exists to find out whether this kind of bot survives contact with real memecoins.

Why I built it

I build Solana Pulse, a set of safety tools for people and AI agents: is this token a trap, is this transaction safe to sign, where did the money go. A safety check can't make a token safe. It looks for the known ways people get robbed. The honest way to find out what it misses is to put real decisions behind it and watch what happens.

A trading bot is the hardest test there is. It checks hundreds of brand-new coins a day, it acts on the answer, and every miss shows up as a loss with a timestamp.

How it works

Cloud Scheduler wakes the desk once a minute on Google Cloud Run. Each agent hands off to the next and can only say yes or no:

SCOUT pulls new pools (Pump.fun, PumpSwap, Raydium, Meteora) and the pools trending in the last hour from GeckoTerminal.
FILTER rejects anything that fails a hard rule: under $50k traded in the last hour, mint authority not revoked, under 95% of pool liquidity locked or burned (RugCheck), top 10 holders over 20%, a creator with a bad history, freeze authority on, or a simulated sale that fails. Anything it can't verify is rejected, as the prompt says. Every coin also goes through Solana Pulse's token_safety.
ANALYST scores what's left from 0 to 1: pool age, liquidity, buy pressure, number of buyers, the 1-hour price move and turnover. Below 0.6 is out. The weights are a guess the paper run is there to measure.
EXECUTOR makes a paper buy at 8% of equity, with a swap fee and price impact taken off. One trade per coin: no averaging down, no re-entry.
RISK runs first every minute: sell at -6%, and once a trade is up 12%, a trailing stop sells 6% below the peak.
LOGGER writes every scan, rejection (with its reason), score, buy and sell to Postgres. Those rows are the source for every number below.

The live desk is public and read-only: https://trade-desk-1021990235790.us-central1.run.app/desk

Run 1: up 24%, then three rugs

The first run started November 1 with $1,000. By the afternoon it was at $1,244. By the evening it was at $761.76 (-23.8%): 8 trades, 1 win.

Three coins did almost all of it. Two different coins both named AODF, then one named XTO, each lost 90-100% of its price inside a minute. Those three trades were $224 of the $238 lost.

What a rug looks like up close: XTO climbed slowly all day on about $500 of trading a minute. Then a single sale of $1.8M hit its pool, and the price went from $2.03 to $0.00017 in that same minute. A stop-loss can only sell at the price that's left, and nothing was left.

Why Solana Pulse missed it. About three minutes after AODF launched, its creator sent around 667 transfers in 3 seconds, splitting the supply into many wallets. That makes the top 10 holders look tiny (0.5%), so the coin passed the concentration rule. Pulse did see a network of over 500 linked wallets, but it ignored groups that big, because on old coins they're usually an exchange or an airdrop. On a coin less than a day old, that was wrong.

What changed in Pulse (with tests built from the real AODF and XTO data):

big linked-wallet groups now count on new coins
a new creator_split check catches a creator splitting the supply right after launch
a warning when a new coin is worth over 100x the cash in its pools (XTO was 487x when the desk bought it)
a note when other coins use the same ticker
a rug_chance answer with its reasons

Building creator_split also turned up a real bug: fetching a creator's transactions in one batch throws on version 1 transactions, so the check came back "unknown". I wrote that one up separately: Solana RPC error -32015.

Run 2: two lanes

The desk restarted November 2 at 13:15 UTC with the new checks and a second lane:

Main desk: the original six agents.
Fast lane: its own $1,000. It buys every coin that passes FILTER unless Pulse says AVOID, checks prices every 10 seconds, and sells at +10%, -6% or 30 minutes, whichever comes first. A replay of the first day's coins said these rules would make about +3.8% a trade, but that was only 15 coins. The fast lane is there to test it until it has 50 trades.

After 21.5 hours (read November 3, 10:50 UTC):

	Equity	Trades	Wins
Main desk	$892.90 (-10.7%)	5	0
Fast lane	$955.46 (-4.5%)	12	3

The lesson of the day. At 05:10 UTC a brand-new coin, also called XTO, 48 minutes old and up 6,986% in an hour, passed every FILTER rule. Pulse said AVOID, and its reason named the exact pattern: supply split across many wallets, like AODF and XTO, both dumped 99%.

The fast lane skipped it. The main desk still allowed AVOID coins in a "likely rug" tier that sells in steps on the way up, so it bought. Seventeen minutes later it was -100%. That one trade is $77 of the $107 the main desk is down.

The fast lane isn't matching its replay. It averages -4.7% a trade, not +3.8%. Three reasons so far:

The replay stopped out on a minute's closing price. Live, the stop fires on any 10-second price, and these coins swing 30-50% inside a minute. One coin was stopped at -17.7% and then went to +17% above entry.
Three stop-losses filled at -13% to -22% within 5-15 seconds of the buy.
FILTER wants $50k of volume in the last hour, so both lanes buy after the spike, not before it.

Does Pulse's AVOID mean anything?

I checked every coin the desk asked Pulse about (299 checks, 296 coins, November 1-2) against its price on November 3:

Pulse said	Coins	Down 90%+ or no longer priced	Up
AVOID	220	150 of the 183 with a price at check time (82%)	5%
CAUTION	65	37%	22%
SAFE	15	0	7%

"No longer priced" means Jupiter stopped pricing the coin. That's a strong sign it's dead, not proof. The SAFE coins were all established tokens (WBTC, ETH, Bonk and the like), and the coins were at most 40 hours old when measured, so this is short-term only.

My read: Pulse separates rugs from the rest well, and CAUTION is a real risk tier. The desk's losses come from its trading rules, not from the safety checks.

What's next

The main desk stops buying anything Pulse calls AVOID.
Stops judged on a steadier price than a single 10-second tick.
The fast lane keeps going until it has 50 trades. Then the numbers decide, not the replay.

If the $280-to-$3,412 bot is real, its edge isn't in the prompt. Following that prompt exactly, carefully and with good safety data, loses money on paper. That's worth knowing before anyone runs it with real money.

The safety checks come from Solana Pulse: 18 tools for people and AI agents, over MCP or plain HTTP, 25 free checks per tool per day.

Website: https://solana-pulse-gateway-1021990235790.us-central1.run.app
Live desk: https://trade-desk-1021990235790.us-central1.run.app/desk
X: https://x.com/solanapulsebots
GitHub: https://github.com/Timothymycompc/solana-pulse-ai-agent-gateway
YouTube: https://www.youtube.com/@timothymycompc1205
Email: timothymycompc@gmail.com

Solana RPC error -32015: why 4 in 10 transactions vanish from your app

Timothymycompc — Tue, 03 Nov 2026 03:46:20 +0000

If your Solana code logs this:

Transaction version (1) is not supported by the requesting client.
Please try the request again with the following configuration parameter: "maxSupportedTransactionVersion": 1

your code asked the RPC for transactions up to version 0 and the one it wanted is version 1. The RPC refuses it instead of answering.

Why it matters now

Version 1 transactions went live on mainnet on 2026-09-15 (the first one we found is in slot 447,120,004). In sampled mainnet blocks they were 13.8% of non-vote transactions the week of Sep 14 and 41.9% from Oct 16 to 30 (44.4% of swaps). Whether you see one depends only on which wallet or SDK the sender used, so a payment can fail for one customer and work for the next.

We reported this bug in 30+ open-source projects. Six maintainers have already fixed it: Agent402, elizaOS, UltiMafia, rotki, taurvia and sol-parser-sdk-nodejs.

The fix

// @solana/web3.js 1.99.0 or later (1.98.x throws on version 1 even with this setting)
const tx = await connection.getTransaction(signature, { maxSupportedTransactionVersion: 1 });

client.get_transaction(signature, max_supported_transaction_version=1)

let config = RpcTransactionConfig { max_supported_transaction_version: Some(1), ..Default::default() };

Same for getParsedTransaction(s) and getBlock.

Which library versions can read version 1

Tested on mainnet on 2026-10-30 against a real version 1 transaction:

@solana/web3.js 1.95.8 to 1.98.4: throw, even when asked correctly. 1.99.0+ works.
@solana/kit before 7.1.0 returns version as the bigint 1n, so version === 1 is false. 7.1.0+ works.
solana-py 0.30.2 to 0.41.0 works with max_supported_transaction_version=1.

Traps

getParsedTransactions / getTransactions throw for the whole batch when one entry fails: one version 1 payment hides 49 others.
Code that catches the error and returns null reports a paid transaction as "not found".
Raw version 1 bytes start with 0x81, so hand-written parsers break too.

Full page, with a live checker for any signature: https://solana-pulse-gateway-1021990235790.us-central1.run.app/fix/transaction-version-not-supported

DEV Community: Timothymycompc