DEV Community: manja316

308 Labeled Polymarket Crash Trades — Free Dataset For Mean-Reversion Research

manja316 — Tue, 28 Apr 2026 15:58:14 +0000

If you want to study mean-reversion on prediction markets, the data you actually need does not exist publicly. Most "Polymarket datasets" are either:

Synthetic — generated for academic papers, no real money behind them.
Aggregate — hourly volume and last-price across thousands of markets. Useless for tactical signal research.

So I built one and open-sourced it: cross-signal-data.

pip install cross-signal-data

from cross_signal_data import load
df = load()                          # pandas DataFrame, 308 rows
print(df["is_profitable"].mean())    # 0.802

This is the actual labeled outcomes of 308 closed trades from a live Polymarket crash-recovery bot, with the signal features and the resolved outcome for each trade.

Also mirrored on HuggingFace: huggingface.co/datasets/LuciferForge/cross-signal-data.

What's in the dataset

19 columns, one row per closed trade:

Column	Description
`trade_id`	Sequential 0-indexed
`market_id`	Polymarket market ID (queryable via `gamma-api.polymarket.com`)
`question`	Market question text
`outcome_label`	YES/NO outcome the bot bet on
`entry_time`	When the crash signal fired (ISO-8601 UTC)
`exit_time`	When the position closed
`entry_price`	Per-share price at entry (0–1, Polymarket prices are probabilities)
`exit_price`	Per-share price at exit
`pre_crash_high`	Recent local-window high before the crash trigger
`drop_pct`	`(pre_crash_high − entry_price) / pre_crash_high × 100`
`size_usd`	USD allocated (typically $5)
`shares`	Share count purchased
`hold_hours`	Wall-clock hours from entry to exit
`pnl_usd`	Realized P&L (theoretical, see below)
`is_profitable`	1 if `pnl_usd > 0` else 0
`exit_reason`	RECOVERY / TIMEOUT_48H / TIMEOUT
`entry_hour_utc`	Hour-of-day at entry
`entry_dow`	Day-of-week at entry (0=Monday)
`recovered_to_pct_of_high`	`exit_price / pre_crash_high × 100`

Aggregate stats

308 trades, 247 profitable (80.2% WR)
Date range: March 2026 – April 2026
Median hold: ~3 hours
Average drop_pct at entry: ~22%
Average recovery: ~85% of pre-crash high

Exit reason distribution

Reason	Count	What it means
RECOVERY	235	Price climbed back to ~90% of pre-crash high. Took profit.
TIMEOUT_48H	62	Held 48 hours without recovery. Sold at whatever the bid offered.
TIMEOUT	11	Older shorter-window timeout from earlier in the dataset.

Sports markets where the team had already lost the underlying game often end up in TIMEOUT_48H. So do political markets that crashed because the resolution fundamentals shifted, not just because of momentary panic. The bot's job is to filter those out before entering; the dataset shows where the filter fails.

How I used it

Loaded the data with the bundled loader, ran a logistic regression and a random forest, got 79.9% cross-validated accuracy from 7 features:

Feature	RF importance
`drop_pct`	0.254
`shares`	0.200
`entry_price`	0.174
`pre_crash_high`	0.171
`entry_hour_utc`	0.110
`entry_dow`	0.059
`size_usd`	0.031

Translation: the bot's trigger filter is doing 100% of the work. A simple model that just learns "crashes with bigger drop_pct in the right time-of-day window are more likely to recover" basically reproduces the bot's actual win rate. There's no obvious feature engineering trick that beats the trigger.

The diurnal pattern is interesting. Hours 16, 21, 22 UTC have ~100% WR (small samples). Hour 8 UTC dips to ~55%. Off-peak hours (when US/EU traders are asleep, books are thin) are punishing.

df.groupby("entry_hour_utc")["is_profitable"].mean()

Run that yourself and see.

Important caveat: theoretical P&L vs on-chain P&L

The pnl_usd column is theoretical — computed from the bot's recorded entry_price and exit_price. This assumes you got every share filled at those prices. In practice on thin Polymarket books, fills come in slightly worse, especially for TIMEOUT exits.

I built a separate audit tool that reconciles the bot's records against on-chain fills: pnl-truthteller. On this same 308-trade dataset, it surfaces:

Theoretical P&L:  +$33.49
Actual P&L:       -$89.01
Slippage cost:    -$122.50  (-365.8% of theoretical)

So the bot has 80.2% trigger-level WR but is slightly underwater once slippage is included. That gap is worth more than the trigger itself — it tells you that the exit ladder strategy was walking thin books down. Interesting research question, exactly the kind of thing the dataset enables.

pip install pnl-truthteller
pnl-truthteller --wallet 0xYourProxyAddress

If you build a strategy on top of the dataset, run pnl-truthteller against your live wallet too. Otherwise you'll think you're profitable when you aren't.

What this dataset is good for

Mean-reversion alpha studies — does crash-recovery actually work? At what drop_pct does it start working? The data has all the inputs.
Time-of-day effects — entry_hour_utc × is_profitable reveals diurnal patterns.
Hold-time tradeoffs — the win-rate vs hold-hours curve is in here.
Feature-engineering exercises — if you can predict is_profitable better than 80% accuracy from these features, you've found something.
Backtesting frameworks — real labeled data with real prices, suitable for cross-validation.

What it's NOT good for

General Polymarket research. Too narrow a slice (one bot, one signal, two months).
High-frequency studies. Only entry/exit timestamps, not tick-level.
Counterfactuals ("what would a different bot have done?"). Only triggered trades are recorded.

Known biases

1. Survivorship in the trigger

Only contains markets where the trigger fired (>20% drop, $0.04–$0.30 entry range). If you'd used a different threshold, you'd see different markets.

2. Selection in the entry-price band

Most rows are concentrated in $0.04–$0.30. Markets that crashed from $0.80 → $0.50 are absent (above the range). Markets at $0.02 are absent (below the floor).

3. Theoretical PnL ≠ realized PnL

See above. Use pnl-truthteller for slippage-adjusted analysis.

4. Time period

March–April 2026. Includes one Polymarket V1 → V2 migration window, various political events specific to the period, and Polygon-specific gas conditions.

Don't assume the patterns extrapolate forward indefinitely. Re-run the dataset extraction quarterly as it grows.

Reproducibility

The script that generated the dataset from the bot's positions.json is checked in: scripts/extract.py. Anyone with the bot's source data can rerun it and get the same output.

git clone https://github.com/LuciferForge/cross-signal-data
cd cross-signal-data
python scripts/extract.py \
    --positions /path/to/positions.json \
    --output data/crashes_v1.csv

The dataset file is also bundled inside the pip package — cross_signal_data.load() returns the data without any external download.

License & citation

MIT. Use it, fork it, train on it, build a competitor strategy. The chain is public; the data is public; the code is public.

If you publish research using it:

