DEV Community: Manish Kumbham

I tested 748 crypto trading strategies and open-sourced the code and autopsy reports of the corpses

Manish Kumbham — Tue, 03 Nov 2026 22:45:55 +0000

A few weeks ago I wrote hundreds of hypotheses for crypto trading strategies, re-screened every bot from my last post (https://www.reddit.com/r/algotrading/s/dF5qfUNaCa) and open-sourced the whole pile: 748 strategies in total with full code and report cards showing exactly where each one died and why. (That's 416 from last time plus 332 new corpses. The new ones are smarter strategies than before for the most part...)

https://github.com/CacheCarti/Crypto-Strategies

The pipeline runs 7 stages on real Binance data: code safety, in-sample, OOS, rolling walk forward, randomized starts, slippage stress and a holdout slice that nothing touches. Ran it on cloud VMs this time instead of my dying laptop, so the screening could actually get stricter.

What the new pipeline found:

Re-ran the 416 bots from my last post. 0 of 416 re-passed in the strictest config, including all 10 of my "survivors". Most die at out-of-sample with negative OOS (-85 to -900bps). The best one, rel_strength_eth_v3, made it to stage 5 and died at holdout. So my "validated" bots were mostly my old screening being sloppy and luck :)
In the second config (slightly more lenient) exactly 1 of 416 re-passed, and it was a bot I had originally rejected (weekend_season_eth_v6, +325bps OOS). My graveyard had the only bot that actually lived.
The 332 new corpses came from 559 hand-written bots (mixed with another batch, messy to release all at once). 384 screened, 332 dead (published), 52 survived and stay private for further testing. (Yes yes I know 52 is stupidly high, there's a reason for this at the bottom!)
Admits per batch: v2 5/42, v3d 0/26, v3h 0/96, v4 3/92, v5 17/52, v6 18/60, v6b 9/16. v3h went 0 for 96, which tracks, it was basically like a monkey typing random keys, just a sweep of untested ideas. v5-v6b were narrow parameter neighbors of a mechanism that already worked. Please don't read the admit rates as some kind of quality check for the batches!!

Why the rebuild?:

The comments on the last post were right about my sloppy methodology (it still admittedly is sloppy here, but it got better later). It's also built on Google VMs now so I can create a new batch and test faster. I'll drop the batches weekly:

Stricter judge: higher OOS thresholds, enforced holdout and a dev/holdout split inside the window so one lucky slice can't pass
Every report card shows the exact gate that killed the bot, so you can figure out how to improve it
Every batch is hashed so you can check when it was judged and by what
I later added a 6+ year certification and a combined replay on 2.75 years, with DSR, PBO, plateau, regime splits, trial-ledger correction. Those results are still being evaluated, they'll come later.

One disclosure about report cards vs actual performance: I cross-checked some strategies against QuantConnect classics this week and it surfaced a bug I didn't notice. Some bots emit a "flat" signal and my screen sometimes treated it as "hold". Impact is mostly ±100-300bps per strategy, around 25% of bots may fluctuate by that amount. The later stages and live paths honored flat completely.

Yeah so I found a bug in my own judge while checking it against someone else's judge. The judge judges all, including the judge.

If anyone improves the strategies and gets different results I'd love to see it. Happy to add tests people think are missing. Every suggestion so far has killed more of my bots... That's the process now!

(Btw about the 52 admits, I can already see you smirking at my stupidity... I mean I am stupid but there's a reason for such a high admit number, it just means the 52 are accepted into the next stages: correlation testing (less than 10 made it past this)->data testing on 6+ years->combination testing on 2.75 years->live paper trading->live trading possibly.

But most importantly, my standards are deliberately lower!! The experiment I'm trying to conduct is testing a strategy of strategies router. Bots with known gaps can still be considered for entry, because my router should in theory route around these gaps of the bots, smartly. So I'm not only looking for extremely good bots that can one-shot your portfolio I'm also looking for slightly weaker bots to test my router's skill!)

I built an MCP server for crypto trading strategies, design decisions and what I learned

Manish Kumbham — Wed, 26 Aug 2026 21:21:17 +0000

I've been building a crypto trading platform (dMoERA) that runs algorithmic bots on ETH/BTC/SOL pairs. The core problem I kept hitting: the strategy development loop is brutal. You write a bot, manually backtest it, eyeball the results, try 20 variations, repeat. So I wrapped the whole thing in an MCP server and open-sourced the client.

Repo: github.com/CacheCarti/dmoera-mcp
Smithery: smithery.ai/servers/mk9654/dMoERA-Creator

It's not a trading bot. It's not a signal service. It's an MCP interface that lets any MCP-compatible agent (Claude, Cursor, Windsurf, Devin) interact with a running trading platform, discover markets, backtest strategies, submit them for validation, and monitor live performance.

This post is about the design decisions that mattered.

How the strategy contract works

Strategies subclass a Strategy class and implement on_bar(self, ctx) -> Signal. The signal is just:

direction (long/short/flat)
confidence (0-1)
stop_loss_bps
take_profit_bps
horizon_seconds

That's it. The bot never sees leverage, position sizing, or portfolio state, the router handles all of that.

This was a deliberate decision: bots that know their leverage tend to overfit to it. If a bot knows it has 10x, it'll optimize for 10x-specific risk profiles that stop working the moment leverage changes. By isolating the signal from the execution, the same bot can run at 1x for a conservative user and 10x for an aggressive one without changing a single line.

The ctx object gives access to:

OHLCV bars (configurable lookback)
A feature catalog: funding rates, Fear & Greed index, order book imbalance, ATR, RSI, volume profile
Current market regime (trending / ranging / crisis) with a crisis score

All features are pre-computed and cached. The strategy just reads them.

class MyStrategy(Strategy):
    METADATA = {
        "name": "SMA Crossover",
        "domain": "eth_usdc",
        "declared_sl_bps": 150.0,
        "declared_tp_bps": 300.0,
        "declared_hold_seconds": 3600,
        "warmup_bars": 20,
        "required_features": [],
    }

    def on_bar(self, ctx):
        closes = ctx.closes(lookback=20)
        if len(closes) < 20:
            return None
        fast = sum(closes[-5:]) / 5
        slow = sum(closes) / 20
        if fast > slow:
            return ctx.signal(
                direction=SignalDirection.LONG,
                confidence=0.7,
                stop_loss_bps=150.0,
                take_profit_bps=300.0,
                horizon_seconds=3600,
            )
        return None

Validation

Submitted strategies go through a 7-stage validation pipeline:

Static check — metadata validation, SL/TP ceiling, code safety scan
In-sample backtest — seeded RNG, no wall clock, no network
Out-of-sample — 40% of data held out, never seen during in-sample
Walk-forward — 4 rolling windows, train on each, test on the next
Randomized start — 10 backtests with different start dates, checks for start-date luck
Perturbation — inject small noise into OHLCV, checks for overfitting to exact prices
Holdout — final test on data the strategy has never seen

A strategy has to pass all 7 to go live. The holdout stage is the gate, if it fails there, it doesn't deploy regardless of how good earlier stages looked.

After passing two stages, you can choose to make the code open-source so others can fork and improve it.

Tournament system

Bots compete in 3-day rounds across 6 domains (ETH/BTC/SOL spot + scalp). Scoring is:

50% rolling Sharpe ratio
30% rolling return (last 25 trades, compounded)
20% consistency (win rate × trade volume)

Top 3 per domain win USDT from the reward pool. No user following needed, your bot competes on its own metrics.

What this does NOT do

No execution layer in the MCP server. The server is a thin API client. It talks to a running dMoERA backend over HTTP.
No published performance numbers. The bots on the platform have live track records you can inspect, but I'm not going to cherry-pick numbers for this post. Call get_bot_profile and see for yourself.
No code execution in the MCP server itself. Backtesting runs on the backend in a sandboxed process. The server just passes strategy code via HTTP.
Not a framework for building your own backtester. This is specifically for the dMoERA platform's strategy contract.

Tools (16)

Category	Tools
Discovery	`list_domains`, `list_bots`, `get_bot_profile`, `get_feature_catalog`
Market data	`get_market_regime`, `get_current_prices`
Strategy dev	`sandbox_backtest`, `submit_strategy`, `list_strategies`, `get_strategy_report`
Marketplace	`get_marketplace_bots`, `get_tournament_status`
Open source	`open_source_strategy`, `fork_strategy`, `get_open_source_leaderboard`, `delist_strategy`

Resources (2)

creator-api://docs — Full strategy contract documentation
creator-api://strategy-template — Copy-pasteable template

Auth model

Public tools (market data, leaderboard, tournament) work with no key. Authenticated tools (backtest, submit, fork) need a personal access token.

Transports

stdio: python mcp_creator_server.py (for Claude Desktop, Cursor, Windsurf)
Streamable HTTP: https://dmoera.xyz/mcp (for Smithery, remote clients)

Setup

{
  "mcpServers": {
    "dmoera-creator": {
      "command": "python",
      "args": ["/absolute/path/to/dmoera-mcp/mcp_creator_server.py"],
      "env": {
        "DMOERA_API_URL": "https://dmoera.xyz",
        "DMOERA_API_KEY": "your_optional_personal_access_token"
      }
    }
  }
}

The API key is optional for public tools. Create a personal access token at dmoera.xyz under Settings → API Keys to backtest, submit, fork, open-source, or delist strategies.

GitHub: github.com/CacheCarti/dmoera-mcp
Smithery: smithery.ai/servers/mk9654/dMoERA-Creator
Platform: dmoera.xyz

MIT license. Happy to answer questions or take criticism. If you see design flaws in the strategy contract or validation approach or any nice-to-haves :) I genuinely want to know.