Open Trader
A Rust system for collecting data on fresh coin releases, and testing entry/exit strategies through paper simulation.
- Category
- Market data / quantitative research
- Tags
Overview
Open Trader watches new coins launch on Solana across pump.fun, Raydium and Meteora, records everything that happens to them, then tests entry and exit rules against that record.
It buys nothing. There is no live trading code in the repo, on any branch, and no real money has ever gone through it. Every trade in it is simulated against data already collected.
I built it to answer one question. Is there a rule here that makes money, or does it only look that way if you squint?
The answer so far is no
Published base rates: 68.7% of these coins are dead on launch day, 80.4% inside 48 hours, about 1.4% ever graduate, and roughly 0.005% reach a $1M market cap. Those are from public datasets, not from me.
My own number is worse than break-even. Break-even needs about an 11.2% hit rate. The one run I've measured came in at 6.8%, and that run is itself contaminated, so even the bad number is untrustworthy.
The genuinely interesting finding is that picking winners isn't the binding constraint. Getting out is.
Why getting out is the real problem
PumpSwap (pump.fun)
- Pool size at graduation
- $10k to $15k
- What you can actually sell
- $5 to $50 per trade
Believe DAMM v2 (Meteora)
- Pool size at graduation
- ~$100k migration threshold
- What you can actually sell
- $200 to $500 per trade
Raydium LaunchLab
- Pool size at graduation
- ~$80k to $100k
- What you can actually sell
- $200 to $500 per trade
From the research dossier in the project wiki. Constant-product math: keep any single exit under 1 to 2% of the pool or you crater your own price on the way out. At pump.fun depths the strategy cannot even pay for its own infrastructure, which runs $150 to $500 a month.
I threw the first version away
The previous codebase had a concentration gate that called an RPC returning null for every Token-2022 and pump.fun mint. So the gate never ran. Not once. All 73 trades went through blind while I thought they were being filtered. Add 16 measurement bugs on top.
Every number it produced was garbage, so I binned the whole thing and started again with one rule: collect everything, filter nothing, decide later. A filter applied before collection means you only ever see what passed it, so you can never measure what it cost you.
The bar a result has to clear
Positive every complete day
Not positive on average. Positive on each day, separately.
Still positive after dropping the best three trades
This one kills almost everything. If your profit lives in three lucky wicks, you don't have an edge, you got lucky three times.
At least 30 trades a day
Below that I'm reading noise and calling it a signal.
Capture and research boundary
- Outside dependency
- Processing
- Stored data
Architecture from the September 2026 project report. The processor only reads the database and can't touch the chain, so a rule can't quietly use information the real population never had.
The pieces
Capture
- Job
- Spot launches, parse and dedupe them, add creator, holder, pool and fee context.
- What it produces
- Token observations with provenance.
- Notes
- The only part that touches the chain.
Persistence
- Job
- Store observations, trajectories, quality flags and paper results.
- What it produces
- Relational tables.
- Notes
- The contract between capture and research.
Processor
- Job
- Pick candidates from captured rows under as-of-entry rules.
- What it produces
- Paper divisions.
- Notes
- Database only, by construction.
Simulation
- Job
- Apply execution assumptions to each candidate.
- What it produces
- Simulated trades and exits.
- Notes
- Fills, retries, delays, fees, sizing, exits.
Reporting
- Job
- Compute results under several measurement bases.
- What it produces
- PnL, exclusions, concentration, uncertainty bands.
- Notes
- Frozen and realistic bases sit side by side instead of one overwriting the other.
Operations
- Job
- Watch stage health and capture freshness.
- What it produces
- Health signals and verification output.
- Notes
- Built to fail loudly rather than quietly.
Jobs as described in the September 2026 project report. Rust over a relational database. This says nothing about how many instances run, or where.
Four things that decide if a result means anything
Observation time
What you could know at entry, against what you know now. Mixing those is the most common way a backtest invents an edge.
Units and identity
One venue stores reserves raw and scales them on read. Another doesn't. Get it wrong and your numbers look perfectly reasonable and are complete bullshit.
Missing data
Data that's missing is rarely missing at random. It goes missing when the venue is weird or the system is loaded, which is exactly the thing you were trying to measure.
Cohort
Which rows counted, which got dropped, and why. Change the denominator and the result changes without anyone touching the strategy.
Anatomy of a paper experiment
- Stored data
- Processing
- Proposed, not built
From the September 2026 project report. The dashed box is proposed. Right now part of an experiment's definition lives in deployment config, so a saved result can't be fully rebuilt from what got saved with it.
Research log
2026-07-29
- What I asked for
- Audit STRAT-4 again, in a loop.
- What came back
- A full week of results came out statistically and methodologically zero. The profit was about ten overshoot wicks. 48 agents, 20 findings confirmed, 0 refuted.
2026-08-01
- What I asked for
- A decision brief on the production gate.
- What came back
- Four options, measured consequences, no recommendation. The gate was throwing away 22 to 33% of the winners it existed to catch.
2026-08-21
- What I asked for
- "NARROW THE WORLD". I called it the most important job til now.
- What came back
- Four measurements replaced four guesses. Failed transactions were 3.5x more common than assumed, but retries were nearly free. MEV was negligible at 0.02% of volume. Chance of a losing year fell from 45% to 21%.
2026-08-24
- What I asked for
- Find out why Token-2022 launches stopped.
- What came back
- The venue stopped, not my capture. Last one at 00:49:49 UTC, then nothing. My side proved clean three separate ways.
2026-09-06
- What I asked for
- "Return positive-PnL arms."
- What came back
- No. About 520 combinations tested, five whole families refuted. One survivor passed every test except sample size: 24 winners out of 24, at roughly 8 tokens a day.
Real entries from the project wiki. Each was a working session with an AI agent, and the quoted bits are what I actually typed.
What's broken or unknown
- Paper only. No edge found, no live money, not production ready. The honest headline is a negative result.
- You can't rebuild an experiment from its own results yet. Part of the definition sits in deployment config instead of next to the result.
- Capture completeness isn't queryable. A quiet venue and broken capture look identical from outside, and I've had to work out which after the fact more than once.
- Units differ per venue and get converted on read. That's a trap for anyone analysing the data later, including me.
- Results move with the cohort definition, and that logic is spread across big reporting functions instead of stated once.
Next
Experiment definitions saved next to their results, consistent units and IDs, and real proof that capture is complete. The point is making results easy to rerun and pick apart.
The thing I actually want is a ledger that answers what was expected, what arrived, and what got stored. Per venue, per stage, per hour. Right now that's forensics after the fact.
Who did what
I built it, with AI tooling throughout. The architecture and its weak spots are mine.
Useful collaborator: someone with real quant experience willing to attack the measurement instead of the strategy. The cohorts, the exclusions, and every place a reasonable-looking number could still be wrong.