@dataset{cross_signal_data_2026,
    title  = {cross-signal-data: Polymarket crash-recovery labeled dataset},
    author = {LuciferForge},
    year   = {2026},
    url    = {https://github.com/LuciferForge/cross-signal-data}
}

Resources

Repo: github.com/LuciferForge/cross-signal-data
PyPI: pip install cross-signal-data (pypi.org/project/cross-signal-data)
HuggingFace mirror: huggingface.co/datasets/LuciferForge/cross-signal-data
Slippage audit tool: pip install pnl-truthteller — github
Bot source: github.com/LuciferForge/polymarket-crash-bot — same bot that produced this data

If you build a model that beats 80% on this dataset, I want to know what feature you used. The bot's edge is mine until someone finds a better one.

LuciferForge runs a public-audited Polymarket trading bot, protodex.io (5,800+ MCP servers indexed), and the free Polymarket data API.

80.2% Win Rate on 308 Polymarket Trades — Open Source, Public Data, On-Chain Verifiable

manja316 — Tue, 28 Apr 2026 15:57:38 +0000

I run a Polymarket crash-recovery bot. As of today, it has placed 308 closed trades at an 80.2% win rate. The bot is open source. The 308-trade dataset is open source. The audit tools that prove the numbers are open source. Every claim in this post is verifiable.

This isn't "I built a trading bot, here's a screenshot." This is the full data, the open code, and the honest lessons.

The numbers, with no spin

Metric	Value
Closed trades	308
Profitable	247 (80.2%)
Date range	March 2026 – April 2026
Median hold time	~3 hours
Average drop_pct at entry	~22% (from recent local high)
Average recovery to	~85% of pre-crash high
Theoretical lifetime P&L	+$33.49
Actual on-chain P&L	-$89.01
Hidden slippage cost	-$122.50

Yes — that last number is real. Despite an 80.2% WR, the bot's actual on-chain P&L is negative because of slippage. The DB said +$33; the chain said -$89. I open-sourced the audit tool that surfaced this gap as part of today's release: pnl-truthteller. More on that below.

The bot is profitable on average per-trade entry, but the exit-ladder strategy walked thin order books down on TIMEOUT exits, and that ate the alpha. This is the kind of finding that only shows up when you compare your bot's records against on-chain reality. Most operators never do.

What the bot does

The bot enters Polymarket binary or multi-outcome markets when three conditions hit simultaneously:

The price has dropped > 20% from a recent local-window high (the "crash" signal).
The current price is in a sweet-spot range (originally $0.04–$0.30; raised to $0.04–$0.60 today after a backtest showed the wider range had 81.8% WR on a recent slice).
The orderbook has enough bid-stack depth to absorb the position size within a slippage budget.

It enters at $5 per trade. No leverage. No exotic positioning. Single Polygon proxy wallet, all USDC.

The exit logic is where the alpha gets compressed:

RECOVERY (235 of 308 trades): price climbs back to ~90% of pre-crash high, sells. Profitable.
TIMEOUT_48H (62 trades): held 48 hours without recovery. Sells at whatever the bid stack offers. Sometimes profitable, often a small loss.
TIMEOUT (11 trades): older, shorter-window timeout from earlier in the dataset. Same logic, less generous.

That's it. The bot is ~500 lines of Python. The "edge" is in the trigger filter, not in clever execution.

The edge: why crashes mean-revert on Polymarket

Prediction markets have a structural property that doesn't show up in equity markets: the resolution probability is the price.

When a Polymarket binary contract trades at $0.20, the market is saying "20% chance YES." When it crashes from $0.40 to $0.20 in a few hours due to a news event, two things are usually true:

The fundamental probability (whatever the actual likelihood is) didn't change by 50%. News events overcorrect.
Liquidity is asymmetric — there are short-term sellers panicking out, but no equally-fast buyers stepping in. Bid stacks thin out.

The bot's job is to step in as the buyer when both happen. Most of the time, the price recovers within a few hours as cooler sellers reassess. That's a 2-3% win on a $5 position when it works.

I trained a logistic regression and a random forest on the dataset to see if I could predict is_profitable from the available features. Result: ~79.9% cross-validated accuracy on the simple model, basically matching the bot's actual WR. Translation: most of the alpha is in the trigger filter itself, not in feature engineering on top.

The dataset, the loader, and the baseline notebook are at: github.com/LuciferForge/cross-signal-data (pip install cross-signal-data).

What 308 trades teaches you that backtesting doesn't

Lesson 1: Slippage is bigger than you model

I built backtests assuming midpoint fills. Real exits on thin Polymarket books are 3–8% worse than midpoint. Across 302 closed trades, that compounded into the -$122.50 hidden cost noted above.

Detection: build the audit tool first. The bot kept a live_trades.db SQLite logging the raw response from every CLOB POST. The audit replays each closed trade against the chain's actual fills (deduplicated by orderID, because sweep retries log the same fill twice). The math is straightforward; the surprise is how big the gap is.

pip install pnl-truthteller
pnl-truthteller --wallet 0xYourProxyAddress

Read-only, no API key needed. Outputs a Markdown report with by-exit-reason breakdown, worst-10 trades, and dust shares stranded on-chain.

Lesson 2: Category concentration kills you

Three losing streaks in the dataset all came from the same market category in the same time window. Sports markets where the team had already lost the underlying game continued to trade with bid offers from people who hadn't yet updated. Easy to spot in retrospect; harder to filter automatically.

Today's release adds a tiered category blacklist with persistence — markets in losing categories get a 7-day cooldown after a TIMEOUT exit. Whether this moves the WR is a question for the next 30 trades.

Lesson 3: The bid-stack changes faster than your poll interval

A market that looks liquid at signal time can be thin by the time your limit order needs to fill. The fix is a buy-preflight check: before entering, verify the bid stack has at least 5 × shares_needed of capacity within your slippage budget. Skip if not.

Ship this from day one. We didn't, and learned the hard way.

Lesson 4: Per-token loss cooldown

If a specific token already cost you money via TIMEOUT, don't re-enter it for 7 days. Sounds obvious. Wasn't enforced for the first 200 trades. Some markets just have stuck consensus and will eat every entry attempt for the same reason every time. Moving on is cheaper than persistence.

The infrastructure underneath

Five tools shipped today, all built around the bot's actual operational lifecycle:

polymarket-crash-bot — the bot itself. 308 trades. Open source.
polymarket-mcp-pro — Polymarket data as MCP tools. Lets Claude/Cursor query live markets natively.
pnl-truthteller — fill-level P&L audit. Read-only, wallet address only.
quant-rollout — staged rollout toolkit. Gates, kill switch, veto window. Pure stdlib, zero deps.
cross-signal-data — the 308-trade labeled dataset. CSV + Python loader + baseline notebook.
sigil-ta — MCP-native TA runtime. 8 indicators + 2 composite signals + Polymarket Sentiment Divergence.

All MIT. All have tests. All have public CI-ready repos. If they save you a few hours, star them.

The bot also went through Polymarket's V1 → V2 migration today. That has its own writeup with a working code diff and a 12-error troubleshooting guide: polymarket-v2-migration.

The honest accounting

I would be lying if I said the bot is currently a money-making machine. It's break-even-ish in theoretical terms and slightly down once slippage is included. What it IS, with confidence:

A live, public-audited mean-reversion strategy on prediction markets
A credible 80.2% trigger-level alpha on a real (not backtest) sample
A complete data + tooling stack that lets anyone replicate and improve on it
A textbook case of why "I made money in backtest" ≠ "I made money on-chain"

The reason I ship it open source is because the real value is in the data and the tooling, not in the entry logic. The entry logic is 500 lines anyone can read. The 308-trade labeled dataset and the slippage audit tool are what took months to produce.

If you can do better than 80% on this dataset by adding features the bot doesn't currently log (orderbook depth at entry, market category metadata from gamma-api, time-to-resolution), you've found something worth more than my entry trigger. Go do it.

Resources

Bot source: github.com/LuciferForge/polymarket-crash-bot
Dataset (free, MIT): pip install cross-signal-data — github · HuggingFace
Slippage audit: pip install pnl-truthteller — github
TA runtime: pip install sigil-ta — github
Polymarket data MCP: pip install polymarket-mcp-pro — github
Free Polymarket data API: api.protodex.io

If you build something with the dataset, send me the link. If you find a feature that pushes the model past 80%, send me the diff. The bot's edge is mine until someone finds a better one — and at that point, I want to know what you found.

LuciferForge is a solo operator running a public-audited Polymarket trading bot. Also runs protodex.io (5,800+ MCP servers indexed) and the free Polymarket data API.

Sigil — An MCP-Native Technical Analysis Runtime That Talks to Claude

manja316 — Tue, 28 Apr 2026 15:57:01 +0000

I needed a TA library that did three things I couldn't find together:

Indicators that aren't a stack of opinionated TA-Lib glue. Pure Python, deterministic, zero runtime deps.
Composite signals my way, not LuxAlgo's. No copying. Different naming. Different weighting.
MCP-native runtime so Claude / Cursor / Cline can query live signals without glue code.

So I built one. It's called Sigil (pip install sigil-ta), and I'm releasing v0.1.0 today.

What's in the box

8 core indicators — pure Python, no numpy required

Indicator	Function
Simple Moving Average	`sma(closes, period)`
Exponential Moving Average	`ema(closes, period)`
Wilder RSI	`rsi(closes, period=14)`
MACD	`macd(closes, 12, 26, 9)` — returns line, signal, histogram
Bollinger Bands	`bollinger_bands(closes, 20, 2.0)` — upper/middle/lower
Wilder ATR	`atr(series, 14)`
Supertrend	`supertrend(series, 10, 3.0)` — line + direction
Stochastic	`stochastic(series, 14, 3)` — %K and %D

All deterministic, all return list[float | None] aligned to input length, with None during the warm-up period. No silent NaN propagation, no magic resampling, no exotic dependencies.

2 composite signals — our naming, our weighting

reversion_score(series) → list of values in [-1, +1]

Combines RSI deviation from 50, Bollinger Band position, and ATR-normalized deviation from the 20-bar SMA. Score of +1 means strongly oversold (likely reversion up); -1 means strongly overbought.

momentum_composite(series) → list of values in [-1, +1]

RSI deviation, MACD histogram (volatility-normalized), and Supertrend direction. +1 means strong sustained uptrend; -1 means strong downtrend.

I tested both on 500 hours of BTCUSDT 1h data:

ReversionScore (long+short, 10bps fees):
  24 trades, 66.7% WR, total_pnl_pct -2.84%, avg_bars_held 14.0

MomentumComposite (long-only, 10bps fees):
  6 trades, 50.0% WR, total_pnl_pct +2.69%, avg_bars_held 35.5

Real numbers from a real test. Not impressive, not unimpressive — exactly what you should expect from generic TA on a 500-bar window. The point isn't that these signals print money; the point is that they're honestly measurable, you can tune them, and they live next to a backtest harness with realistic fees and no look-ahead.

1 unique signal — Polymarket Sentiment Divergence (PSD)

This is the one that doesn't exist in any other TA library, because it requires data only Polymarket has.

PSD measures divergence between an underlying asset's price action and the resolved sentiment of a related Polymarket prediction market.

Example: BTC trades on Binance. Polymarket has a contract "Will BTC be above $80,000 by month-end?" The Polymarket price is a sentiment time-series — when bettors think yes is more likely, the price rises; when they think no, it falls.

PSD scores +1 when:

BTC price is dropping
AND the Polymarket "yes" probability is rising
= bullish divergence — sentiment thinks the dip is buying opportunity

PSD scores -1 when:

BTC price is rising
AND the Polymarket "yes" probability is falling
= bearish divergence — sentiment doesn't believe the rally

When both move together, PSD is near zero (no signal).

Why this matters: pure-TA libraries (LuxAlgo, ta, pandas-ta, ta-lib) do not have access to prediction-market sentiment. PSD captures information that a chart-only signal cannot see. It's an integration play, not a math play — anyone can copy the formula, but they need a Polymarket data layer to use it. Sigil includes the Polymarket fetcher (fetch_polymarket_price_history(token_id)) so the integration is built in.

Backtest harness with realistic fees

from sigil.backtest import backtest_signal
result = backtest_signal(
    series=ohlcv_series,
    signal=reversion_scores,
    entry_threshold=0.5,
    exit_threshold=0.0,
    fee_per_side_pct=0.001,  # 10 bps each side
)
print(result.summary())
# Backtest: 24 trades, WR 66.7% (16/24), total_pnl_pct -2.84%, ...

Decisions on bar i, fills at bar i+1 open. No look-ahead. Default 10 bps per side fee (realistic for retail crypto).

Live data fetchers

from sigil.data import fetch_binance_ohlcv, fetch_polymarket_price_history

btc = fetch_binance_ohlcv("BTCUSDT", "1h", limit=500)
pm = fetch_polymarket_price_history(token_id="...", fidelity=60)

Both use only Python's stdlib for HTTP. Zero runtime dependencies in core. Network only when you call the fetcher.

The MCP angle: indicators as Claude tools

If you've used Claude Desktop, Cursor, or Cline, you know how MCP tools work — they appear in the LLM's tool catalog and get called natively in the conversation.

Sigil exposes 14 tools through FastMCP:

pip install sigil-ta[mcp]
sigil-mcp                # stdio transport (Claude Desktop / Cursor / Cline)
sigil-mcp --transport http --port 8765   # HTTP transport

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "sigil": { "command": "sigil-mcp" }
  }
}

