← All work

meme-sniper

Records every token launch on pump.fun so the current regime can be measured before anyone tries to model it.

Role
Sole engineer
Year
2026
Status
in development
Built with
Python, SQLite, Litestream, AWS EC2
Go look
  • 36k–65kLaunches seen per day
  • 1.2e-16Curve residual, worst
  • top 0.1%Tracked in full

This is a measurement instrument, not a trading bot. Phase one is meant to produce a number, not a strategy. It is recording now and has no results yet.

Why record before modelling

On 21 July 2026, pump.fun shipped a mechanism called BOOST that reinjects previously dead liquidity as post-migration buybacks and burns. Graduation rates moved from around 0.2% to somewhere between 4.7% and 6.7%, roughly eightfold.

Every published threshold, heuristic and model for this market predates that change and is calibrated against a mechanism that no longer exists. They are still available, and they will still fit historical data from a regime that is gone.

So the first job is to measure what the market looks like now and treat every inherited constant as suspect until it is re-measured.

A funnel shaped by what is free

Free-tier API quotas are the binding constraint, so the architecture is four tiers with the budget spent only on survivors.

Tier Population Cost What happens
0 Firehose every launch, 36k to 65k a day free record raw, no filtering
1 Metadata 5 to 15% free resolve the metadata URI to socials
2 Enrichment 1 to 3% rate-limited deployer history, holder concentration
3 Tracked ~0.1% RPC polling curve velocity, score, paper trade

Tier 1 carries the strongest published signal in the space and costs one HTTP GET: across 832,941 launches, tokens advertising a Telegram graduated at 1.485% against 0.166%, and tokens carrying all three social channels at 1.919% against 0.110%. That is roughly nine times and seventeen times, for free, on the cheapest tier in the funnel.

There is also a statement of where an edge cannot come from. Bundle snipers own the first two blocks after a launch and no free-tier setup will beat them there. What is potentially winnable is a selection edge on a thirty second to five minute horizon, using how few trades it took to reach a given liquidity level as a proxy for large-ticket conviction rather than bot churn.

Reading the curve rather than the documentation

The bonding-curve constants were measured against live frames instead of taken from docs. Virtual SOL opens at exactly 30.0, virtual tokens at 1,073,000,000, and their product holds as an invariant across every launch observed, with a worst-case residual of 1.2e-16, which is floating-point noise.

That precision is useful for one specific thing. Create frames report state after the developer’s own pre-buy, so subtracting the opening constant from the reported virtual SOL gives exactly how much the deployer bought of their own token, at time zero, with no RPC call and no cost. That is a direct rug signal sitting in a field that looks like a constant until you check it.

Those constants are pinned in tests against real captured frames. If pump.fun changes a curve parameter the test suite fails, rather than the features quietly becoming wrong.

What the stream does not tell you

Each of these would have corrupted the dataset without being obvious.

One stream carries two venues. A second launchpad shares the subscription with a different payload shape, so classification branches on the pool field rather than on anything that looks like a naming convention.

There is no timestamp. The stream does not carry one, so arrival time is our clock, not the chain’s. Any real timing feature has to resolve block time from the signature, and treating receipt time as truth would bake network latency into the model.

Instant-bond bundles exist. One token had its creation and its migration twenty-four milliseconds apart: a create plus a full curve buy in a single bundle. It was never buyable by anyone and it is not organic demand, but to a naive model it is the most successful launch in the dataset. Left in, it teaches the model that graduating fast is good. It is detected and excluded.

Graduation rate is a cohort question. Dividing migrations by launches over the same window is wrong, because most migrations observed belong to tokens launched before the recorder connected. Only cohort-based rates get reported.

The creator is not always the signer. The on-chain creator field disagrees with the transaction signer in ten to twenty-five percent of samples, because proxies and bundlers sign on someone else’s behalf. Any deployer-history feature has to decide which identity it keys on, and the disagreement is itself a candidate signal.

Serial spam is the dominant behaviour. In one seventy-five second window a single creator launched five tokens under one symbol, and two mints shared an identical name, symbol and metadata URI seconds apart. A duplicate creator and URI pair is a free spam filter.

The kill criterion

Written down before collection began: if three weeks of paper trading comes out negative once a realistic two percent round-trip cost is applied, the conclusion is that no edge exists at this latency tier, and the project stops or changes approach.

It is in the repository and agreed in advance so the result cannot be graded after the fact. The base rate before the protocol change was that roughly 0.2% of tokens graduated, and one study found 98.6% of launches carry pump-and-dump signatures, so this is a domain where a pattern in noise is easy to find.

No real money is involved at any point. Paper trading only, no hot wallet, free API tiers throughout.

Where it is

Live on a small EC2 instance since 5 August 2026, running under systemd with Litestream replicating the database off the box, plus a periodic local pull. The deploy runbook covers the free-tier account expiry that would otherwise end the collection silently.

Tier 0 and tier 1 are running. Tiers 2 and 3, the scorer, the paper-trading ledger and the analysis are not built yet, and there is no point building them against a fortnight of data.

The value of this depends on wall-clock time. It has been collecting for a week and a half, the viability question is open, and the answer arrives when there is enough data to answer it.