mintguardian ~/research/case-speedrss

SPEED GANG ($SPEED) on Solana: LP locked with 39 minutes left

contract

6AJJUGB6nK4vacepkwAtohTQQcf4CS96LqTk1tYnCWjd

scanned

2026-09-21 17:21 UTC

verdict

LOW RISK 90

pool depth

$88,259 → $823 in seven days

written by Yaroslav Doroshenko · MintGuardian

We rated this token LOW RISK 90. Its liquidity was locked when we scanned it, with 39 minutes left on the lock. Twenty-eight seconds after the lock expired, the creator withdrew it. This is a miss, and this post is about why.

what the scan said

Scanned on 2026-09-21 at 17:21 UTC from the released app. Verdict LOW RISK, score 90, confidence 75. The token was 16 days old, and the pool held $88,259.

All three findings were low severity: supply concentration (top ten wallets 27.9%), exit price impact, and token age. Mint and freeze authority were revoked. Nothing in the contract could block a sale.

Not measured in this scan: whether the pool's liquidity was locked. At the time, the scanner read LP locks on Solana only for pump.fun pools. This was a Raydium pool, so the lock went into the list of unknowns and lowered confidence from 90 to 75. It did not lower the verdict.

what happened on chain

The pool creator held about 84% of the pool's LP tokens. From 2026-09-09 they kept them in Streamflow: 34 locks in twelve days, each lasting between 1 and 24 hours, most of them 5 to 9. When a lock ended, they usually locked the LP again within minutes. In all, the LP sat unlocked for about 15 hours out of 296. The last two locks were one hour each.

Streamflow takes a fee on every lock. By the end, those fees had cost the creator about 15% of their LP.

Our watchlist measured the pool at $92.6k at 17:46 and at $1.3k at 18:16. We scanned the token again at 20:46: RISKY 69, with $1,369 in the pool. Seven days later it held $823.

The pool reserves confirm this was a withdrawal and not only selling. Selling into a constant-product pool keeps its invariant k. Here √k fell by about 84%, the creator's share of the LP, and stayed flat afterwards.

why the scanner called it LOW RISK

Two things went wrong.

First, the scanner did not read the lock at all. An unmeasured lock cost confidence, not score. A token whose lock we could not see could still be rated LOW RISK, as long as everything we could see looked clean.

Second, even reading the lock would not have been enough. At 17:21 the LP was locked. A scanner that counts "locked" as safe would have reported 84% of LP locked, which is worse than reporting nothing. The lock that mattered was the one ending in 39 minutes.

what we changed

The scanner now reads LP locks on chain for Raydium v4 and CPMM pools, Raydium Burn & Earn, and Streamflow locks, including when each lock ends.

• LP counts as locked only if it is burned, sits in Raydium's Burn & Earn locker, or stays locked until more than 30 days after the scan.
• A lock that ends within 7 days is its own high-severity finding, with the time in the text: "LP unlocks in 39 min (2026-09-21 18:00 UTC)".
• LP held by a wallet is shown as held by a wallet, never as locked.
• A young token whose lock cannot be read is capped at RISKY. Not measuring something can no longer produce a better verdict than measuring it.

On the same saved data, the current engine rates SPEED RISKY 74 instead of LOW RISK 90. The lock itself can't be re-read as it stood at 17:21, so we rebuilt that state in a test from the transactions above. In that test the scanner shows the 39-minute unlock as a high-severity finding.

The lock reader covers Raydium v4 and CPMM pools only. Concentrated-liquidity pools (Raydium CLMM, Orca, Meteora DLMM) hold liquidity as position NFTs, and we don't read those locks yet. Young tokens there stay capped at RISKY.

the wider pattern

We revisit every scanned token seven days later and record its pool depth. For tokens younger than 60 days we have 55 comparable results, counting a token once for each day it was scanned. 11 of them kept their liquidity.

A lock doesn't change that picture much. Eleven fresh pump.fun tokens in our data lost more than 90% of their depth within a week, or had no pool left at all, and every one of them had 100% of its LP burned. Burned LP can't be withdrawn, so nobody pulled those pools. The depth went out through trading.

So a burned or locked LP only tells you the creator can't pull the pool. It doesn't tell you the pool will last. SPEED's pool was pulled. Most of the young tokens above were simply sold down.

limits

A lock tells you nothing past its end date. For twelve days SPEED's LP was locked about 95% of the time, so almost any check would have found it locked. The last lock was set 19 minutes before our scan and ended 39 minutes after it.

It does not show intent from the lock alone. Short locks have legitimate uses, and a creator who renews them may never withdraw. What it does show is that a short lock gives no protection, so we no longer count it.

55 results is a small sample. The seven-day numbers describe the tokens people scanned with our app, not the market.

This is one token, and it is a case we got wrong. It says nothing about the scanner's accuracy in general.

The scan, the pool depth and the seven-day revisit are our own records. The lock and withdrawal timeline is read from on-chain transactions after the fact; the hashes are in the data section. We did not measure price, and we did not track who bought or sold.

data

Our records: scan 3069 (17:21), rescan 3078 (20:46), seven-day revisit 45. On chain (Solana):

All of it as JSON: case-speed.json · addresses only, no user data.