Then in Claude:

"Fetch the last 200 hours of BTCUSDT and compute the RSI and Bollinger Bands."

"Run a Supertrend backtest on ETHUSDT with default params."

"What's the MomentumComposite for SOLUSDT right now?"

The agent calls fetch_binance_ohlcv, then compute_rsi, then compute_bollinger_bands, and shows you the result. No glue code.

This is how I run my own analysis now. I haven't opened a TradingView tab in two weeks. Claude does the indicator queries directly, and when I want a chart, I ask it to render one with plotly.

Streamlit dashboard

pip install sigil-ta[dashboard]
sigil-dashboard

A simple chart-and-indicator UI for when you want to look at price visually rather than asking the agent. Pick a symbol, an interval, an indicator, see the output live. Backtest panel underneath for the composite signals.

It's not a TradingView competitor — it's a 200-line proof that the same indicators work in a UI when you want one.

Design choices

Pure stdlib core. No numpy, pandas, scipy required for indicators. Every implementation is plain Python doing arithmetic. This means:

Installs in milliseconds. No compilation.
Runs on cold-start serverless.
Never breaks because of a third-party version bump.

pandas, streamlit, plotly, mcp, fastmcp are optional extras (pip install sigil-ta[mcp], pip install sigil-ta[dashboard]).

Indicators return list[float | None] aligned to input length. This is unfashionable. Most libraries return numpy arrays with NaN warmup or pandas Series with index alignment. I find lists with explicit None more debuggable — when something's wrong, you can see exactly which bars are warmup and which are data.

Test coverage is the contract. 47 tests at v0.1, including:

Constant-input behavior for every indicator
Monotone-up RSI = 100, monotone-down = 0
Stochastic at top of range = 100, at bottom = 0
Bollinger Bands widen with volatility
ATR converges on constant range
Supertrend direction flips on trend reversal
Backtest harness handles long-only, short-allowed, fee accounting
All MCP tools register correctly

git clone https://github.com/LuciferForge/sigil
cd sigil
pip install -e ".[dev,mcp]"
pytest tests/ -v
# 47 passed in 3.18s

What's next

v0.1 ships today with the core indicators + composite signals + PSD + backtest + MCP + dashboard. Roadmap:

v0.2 — More indicators: ADX, Ichimoku, OBV, VWAP, Heikin-Ashi
v0.3 — Walk-forward backtest with parameter sweeps
v0.4 — Multi-timeframe signal fusion (15m + 1h + 4h alignment in one decision)
v0.5 — Live signal alerting (Discord / Telegram / Slack)
v0.6 — Public ground-truth ledger at signals.protodex.io

If there's an indicator you'd use and don't see, open an issue — happy to prioritize.

Why ship this open source

I run a Polymarket trading bot (308 trades, 80.2% WR, all data public). I needed a TA library to ask "should I add an RSI filter to the entry signal?" and didn't want to wrap an existing library that has 50+ dependencies and 5,000 lines of pandas magic.

So I built the simplest thing that worked. Then I made it MCP-native because that's how I do all my analysis now. Then I added PSD because that's the part that's actually mine.

Open-sourcing it isn't charity. The TA logic isn't the moat — the moat is the integration with Polymarket data, and that data layer is also what I sell access to via api.protodex.io. If you want indicators on stocks or crypto, Sigil works fine standalone; if you want PSD on prediction markets, you need the Polymarket data, and that's where the funnel is.

But honestly, even if there were no funnel — building a TA library this clean was satisfying enough that the time would have been worth it for me alone.

Resources

Repo: github.com/LuciferForge/sigil
PyPI: pypi.org/project/sigil-ta (pip install sigil-ta)
MCP-only install: pip install sigil-ta[mcp]
Dashboard install: pip install sigil-ta[dashboard]
Tests: git clone && pip install -e ".[dev,mcp]" && pytest

If you ship a project on top of Sigil, send me the link.

LuciferForge runs a public-audited Polymarket trading bot, protodex.io (5,800+ MCP servers indexed), and the free Polymarket data API.

I Shipped 6 Polymarket / Trading-Bot Tools Today — Here's What Each Does

manja316 — Tue, 28 Apr 2026 15:56:10 +0000

I run a Polymarket crash-recovery bot (308 closed trades, 80.2% WR, all data public). Polymarket migrated from V1 to V2 contracts today. While doing the migration on my own bot, I extracted six tools that solve problems any prediction-market or trading-bot operator runs into. All MIT, all on PyPI / GitHub / HuggingFace, all tested, all verified shipped.

If you're running a Polymarket bot, you probably need 2-3 of these. If you're researching prediction markets, you definitely need the dataset. If you use Claude / Cursor / Cline for analysis, the MCP servers will make your life easier.

Here's the entire stack in one place:

Project	What it does	Install / Use
polymarket-mcp-pro	Polymarket data as MCP tools for Claude / Cursor / Cline	`pip install polymarket-mcp-pro`
polymarket-v2-migration	Cookbook + 12 errors from today's V1→V2 cutover	`git clone …`
pnl-truthteller	Audit your bot's actual on-chain P&L vs DB-recorded	`pip install pnl-truthteller`
cross-signal-data	308-trade labeled crash-recovery dataset + baseline notebook	`pip install cross-signal-data`
quant-rollout	Staged-deployment toolkit (gates, kill switch, veto window)	`pip install quant-rollout`
sigil-ta	MCP-native TA runtime with the unique Polymarket Sentiment Divergence	`pip install sigil-ta`

Total tests across all 6: 95. All passing. Every claim in this post verifiable in 30 seconds via pip install + a one-liner.

1. polymarket-mcp-pro — Polymarket data as Claude/Cursor tools

pip install polymarket-mcp-pro

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "polymarket": {
      "command": "uvx",
      "args": ["--from", "polymarket-mcp-pro", "polymarket-mcp"]
    }
  }
}

Then ask Claude:

"What are the highest-volume Polymarket markets right now?"
"Which markets crashed >20% in the last 24 hours?"
"Show me the full order book for [token]."

