BLACKBENCH

All work polygangster


Trading · backtesting · 2026

polygangster


Backtesting a Smart Money Concepts order-block strategy against real Polymarket binary-option odds.

An honest answer for a trading hypothesis, taken from the odds that really stood in the book, before any money goes near it.

By the numbers

7
instruments
4
timeframes: 5m, 15m, 1h, 4h
~50
TypeScript modules
2
price sources: Binance and MetaTrader 5

The problem

The client has a strategy built on Smart Money Concepts order blocks and one question about it: does it hold up at the prices binary options actually trade at? A notional 1:1 payout proves nothing — on Polymarket the price of a bet moves minute by minute, so an identical signal pays differently depending on when it fired. The test has to run against the odds that stood in the book at the moment of entry.

That is where the data itself gets in the way. Polymarket keeps odds history for about 30 days and deletes order books once a market resolves. With no storage of your own the testable window shrinks rather than grows, and yesterday cannot be recovered. Which period you can test at all turns out to be an engineering question here, not an analytical one. And when the tool comes back saying a strategy does not hold up, that is a legitimate answer — it is the answer a backtest exists to produce.

The solution

The sync accumulates Polymarket odds going forward and keeps them once Polymarket has purged its own. The backtestable window is as long as the service has been running, not as long as the exchange's thirty-day tail.

Binance and MetaTrader 5 candles sync independently of Polymarket odds, each source with its own backfill and its own status. One of them failing neither corrupts the others nor halts a run.

Every bet stores the geometry of the order block that triggered it, the order-book depth at entry, and the traded volume of the market. The journal shows why a trade opened, not merely how it closed — and any signal can be replayed under different parameters.

A strategy is a set of structures — OB-EXT, OB-IDM, SMT and their internal variants — with lots and timeframes attached. One set of settings drives the backtest, the dry run and the live session; the modes differ by a flag, not by a code path, which is what makes their results comparable.

Sessions run with a trade journal and Telegram notifications, and instruments switch on per coin and timeframe — nothing is computed over data that was never loaded.

Screens

Synthetic data. Every screen in this case study comes from a separate demo database, polygangster_demo, filled by a random-number generator, never the production archive: the backtests, the stakes and the PnL measure nothing and describe no trading result.

Setting up a run: instruments, timeframes, the structure set and the staking parameters, with finished sessions listed below. The win rate and the PnL in that log were computed over generated stakes from an isolated demo database: they measure nothing and promise nothing.
Candles with order blocks drawn in — green means the strategy bets down, red means up. The inspector underneath lists every block and marks it live or touched.
Load and sync: seven instruments across four timeframes in the catalogue, three of them switched on — BTC, ETH and SOL at 15m. Binance and Polymarket each carry a status and a backfill depth of their own.
The Binance symbol catalogue — 200 symbols across five timeframes. The same three are switched on, and a stored-candle count is shown only for those.
A trading session in dry-run mode on the same settings as the backtest. Live is a separate flag; notifications go to Telegram.

Stack

TypeScript, about 50 modules
Vite web console
PostgreSQL for odds, candles and sessions
Polymarket, Binance, MetaTrader 5
Telegram notifications