Seven tools (list_markets, get_market, get_prices, get_crashes, get_categories, get_orderbook, get_stats). Backed by api.protodex.io which indexes 9,500+ markets with a price snapshot every 15 minutes.

This is how I do all my Polymarket research now. The agent calls the tools, I look at the result, ask follow-ups. No manual curl | jq chains.

Repo: github.com/LuciferForge/polymarket-mcp

2. polymarket-v2-migration — the cookbook for today's cutover

If you have a bot still 503-ing after today's cutover:

The fix is two import rewrites and one kwarg rename. The cookbook has the diff.
The wallet migration HAS to be done in the Polymarket UI with a ≥5-share trade. SDK methods do NOT trigger it. I tested every alternative.
The "1 hour cutover" announcement was wrong; actual was 6 hours of mixed states.

The cookbook is documentation-only — examples, timeline, allowance details, 12 specific errors with fixes, and a smoke test that verifies whether your wallet is migrated and your SDK is V2-ready.

Repo: github.com/LuciferForge/polymarket-v2-migration

3. pnl-truthteller — find your bot's hidden slippage cost

pip install pnl-truthteller
pnl-truthteller --wallet 0xYourProxyAddress

Read-only. Wallet address only. No private key, no API key.

The story: my bot's DB said +$33 lifetime profit. The chain said -$89. Difference: -$122 of hidden slippage cost across 308 trades that the bot literally couldn't see because it records P&L when orders are placed, not when they fill.

The tool reconciles each closed trade against on-chain fills (deduplicated by orderID — critical, because sweep retries log the same fill multiple times in your local DB). Outputs a Markdown report with by-exit-reason breakdown, worst-10 trades, and dust shares stranded on-chain.

Most Polymarket bot operators have never done this audit. If you're one of them, do it once. Worst case you confirm you're profitable. Best case you find the same gap I did.

Repo: github.com/LuciferForge/pnl-truthteller

4. cross-signal-data — the 308-trade labeled dataset

from cross_signal_data import load
df = load()                          # pandas DataFrame, 308 rows, 19 cols
print(df["is_profitable"].mean())    # 0.802

This is the actual labeled outcomes of every closed trade from my bot — entry features, exit features, timestamps, P&L, exit reason. 19 columns, 308 rows.

Trained a logistic regression and a random forest on it: 79.9% CV accuracy from 7 simple features. Translation: the trigger filter is doing 100% of the work. If you can beat 80% with feature engineering, you've found something the bot doesn't know.

License: MIT for both code and data. Mirrored on HuggingFace at huggingface.co/datasets/LuciferForge/cross-signal-data.

Repo: github.com/LuciferForge/cross-signal-data

5. quant-rollout — staged deployment for trading bots

pip install quant-rollout

You changed a bot parameter. Did it actually help, or are you about to lose money?

quant-rollout adds canary → 10% → 50% → 100% rollouts to any bot. Per-stage gates (n trades + win rate + EV/$). Kill switch on losing streaks. Veto window for human override. Persistent state across restarts. Pure stdlib. Zero deps.

Pure decision logic — the library returns RolloutDecision objects, your code applies the config swap. This makes it trivially testable (no Telegram, no real bot, no actual config files in the test path).

26 tests including end-to-end state machine simulation walking through every transition (NOOP → VETO_OPEN → VETO_EXPIRED → KILL_TRIPPED → recovery).

I extracted this from my own bot's stage-tracker after running 3 successful parameter rollouts in 14 days. Drop-in for any trading bot you have.

Repo: github.com/LuciferForge/quant-rollout

6. sigil-ta — MCP-native TA library

pip install sigil-ta              # core, no deps
pip install sigil-ta[mcp]         # add Claude/Cursor tools
pip install sigil-ta[dashboard]   # add Streamlit dashboard

8 core indicators (SMA, EMA, RSI, MACD, BB, ATR, Supertrend, Stochastic) + 2 composite signals (ReversionScore, MomentumComposite) + the unique Polymarket Sentiment Divergence (PSD).

PSD measures divergence between an asset's price action and the resolved sentiment of a related Polymarket prediction market. Pure-TA libraries (ta-lib, pandas-ta, LuxAlgo) cannot compute this because they have no prediction-market data. Sigil includes the Polymarket fetcher so the integration is built in.

14 MCP tools. Pure stdlib indicator core (no numpy required). Backtest harness with realistic fees and no look-ahead. 47 tests.

Repo: github.com/LuciferForge/sigil

Why ship all 6 at once

I had two options:

Option A: Ship one project at a time over six weeks. More posts, more chances at front-pages, more sequential momentum.

Option B: Ship all six on the day Polymarket V2 cutover happens, when there's a forced demand spike.

Option B turned out to be obvious in hindsight. Today, every Polymarket bot operator on the planet is searching for "polymarket v2 migration" or "polymarket bot 503 error" or some variant. They land on my cookbook. From the cookbook, they discover pnl-truthteller (which solves the slippage problem they didn't know they had). From there, the dataset, the rollout toolkit, the TA library.

The whole stack reinforces itself. The bot validates the dataset. The dataset validates the trigger logic. The audit tool validates the bot's claimed numbers. The MCP server lets you query the data with Claude. The TA library gives you the indicator stack to do your own analysis. Everything cross-references.

This is the kind of thing that's only possible because I built it all for myself first. I didn't sit down to "create a portfolio." I had a bot. I needed tools. I built tools. They ended up being independently useful so I'm shipping them.

How I built six things in one day

I didn't, exactly. I built them over the past couple months for my own bot. Today was just the day I cleaned them up, wrote tests, made them pip-installable, and pushed them.

The pattern that worked:

Start from a real problem. Every one of these tools was built to solve a thing I was hitting in operations. Not "this seems useful," not "this would be a good open-source project." Real-pain-now-fix-it.
Write the test first when possible. All 6 repos have meaningful test coverage (95 tests total across the stack). The tests caught real bugs during cleanup — RSI returning 100 on constant input (should be 50), kill switch evaluating wrong trade slice, etc.
Verify before claiming. I have a rule with myself: if I say "shipped," it means I've:
- Run the tests
- Built the wheel
- Installed it in a fresh venv
- Imported it
- Run the smoke test from the CLI
- Confirmed the GitHub repo exists with the expected commits This rule caught a sub-agent's false claim about a missing GitHub repo today. Without it, distribution would have rested on a phantom dependency.
Optimize for the second user, not the first. I'm the first user; I already know how to use these. The README, the CLI, the error messages, the example configs — all of those exist for the second person. If I can't read my own README and figure out how to install the package without context, neither can anyone else.

The honest accounting

I'm not pretending this is a $1M ARR business. It isn't. It's six tools, a public bot, a free API, and an MCP server index (protodex.io) — all running on roughly $200 of personal capital, all open source, all run by one person.

What I'm betting on: the surface area of the stack is the moat, not any single tool. If you're building on Polymarket, you need data (api.protodex.io), you need the SDK done right (polymarket-v2-migration cookbook), you need the audit (pnl-truthteller), you need the labeled examples (cross-signal-data), you need the rollout discipline (quant-rollout), you need the TA stack (sigil-ta), and you need an MCP server to wire it all into your AI tools (polymarket-mcp-pro).

I shipped all seven things. The market will tell me which are right.

Resources

All 6 repos under one org: github.com/LuciferForge
Bot itself (open source): github.com/LuciferForge/polymarket-crash-bot
Free Polymarket data API: api.protodex.io
MCP server index: protodex.io

If you build something on top of any of these, send me the link. If you find a bug, open an issue.

Built in public by LuciferForge, a solo operator running a Polymarket trading bot and the protodex.io infrastructure.

Polymarket V2 Migration: What I Actually Hit Migrating a Live Bot Today

manja316 — Tue, 28 Apr 2026 15:56:05 +0000

If you run a trading bot against Polymarket's CLOB, today's V2 cutover broke it. I migrated my live crash-recovery bot (308 closed trades, 80.2% WR) in 4 hours during the cutover window. This post is exactly what I observed — not what the announcement said, but what actually happened on the wire.

There's a companion repo with the working code, line-by-line diffs, and a smoke test you can run in 30 seconds: github.com/LuciferForge/polymarket-v2-migration

Reading this without checking the cookbook is fine. Running a live bot through the cutover without the cookbook is how you lose hours.

The headline you missed

Polymarket announced a 1-hour V2 cutover. The actual disruption was ~6 hours of mixed states, not 1. If your bot was running during the window and you were retrying every 30 seconds, you logged a few hundred 503s for nothing. Here's what those 6 hours looked like, hour by hour:

Time (UTC)	State	What worked	What didn't
11:00	Cutover begins	Reads (orderbook, balance, positions)	New orders → HTTP 503 cancel-only
11:00–13:00	Pure cancel-only	Cancels of pre-existing V1 orders	Anything that posts a new order
13:00–14:30	V2 contracts active, V1 SDK confused	Migrated wallets via UI	V1 SDK paths still 503-ing
14:30–16:00	Mixed state	V2 SDK + migrated wallets	V1 SDK; un-migrated V2 wallets (allowance errors)
16:00 →	Stable V2	Everything	Anyone still on V1 imports

The bot saw HTTP 503: Trading is currently cancel-only for the entire window. Nothing about that error tells you it'll last 6 hours. Polling the are-orders-scoring flag wouldn't have helped either — the right behavior is "pause, walk away, resume when V2 is up".

What actually changed (it's not a version bump)

The V2 migration is a new SDK package, not a pip install --upgrade. Polymarket shipped V2 as a parallel package so bots could be migrated incrementally rather than via big-bang upgrade.

pip install py-clob-client-v2   # V2 SDK
# Don't uninstall py-clob-client yet — keep it for rollback

Three changes in your code. That's it:

- from py_clob_client.client import ClobClient
- from py_clob_client.clob_types import (
+ from py_clob_client_v2.client import ClobClient
+ from py_clob_client_v2.clob_types import (
      ApiCreds, BalanceAllowanceParams, AssetType, MarketOrderArgs,
  )
- from py_clob_client.constants import POLYGON
+ from py_clob_client_v2.constants import POLYGON
  ...
- return client.post_order(signed_order, orderType="FOK")
+ return client.post_order(signed_order, order_type="FOK")

Two import rewrites and one kwarg rename (orderType → order_type, snake_case in V2). If you forget the kwarg rename, you get a loud TypeError: post_order() got an unexpected keyword argument 'orderType'. Loud errors are mercy.

Contract addresses (changed) and the only way to migrate your wallet

V2 ships with new contract addresses. The SDK has them baked in, but your wallet's allowances are not auto-migrated.

Contract	V1	V2
CTF Exchange	`0x4bFb41d5B3570DeFd03C39a9A4D8dE6Bd8B8982E`	`0xE111180000d2663C0091e4f400237545B87B996B`
NegRisk Exchange	`0xC5d563A36AE78145C45a50134d48A1215220f80a`	`0xe2222d279d744050d28e00520010520000310F59`
Collateral	USDC.e	pUSD (1:1 backed by USDC.e)
CTF (token framework)	unchanged	unchanged

Important: the only way to trigger your wallet's V2 migration is to manually trade ≥5 shares in the Polymarket UI. I tried each of the SDK methods first because the docs hinted they might work. They don't:

❌ update_balance_allowance() from the SDK — only refreshes the SDK's view of existing allowances.
❌ Manually approving the V2 contracts on Polygonscan — Polymarket also requires the pUSD wrapper signature, which only happens in the UI flow.
❌ Logging into polymarket.com without trading — login alone does not trigger the migration prompt.
❌ Trading <5 shares — Polymarket gates the migration prompt behind a minimum.

The only thing that works: go to polymarket.com, click Trade on any market, set size to ≥5 shares, sign all 3 wallet signatures (USDC.e → pUSD wrap, V2 CTF allowance, V2 NegRisk allowance). Costs about 0.1 MATIC in gas. Takes 60 seconds.

After that, your wallet has V2 allowances and the V2 SDK works. Until then, you'll get HTTP 400: insufficient allowance for V2 CTF Exchange.

If you operate multiple proxy wallets, each one has to do its own UI flow. There is no batched migration.

What I actually did, in order

Time (UTC)	Action	Result
11:05	Detected first 503. Paused bot via `MAX_ENTRY_PRICE = 0.0` config flag.	Bot stopped firing buys; existing positions kept being monitored.
11:30	Read V2 announcement + SDK release notes.	Confirmed import + kwarg changes.
12:00	`pip install py-clob-client-v2`. Did NOT uninstall V1.	Both SDKs available; rollback path preserved.
12:15	`sed -i '' 's\	from py_clob_client.\
12:20	{% raw %}`sed -i '' 's\	orderType="FOK"\
12:30	Smoke test: {% raw %}`python -c "from py_clob_client_v2.client import ClobClient; print('ok')"`	Pass.
12:45	Opened polymarket.com, traded 5 shares on a small market, signed migration approvals.	~$0.01 in MATIC gas. Wallet now holds pUSD; V2 allowances appeared in `get_balance_allowance` response.
13:00	Manually posted a 1-share order via my updated bot to verify V2 path.	Order filled on-chain.
14:00	Resumed bot at half-size (`POSITION_SIZE_USD = 5.0` instead of 10).	First 3 orders went through cleanly.
17:00	Confirmed 6h of clean operation.	Returned to normal POSITION_SIZE.

Total wall time: ~4 hours of focus, plus passive waiting for V2 to stabilize.

The 12 errors I hit (with fixes)

The cookbook's troubleshooting guide has all 12 with exact fixes. The most common ones:

ModuleNotFoundError: No module named 'py_clob_client_v2' → pip install py-clob-client-v2 into the right venv. If you use launchd or systemd, double-check the interpreter path.
TypeError: post_order() got an unexpected keyword argument 'orderType' → grep for orderType= and replace with order_type=.
HTTP 503: Trading is currently cancel-only → Polymarket-side maintenance. Pause your bot, wait. Don't retry-storm.
HTTP 400: insufficient allowance for V2 CTF Exchange → wallet not migrated. Go to polymarket.com and trade 5 shares.
Decimal precision mismatch on amount → V2 is stricter. Wrap your amount in round(amount_usd, 2).
Order accepted but never settles on-chain → your wallet has no pUSD balance. The migration trade wraps USDC.e to pUSD; if you skipped that step, accepts will fail at settlement.

The full list with code is in docs/troubleshooting.md of the cookbook repo.

The slippage problem V2 doesn't fix

If your bot used a price-discount ladder (e.g., 5%, 15%, 25% below ref price) for TIMEOUT exits on thin markets, V2 doesn't fix that. V2 fixes nonce-related failed-fill bugs in the matching layer — it doesn't change order-book depth.

I ran a separate audit on my bot's lifetime P&L vs. on-chain fills using a tool I open-sourced today: pnl-truthteller. Result:

Lifetime theoretical P&L:  +$33.49
Lifetime actual P&L:       -$89.01
Total slippage cost:       -$122.50  (-365.8% of theoretical)

That's 302 closed trades, 4-5 months of operation, and the difference between "I'm slightly profitable" and "I'm clearly not, and I should change the exit ladder." If you've never run that reconciliation against your bot's records, you don't know what you're really making.

pip install pnl-truthteller
pnl-truthteller --wallet 0xYourProxyAddress

Read-only, wallet address only, no API key. Outputs a Markdown report with by-exit-reason breakdown, worst-10 trades, and dust shares stranded on-chain.

The deeper lesson: V2 wasn't really about V2

Every DeFi protocol upgrade exposes which bots are well-coupled to the protocol's own SDK abstractions and which ones have hardcoded addresses, hardcoded version assumptions, or naive retry loops.

What V2 actually tested:

Whether your bot detects cancel-only mode cleanly (most don't)
Whether you have a kill switch that pauses the bot on first sign of a system-wide error (most don't)
Whether your slippage cost is being measured against on-chain reality or against your own DB optimism (most aren't)

If any of those answers were "no", today is the day to fix them. I open-sourced three things that handle exactly these failure modes:

polymarket-v2-migration — the cookbook for this specific cutover. 12 errors with fixes, smoke test, hour-by-hour timeline.
pnl-truthteller — fill-level P&L audit. Find your hidden slippage. (pip install pnl-truthteller)
quant-rollout — staged-deployment toolkit with kill switch and veto window. Stops you from shipping bad params into production. (pip install quant-rollout)

All MIT, all zero-dep cores, all PyPI-published. If they save you a few hours over the next week, star them.

Resources

Bot source: github.com/LuciferForge/polymarket-crash-bot — the same bot that ran through today's migration
V2 cookbook: github.com/LuciferForge/polymarket-v2-migration
Smoke test: clone the cookbook and run python tests/test_v2_imports.py against your env. Tells you whether your wallet is migrated and your SDK is V2-ready.
Free Polymarket data API: api.protodex.io — 9,500+ markets, no key required for basic access
Labeled crash-recovery dataset (free): github.com/LuciferForge/cross-signal-data — 308 trades, 80.2% WR, real markets. pip install cross-signal-data.

If your bot is still 503-ing right now, the cookbook tells you whether it's the SDK or your wallet allowances. If it's silent, run pnl-truthteller. The chain is the source of truth.

LuciferForge is a solo operator running a public-audited Polymarket trading bot. Also runs protodex.io (5,800+ MCP servers indexed) and the free Polymarket data API.

We Index 2,013 MCP Servers and Security-Score Every One — Here's What We Found

manja316 — Sat, 18 Apr 2026 03:32:11 +0000

There are over 40,000 MCP server repositories on GitHub right now. That number was 5,000 six months ago.

The Model Context Protocol is eating the AI tooling world — but nobody is checking whether these servers are safe to run. We built Protodex to fix that.

The Problem

When you install an MCP server, you're giving it access to your filesystem, your APIs, your databases, and your shell. The @modelcontextprotocol/sdk makes it trivially easy to build a server. The result: thousands of servers published by developers who never thought about security.

We know this because we've been scanning them. Out of the 2,013 servers we've indexed, we found vulnerabilities serious enough to file bounty reports — and $4,725 has been confirmed for payout.

What Protodex Does

Protodex.io is a searchable directory of 2,013 MCP servers across 13 categories:

Category	Servers	Examples
AI/LLM	974	Claude integrations, embedding servers, agent frameworks
Code/Dev Tools	224	GitHub, GitLab, Jira, IDE integrations
API Integration	116	Slack, Discord, Stripe, Twilio connectors
Memory/Knowledge	111	RAG servers, knowledge graphs, note-taking
Database	87	Postgres, MongoDB, Redis, Supabase MCP
Security	67	Vulnerability scanners, auth servers
Browser/Web	58	Playwright, puppeteer, web scrapers

Every server listing shows:

Source repository and stars
Language and last update
Category and description
Security indicators (this is what makes us different)

How We Built It

The architecture is simple by design:

Scraper — 25 GitHub search queries run weekly, catching new MCP servers across Python, TypeScript, Go, Rust, Java, and C#
Categorizer — keyword-based classification into 13 categories
Static site generator — builds 2,000+ HTML pages with per-server detail pages
Auto-deploy — git push to GitHub Pages every Monday at 6 AM
Security scanner — runs mcp-security-audit on indexed servers

The entire pipeline runs unattended. Zero manual work after setup.

What We Found Scanning MCP Servers

When we audited servers from the official Anthropic and community collections, we found:

SSRF vulnerabilities in servers that fetch URLs without validation
Path traversal in file-serving MCP servers
SQL injection in database MCP servers that pass user input to queries
Command injection in servers that shell out to system commands
Pickle deserialization in ML model servers

These aren't theoretical. We filed reports with Huntr and MSRC. $4,725 has been confirmed for the first batch, with 74+ additional findings in the pipeline.

The typical pattern: a developer builds an MCP server to solve their problem, publishes it to GitHub, and never thinks about what happens when the input comes from an untrusted source. But MCP servers receive prompts that could contain anything — including attack payloads.

Why Not Just Use mcp.so or Smithery?

Fair question. Here's the honest comparison:

Feature	mcp.so	Smithery	Protodex
Backed by	Anthropic	VC-funded	Independent
Server count	~200 curated	~500	2,013
Security scores	No	No	Yes
Open source	No	No	Yes
Auto-updates	Unknown	Unknown	Weekly (GitHub scraper)
Vulnerability research	No	No	$4,725 in bounties

Our moat is security. Nobody else scans MCP servers for vulnerabilities and publishes the results. We use our own tools (ai-injection-guard, mcp-security-audit) to do the analysis.

The Auto-Refresh Pipeline

Every Monday at 6 AM, a launchd job:

Runs 25 GitHub search queries for new MCP servers
Indexes new servers into a SQLite database
Categorizes them by keyword matching
Exports to JSON
Builds 2,000+ static HTML pages
Git pushes to GitHub Pages
Sends a Telegram notification with the count

The pipeline has been running since March. We went from 1,629 servers to 2,013 in the last refresh — 384 new servers discovered in one week.

Use Protodex

Browse: protodex.io — search by keyword, filter by category
Contribute: GitHub repo — open source, PRs welcome
Security: Found a vulnerable MCP server? Email LuciferForge@proton.me

We also maintain a Polymarket historical dataset (8.9M data points) and AI security tools on PyPI.

Protodex is built by LuciferForge — an independent security research lab focused on AI agent safety.

84% of Polymarket Traders Lose Money — I Backtested 6,225 Trades to Find What Actually Works

manja316 — Sat, 18 Apr 2026 03:32:07 +0000

A study of 2.5 million wallets found that 84% of Polymarket traders lose money. But nobody asks the obvious question: what are the 16% doing differently?

I backtested 6,225 trades on 30 days of real data to find out.

The Losing Strategy: Bet on Outcomes

Most Polymarket users bet like this: "I think Trump will win, so I'll buy YES at $0.55."

This is gambling with extra steps. You're predicting the future — and prediction is hard. The house (the market) usually prices things roughly right, so your edge is near zero.

The data shows this clearly. Across 9,550 markets I tracked for 30 days, the average price change between snapshots was -0.002%. Essentially random noise. If you buy randomly and hold, you lose to fees.

The Winning Strategy: Bet on Price Patterns

The 16% who win aren't smarter about geopolitics or sports. They exploit a structural pattern: markets overreact to bad news and self-correct within hours.

Here's the pattern from 5,629 crash events in my dataset:

After a >20% price drop:
  +15 min:  +6.6% average bounce
  +30 min:  +8.8% average bounce
  +45 min: +10.3% average bounce
  +1 hour: +11.0% average bounce

This isn't theoretical. It's measured across every category — politics, sports, crypto, geopolitics — over 30 continuous days.

The Backtest: 6,225 Simulated Trades

Strategy rules:

Entry: Buy when a market drops >15% from its rolling 1-hour high
Exit: Sell when price recovers to 90% of pre-crash level
Timeout: Force exit after 12 hours if no recovery
Size: $1 per trade

Results:

Metric	Value
Total trades	6,225
Win rate	75%
Recovery exits	4,388 (71%) — avg hold 4.1 hours
Timeout exits	1,790 (29%) — avg hold 24 hours
Total P&L	+$135 per $1 risked

The key insight: 71% of trades recover within the first few hours. The ones that don't are the timeouts — and they're the only source of losses.

What The Data Says About Hold Time

This was the most surprising finding. I ran the same strategy with different maximum hold periods:

Max Hold	Win Rate	P&L	Capital Efficiency
2 hours	54%	$87	Highest throughput
6 hours	64%	$108	Good balance
12 hours	70%	$121	Optimal
24 hours	75%	$135	Diminishing returns
48 hours	81%	$142	Capital trap

Going from 12 to 48 hours only adds $21 but locks your capital 4x longer. The smart money exits fast.

Categories Are Not Equal

If you're going to trade crashes, pick your battlefield:

Category	Win Rate	P&L Per Trade
Crypto	78%	$0.030
Sports	79%	$0.027
Other	75%	$0.024
Politics	76%	$0.018
Geopolitics	71%	$0.016
~~Economics~~	69%	$0.008
~~Weather~~	57%	Negative

Crypto and sports markets mean-revert the hardest. Economics and weather markets crash and stay crashed — the "bad news" in those categories usually reflects real fundamental changes.

Why This Works (And Why Most People Miss It)

Prediction markets have a structural inefficiency: emotional overreaction followed by rational correction.

When a political scandal breaks, YES holders panic-sell and the price drops 30% in minutes. But most scandals don't actually change the outcome probability by 30%. So the price drifts back.

Professional market makers know this. They provide liquidity during crashes and profit from the bounce. This strategy is essentially doing the same thing — buying the panic, selling the recovery.

The 84% who lose are betting on outcomes (Will X happen?). The 16% who win are betting on price behavior (Will this crash recover?). Same market, different game.

Reproduce This Yourself

The full dataset is available:

Kaggle — free, includes full SQLite DB with 8.9M data points
HuggingFace — free sample
GitHub — browse and star

Load it in Python:

import sqlite3
import pandas as pd

conn = sqlite3.connect("market_universe.db")
prices = pd.read_sql("SELECT * FROM prices WHERE outcome = 'Yes'", conn)
print(f"{len(prices):,} price snapshots loaded")

# Find crash events
prices['prev'] = prices.groupby('market_id')['price'].shift(1)
prices['change'] = (prices['price'] - prices['prev']) / prices['prev']
crashes = prices[prices['change'] < -0.15]
print(f"{len(crashes):,} crash events found")

For the full dataset with orderbook depth (792K snapshots): Gumroad ($9)

Data collected March 18 — April 17, 2026 using an automated pipeline. 9,550 markets, 8.1M price snapshots, 15-minute intervals. Source: protodex.io

I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move

manja316 — Fri, 17 Apr 2026 18:21:55 +0000

Everyone says prediction markets are efficient. I spent 30 days collecting data to test that claim.

The result: 8.9 million data points across 9,550 markets — and the data tells a story most traders miss completely.

The Setup

I built an automated collector that snapshots every active Polymarket market every 15 minutes. Not just BTC or the US election — every market. Politics, sports, crypto, geopolitics, economics, entertainment, weather, science. All of it.

After 30 days of continuous collection:

Metric	Value
Markets tracked	9,550
Price snapshots	8,158,672
Orderbook depth snapshots	792,527
Categories	10
Total data points	8,951,199

Most Polymarket datasets you'll find cover a single market or a single event. This covers the entire platform simultaneously — which lets you see patterns that single-market analysis can't.

Finding #1: Markets Are Not Efficient After Crashes

Everyone assumes prediction markets instantly price in new information. The data says otherwise.

I measured what happens after a price drops more than 20% between consecutive snapshots. Here's what the 5,629 crash events show:

Time After Crash	Average Return	Events Measured
+15 min	+6.6%	5,629
+30 min	+8.8%	5,629
+45 min	+10.3%	5,629
+1 hour	+11.0%	5,629

After a >20% crash, prices bounce back an average of 6.6% within 15 minutes.

This is classic mean reversion — and it's massive. For comparison, the S&P 500's average annual return is about 10%. These markets deliver that in an hour after a crash.

The reverse is also true. After a >10% pump:

Time After Pump	Average Return
+15 min	-2.9%
+30 min	-3.7%

Prices that spike tend to give it back. Markets overreact in both directions.

Finding #2: Hold Time Matters More Than Entry Price

I simulated the obvious strategy — buy the crash, sell the recovery — across all 30 days of data. 6,225 trades. Here's how hold time affects the result:

Max Hold	Trades	Win Rate	Total P&L
2 hours	10,204	54%	$87
6 hours	8,324	64%	$108
12 hours	7,295	70%	$121
24 hours	6,225	75%	$135
48 hours	5,352	81%	$142

The sweet spot is 12 hours. Going from 12h to 48h only adds $21 to total P&L but locks your capital 4x longer. Most of the money is made in the first few hours.

This surprised me. I expected entry price to be the key variable. It's not:

Entry Price Range	Win Rate	Avg P&L Per Trade
Under $0.10	74%	$0.014
$0.10 — $0.30	74%	$0.018
$0.30 — $0.50	79%	$0.032
Above $0.50	86%	$0.022

Higher-priced markets actually have better win rates. The cheap ones look tempting but they include more dust trades that go nowhere.

Finding #3: Category Is Your Edge Selector

Not all Polymarket categories behave the same:

Category	Trades	Win Rate	P&L Per Trade	Verdict
Crypto	646	78%	$0.030	Best per-trade
Sports	1,050	79%	$0.027	Most consistent
Other	1,872	75%	$0.024	Most volume
Politics	1,362	76%	$0.018	Decent
Geopolitics	890	71%	$0.016	Below average
Economics	101	69%	$0.008	Avoid
Weather	21	57%	Negative	Avoid

Crypto and sports markets have the strongest mean reversion. Economics and weather markets are traps — they crash and stay crashed.

Why? Sports and crypto have event-driven resolution (the game happens, the price discovers). Economics markets depend on slow-moving indicators — when they crash, it's often because the fundamentals actually changed.

Finding #4: The "Always Bet No" Strategy Is Overhyped

You may have seen the "Nothing Ever Happens" bot that bets NO on everything. The claim: 73% of Polymarket resolves NO.

I checked with 4,763 resolved binary markets from the API:

All markets: 52.3% resolve NO (not 73%)
Non-sports: 57%
"Will X happen?" framing: 59.3%

The 73% figure comes from a heavily filtered subset. Across all markets, the NO edge is barely there — and at typical NO prices ($0.65-0.85), the math doesn't work.

The Dataset Is Free to Explore

I'm releasing the full dataset across multiple platforms:

Free (sample):

Kaggle — markets.csv + 100K price preview + full SQLite DB
HuggingFace — same files, HF ecosystem integration
GitHub — browse the data, star if useful

Full dataset ($9):

Gumroad — 8.9M data points, orderbook depth, SQLite DB

The data updates weekly from an automated pipeline. If you want to reproduce any of these findings, everything is there.

What I'd Build Next

If I were starting a Polymarket quant project today, I'd focus on:

Real-time crash detection — the 6.6% bounce after crashes is the clearest edge
Category rotation — crypto and sports, skip economics and weather
12-hour max hold — the data is unambiguous on this
Cross-market signals — does a crash in one political market predict crashes in related ones?

The prediction market space is where crypto was in 2017 — growing fast, most participants losing money, and the edge goes to people with data infrastructure.

The data was collected from Polymarket's Gamma API and CLOB API using an automated pipeline. All code and methodology are open source. I also maintain protodex.io, an index of 2,013 MCP servers with security scores.

Questions or want custom data cuts? LuciferForge@proton.me

How to Use Context7 MCP Server — Up-to-Date Docs for Every Library in Your AI Editor

manja316 — Thu, 16 Apr 2026 16:16:51 +0000

Every AI coding assistant has the same problem: stale training data. You ask Claude to help with Next.js 15 and it gives you Next.js 13 patterns. You ask about the latest Prisma syntax and get deprecated methods.

Context7 fixes this. It's an MCP server that pulls live documentation for any library, directly into your AI editor's context window. 49.9K stars on GitHub. Here's how to set it up in under 2 minutes.

What Context7 Actually Does

When you're coding with Claude Code, Cursor, or Claude Desktop and mention a library, Context7 fetches the current docs and code examples for that library. Not cached training data from 2024 — the actual docs from today.

It works with any library that has documentation indexed: React, Next.js, Prisma, FastAPI, LangChain, Supabase — thousands of libraries.

Setup: Claude Desktop

Add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp@latest"]
    }
  }
}

Restart Claude Desktop. Done.

Setup: Claude Code

One command:

claude mcp add context7 npx -y @upstash/context7-mcp@latest

Setup: Cursor

Add to .cursor/mcp.json:

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp@latest"]
    }
  }
}

Setup: Goose and Other MCP Editors

Context7 works with any MCP-compatible editor. For Goose, Windsurf, Zed, and others, add the Context7 server using your editor's MCP configuration. The server command is the same: npx -y @upstash/context7-mcp@latest

How to Use It

Once installed, just add "use context7" to your prompt when you need current docs:

"Create a Next.js 15 server component with streaming, use context7 for the latest patterns"

Context7 will pull the current Next.js docs and feed them into the AI's context. No more outdated patterns.

When It Saves You

New library versions — Framework just released a major update? Context7 has it.
Migration guides — Moving from one version to another? Get the actual migration docs, not guessed changes.
Niche libraries — Working with a library the AI wasn't trained on? Context7 can still fetch its docs.

Alternatives

There are other documentation MCP servers worth knowing:

Grounded Docs — open source alternative focused on offline caching
Zed MCP Context7 — Context7 integration specifically for Zed editor

Browse all documentation MCP servers at Protodex — Memory/Knowledge category.

protodex.io — 5,618 MCP servers with one-click install for Claude Desktop, Cursor, Goose, and more.

Claude Code vs Goose vs nanobot vs pi-mono — Which AI Coding Agent Should You Use?

manja316 — Thu, 16 Apr 2026 16:16:19 +0000

There are now 7+ open-source AI coding agents with 30K+ stars each. I've used all of them on real projects. Here's when each one makes sense.

The Quick Answer

If you want...	Use this
Full-featured + MCP ecosystem	Claude Code
Maximum extensibility	Goose
Understand the source code	nanobot
Multi-provider + self-host	pi-mono
Visual flow building	Flowise
Browser automation	browser-use
Research experiments	autoresearch

Claude Code — The Full-Featured Option

Stars: N/A (Anthropic product)
Best for: Professional daily driving

A full-featured experience. Hooks system for automation, MCP for connecting to anything (5,618 servers on Protodex), skills for extending behavior. It's opinionated — Anthropic chose the defaults so you don't have to.

The catch: Closed source. You're locked into Anthropic's models. Monthly subscription.

Use when: You want a batteries-included agent with deep MCP integration.

Goose — The Extensible One

Stars: 42.3K
Best for: People who want plugins for everything

Block's open-source agent. MCP support, browser built in, extensible plugin system. The community is active and there are plugins for most workflows.

brew install goose

The catch: Heavier than it needs to be. Plugin system adds complexity. Sometimes slow to start.

Use when: You need specific integrations and want community-built extensions.

nanobot — The Minimalist

Stars: 39.7K
Best for: Learning, research, low-resource environments

99% less code than Claude Code. The entire agent is readable in an afternoon. Starts in under a second. No plugins, no marketplace, no config — just an agent loop.

pip install nanobot-ai

The catch: No MCP, no memory, no ecosystem. It does one thing.

Use when: You want to understand how AI agents work, or need something tiny and fast.

pi-mono — The Toolkit

Stars: 36.3K
Best for: Building your own agent products

Not just an agent — a full toolkit. Unified LLM API across OpenAI/Anthropic/Google, agent runtime with state management, TUI library, web components for chat interfaces, and vLLM deployment tools.

git clone https://github.com/badlogic/pi-mono && npm install && npm run build

The catch: More of a framework than a ready-to-use tool. You're building WITH it, not using it.

Use when: You're building an AI product and need the infrastructure, not a personal assistant.

browser-use — The Web Agent

Stars: 88.1K
Best for: Automating anything in a browser

Gives your AI real browser access. Navigate, click, fill forms, extract data. Not a coding agent — a web automation agent.

pip install browser-use

The catch: Browser automation is slow and brittle. Sites change, selectors break.

Use when: Your task requires interacting with websites, not codebases.

Flowise — The Visual Builder

Stars: 52K
Best for: Non-coders who want AI agents

Drag-and-drop agent builder. Connect LLMs, vector stores, tools, and APIs visually. Export as API.

The catch: Visual building has limits. Complex logic gets messy in node graphs.

Use when: You want to prototype agent flows without writing code.

autoresearch — The Scientist

Stars: 73.2K
Best for: ML research automation

Karpathy's project. AI agents that run ML experiments — modify training code, run experiments, analyze results, iterate. Not a general coding agent — a research automation tool.

The catch: Requires GPU infrastructure. Designed for ML training loops specifically.

Use when: You're doing ML research and want to automate the experiment cycle.

Decision Flowchart

Do you write code daily?
├── Yes → Do you want to tinker with the agent?
│   ├── Yes → nanobot (learn) or pi-mono (build)
│   └── No → Claude Code, Cursor, or Goose (MCP ecosystem)
│
└── No → What do you need?
    ├── Browser automation → browser-use
    ├── Visual workflow → Flowise
    ├── ML research → autoresearch
    └── Custom agent product → pi-mono

The Ecosystem Matters

The agent itself is just the core. What makes it useful is what it connects to. The MCP ecosystem (supported by Claude Code, Cursor, Goose, and others) includes 5,618+ servers for databases, APIs, browsers, memory, security, and more.

If you're choosing between agents, check what integrations you need and whether the agent supports them.

→ Browse all MCP servers on Protodex

Protodex — 5,618 MCP servers with security scores and one-click install for Claude Desktop, Cursor, Goose, and more.

nanobot: The 39K-Star AI Agent That Does What Claude Code Does in 99% Less Code

manja316 — Thu, 16 Apr 2026 16:15:33 +0000

nanobot just crossed 39K stars on GitHub. It's from HKU's Data Science lab and it positions itself as the "ultra-lightweight personal AI agent." I spent a day with it to figure out if that claim holds up and when you should use it over Claude Code, Goose, or pi-mono.

What nanobot Actually Is

It's a coding agent — like Claude Code or Cursor's agent mode — but built with 99% fewer lines of code. The entire agent core fits in a few hundred lines of Python. It connects to any LLM provider, reads your codebase, runs terminal commands, and edits files.

The philosophy: strip everything except what matters. No plugin system, no marketplace, no GUI. Just an agent that reads, thinks, and acts.

Install (30 seconds)

# Fastest
uv tool install nanobot-ai

# Or pip
pip install nanobot-ai

# Or from source (latest)
git clone https://github.com/HKUDS/nanobot.git
cd nanobot && pip install -e .

Run it:

nanobot

That's it. No config files. No API key setup wizard. It prompts you for your key on first run.

When to Use nanobot vs Full-Featured Agents

Use nanobot when:

You want something that starts in <1 second (Claude Code takes 3-5s)
You want to read and modify the agent's source code (it's small enough to understand in an afternoon)
You're doing research on AI agents and need a clean base to experiment with
You want a minimal agent on a low-resource machine (CI server, Raspberry Pi, cheap VPS)
You don't need MCP servers, skills, or hooks

Use a full-featured agent (Claude Code, Cursor, Goose) when:

You need the MCP ecosystem (5,600+ servers on Protodex)
You need hooks, plugins, or automated workflows
You want deep model integration with context management
You're working on large codebases where tooling matters

Use Goose when:

You want extensibility with a plugin system
You need browser automation built in
You want community extensions

How nanobot Works Under the Hood

The architecture is dead simple:

User prompt → LLM call → Tool use (file read/write, shell) → LLM response → Loop

No routing, no planners, no multi-agent orchestration. One loop. The LLM decides what to do, does it, reports back. This is why it's fast — there's nothing between you and the model except the tool execution layer.

Limitations (Be Honest)

No MCP support — can't connect to databases, APIs, or browsers through MCP. If you need that, check Protodex for servers that work with any MCP-compatible editor.
No memory across sessions — each run starts fresh. No persistent context.
Small community — compared to full-featured agents' ecosystems, there are fewer templates, guides, and pre-built workflows.
Research project — it's from a university lab. Updates come when researchers have time, not on a product roadmap.

The Verdict

nanobot is the right tool if you value simplicity and transparency over features. You can read every line of its code in a sitting. That makes it perfect for learning how AI agents work, for building custom agents on top of, or for environments where you need something tiny and fast.

If you need the ecosystem, use a full-featured MCP-compatible agent (Claude Code, Cursor, or Goose) with MCP servers. If you want to understand what's happening under the hood, nanobot is the best teacher.

Building with AI agents? Browse 5,618 MCP servers with one-click install for Claude Desktop, Cursor, Goose, and more at protodex.io

Which Database MCP Server Should You Use? I Compared the Top 6

manja316 — Thu, 16 Apr 2026 16:14:51 +0000

Your AI assistant can now query your database directly. No more copy-pasting SQL results into chat. But there are 183 database MCP servers — which one actually works for YOUR stack?

I tested the top 6 across Postgres, MySQL, SQLite, MongoDB, Redis, and Supabase.

Quick Decision Table

Your Database	Use This	Why
PostgreSQL	`@modelcontextprotocol/server-postgres`	Official MCP team. Read-only by default. Stable.
MySQL	`@benborla29/mcp-server-mysql`	Best MySQL support with schema introspection
SQLite	`@modelcontextprotocol/server-sqlite`	Official. Great for local dev + prototyping
MongoDB	`mcp-mongo-server`	Full CRUD with aggregation pipeline support
Redis	`@modelcontextprotocol/server-redis`	Official. Key-value ops + pub/sub
Supabase	`@supabase/mcp-server`	Supabase-specific: auth, storage, edge functions, not just SQL

PostgreSQL — The Safe Default

If you're on Postgres (and most of you are), use the official one:

# Claude Code
claude mcp add postgres npx -y @modelcontextprotocol/server-postgres postgresql://user:pass@localhost/mydb

# For Cursor, add to .cursor/mcp.json. For other MCP editors, use your editor's config.

It connects read-only by default. Your AI can explore schemas, run SELECT queries, and analyze data without risking writes. Perfect for "what does my user_sessions table look like?" or "find all orders over $100 from last week."

When to pick something else: If you need write access or Postgres-specific features (pgvector, PostGIS), look at the specialized servers on Protodex's database category.

Supabase — More Than a Database

If you're on Supabase, don't use the generic Postgres server. The Supabase MCP server understands your whole stack:

# Claude Code
claude mcp add supabase npx -y @supabase/mcp-server

# Works with any MCP-compatible editor (Cursor, Goose, Windsurf, etc.)

It can manage auth users, storage buckets, edge functions, and RLS policies — not just SQL. "Create a new table with RLS for authenticated users" works as one prompt.

SQLite — For Prototyping

Building something locally? SQLite MCP is the fastest way to give your AI a database:

# Claude Code
claude mcp add sqlite npx -y @modelcontextprotocol/server-sqlite /path/to/your.db

# Works with any MCP-compatible editor

Point it at any .db file. Instant data exploration. I use this for analyzing datasets — drop a CSV into SQLite, connect MCP, ask questions.

MongoDB — When Your Data Isn't Relational

# Claude Code
claude mcp add mongo npx -y mcp-mongo-server mongodb://localhost:27017/mydb

# Works with any MCP-compatible editor

Full aggregation pipeline support. "Show me the average order value grouped by country for the last 30 days" translates directly to a Mongo aggregation.

Security Warning

Every database MCP server has your connection string. Before installing any:

Use read-only credentials when possible
Never use production credentials in your MCP config (config files are typically plain text)
Check the security score on Protodex before installing
Prefer official servers (marked ✓ Secure on Protodex) over community ones

All 183 Database MCP Servers

These 6 cover most use cases, but there are specialized servers for: TimescaleDB, ClickHouse, DuckDB, Neo4j, Elasticsearch, Pinecone, Qdrant, Weaviate, and more.

→ Browse all database MCP servers on Protodex

Protodex — 5,618 MCP servers with security scores and one-click install for Claude Desktop, Cursor, Goose, and more.