Coder Legion - Recent posts tagged backtesting

We pre-registered a Polymarket insider score. It passed, and we still didn't ship it

Thu, 22 Oct 2026 09:55:28 +0000

Polymarket insider trading makes headlines every few weeks, so an insider score sounds like an obvious feature for a Polymarket analytics site. We built one, called it the Early score, wrote the rules down before running it, and tested it on 355,732 wallets. It passed its own test, and we did not release it. The full results are on our blog and the aggregated data and a script are on GitHub.

This post is about the method: how to set up a wallet score so the test can actually fail, the traps we hit before the test, and the check that changed our mind.

1. Write the rules down first

Before computing a single score, we put the whole method in a pre-registration file: what an entry is, how the move is measured, the shrinkage constant, which markets are out, which periods are compared, and what counts as a pass. Every later change went in as a dated line with the reason.

The pass rule was simple: score wallets on October 2025 to March 2026 (period A), and the top 10% must still be positive on April to September 2026 (period B), also without the 5 largest events.

Without this file it is very easy to keep adjusting until something works. With it, every change you make has to be justified in writing before you see the outcome.

2. The score

If a wallet knows something first, the price should move its way after it trades. So for each entry we measured the price of the side the wallet holds 24 hours later, minus the price it paid, in cents. A wallet's score is the size-weighted average, pulled toward zero for wallets with few entries:

def shrunk_mean(moves, weights, k=5.0):
    """Size-weighted mean move, shrunk toward 0.
    weights are entry sizes capped at $10,000, so n_eff counts 'effective entries'."""
    total_w = sum(weights)
    if total_w == 0:
        return 0.0
    raw = sum(m * w for m, w in zip(moves, weights)) / total_w
    n_eff = total_w ** 2 / sum(w * w for w in weights)
    return raw * n_eff / (n_eff + k)   # 5 effective entries keep half the raw mean

Wallets within 1 cent of zero (one price tick) get a neutral 50; the rest become a percentile. Sports and short Up or Down markets are out: a day after a match the price is the result, so the score would just rank sports bettors.

3. Trap: wallets trading with each other at made-up prices

On one test day the top of our list was a group of related wallets passing the same shares back and forth in finished tennis matches. One bought at 0.02 and sold to a partner at 0.96 four minutes later. Read trade by trade, that is a +94 cent entry.

The fix was to define an entry as a wallet's net position change in one market over one UTC day, not as a single trade:

from collections import defaultdict

def daily_entries(trades):
    """Simplified. trades: dicts with wallet, market, day, side ('YES'/'NO'), shares (+buy/-sell), price.
    Selling NO counts as buying YES. A same-day round trip nets to zero."""
    net = defaultdict(lambda: {"yes": 0.0, "no": 0.0, "cost_yes": 0.0, "cost_no": 0.0})
    for t in trades:
        k = (t["wallet"], t["market"], t["day"])
        s = "yes" if t["side"] == "YES" else "no"
        net[k][s] += t["shares"]
        net[k]["cost_" + s] += t["shares"] * t["price"]
    for k, v in net.items():
        delta = v["yes"] - v["no"]
        if delta == 0:
            continue
        side = "yes" if abs(v["yes"]) >= abs(v["no"]) else "no"
        avg_price = v["cost_" + side] / v[side] if v[side] else None
        yield k, delta, avg_price

If you rank Polymarket wallets by anything trade-based, expect these pairs near the top of your list.

4. Trap: a thin "price after"

In one market a handful of trades of $1.50 to $15 at 0.15 set the price 24 hours later, though the market settled at 1. One tiny trade can fake a move. We now require at least $100 of other wallets' trades in that hour before using a price, and fall back to the final price only if the market has closed.

5. The test passed

Period A groups, measured on period B, with t-statistics clustered by event (many entries in one event are not independent):

Group from period A	24 h move in B, cents per entry	t
Top 10%	+0.83	7.9
Bottom 10%	-0.76	-4.7
All wallets	-0.01	-0.2

It held without the 5 largest events, without weather markets, and for every shrinkage constant from 0 to 100. By the rule we wrote, a pass.

6. The check that changed our mind: look at the mechanism

A pass tells you the score finds something that repeats. It does not tell you what. An insider and a wallet that simply buys cheaper both show a positive move, but with a different shape:

news spreading: the price keeps moving for hours;
a cheap fill: the gap is there at once and stops growing.

So we split each wallet's move into the first hour and the drift from 1 to 24 hours, and asked which part repeats between the two periods:

from statistics import correlation  # Python 3.10+

def ranks(xs):
    order = sorted(range(len(xs)), key=xs.__getitem__)
    r = [0] * len(xs)
    for i, j in enumerate(order):
        r[j] = i
    return r

def spearman(a, b):
    return correlation(ranks(a), ranks(b))

# per wallet, period A vs period B
rho_first_hour = spearman(first_hour_A, first_hour_B)   # 0.138
rho_drift      = spearman(drift_A, drift_B)             # 0.050

The top 10% were already +0.75 cents ahead after one hour and +0.83 after 24. The first-hour part repeats; the drift, the part an insider score exists to catch, barely does. The score was ranking wallets by fill quality.

This check was not in the pre-registration, and we label it exploratory everywhere. But it is the one that decided whether a label like "insider" would tell users the truth. It would not, so the score is not on the site, in the API or in MCP.

7. Money, not moves

A 24-hour move is not profit, so we also held every entry in a resolved market to settlement and subtracted the fee each wallet actually paid on-chain. The top 10% made +1.17 cents per entry after fees (t 2.9), on both mostly taker and mostly maker entries. One detail that matters if you repeat this: compare groups with all wallets, not with zero. On longer-dated markets every group drifts up, so zero is the wrong baseline.

Reproduce it

The repo has the aggregated tables behind every number and scripts/early_score_check.py (standard library only), which rebuilds entries, scores and the period test from the OrcaLayer API:

export ORCALAYER_API_KEY=sk_orca_...        # never commit it
python3 scripts/early_score_check.py --csv entries.csv        # first 1,000 markets of data/markets.csv
python3 scripts/early_score_check.py --load-csv entries.csv   # rerun the analysis, no API calls

The API's trade history starts on May 1, 2026, so the script scores on May and June and checks on July to September, on a fixed list of 1,000 markets. The script writes wallets only as salted hashes, and the repo publishes groups only, no addresses.

What this does not show

Sports, individual wallets, and copying these wallets (a copy trades after them and does not get their price). On the shorter API check, the groups did not separate when held to settlement, so treat the money part as the weakest result.

Originally published on orcalayer.com. OrcaLayer is an independent Polymarket analytics provider, not affiliated with Polymarket.

Backtesting live football on Polymarket: 6 traps in a recorded order book

Wed, 14 Oct 2026 11:44:45 +0000

We recorded the order book of every Polymarket football (soccer) market for three weeks and tested two in-play ideas: buying a team right after a late price jump at a level score, and protecting goal bets with a stop-loss. Neither paid. Buying the jump 2 seconds later lost $2.85 per $10 over 837 jumps (t -7.9), and every one of 28 stop settings did worse than holding on the replay. The full results are on our blog and the data is on GitHub.

This post is about the data side: six traps we hit while building the test. Most of them will bite anyone who backtests in-play markets on Polymarket.

1. You have to record the book yourself, then check the recording

Public Polymarket APIs give you trades and the current book, not the book as it was a second ago. For an in-play test you need the best bid and ask around every event, so we recorded the CLOB WebSocket market channel (book, price_change, last_trade_price) with exchange timestamps.

Before using it, check it against on-chain trades. Ours had 99.9% of on-chain trades, and 97.6% of them happened at the best price the recording showed at that moment. If your numbers are much lower, your replay will invent fills.

2. Events arrive out of order

The exchange can send the price_change for a level that a trade just ate before the last_trade_price of that same trade. Read events in arrival order and fills look about 25% worse than they were. Put each trade ahead of the book change it caused before you measure anything.

3. The mid is not a price you can trade

Our first detector watched the mid-price: if a team's mid jumps by 0.25 or more late in a level match, call it a goal. Many of those "goals" were sellers pulling their quotes. The mid doubles, the bid stays where it was, and the spread opens up.

One example from the data: the mid went from 0.24 to 0.505 in seconds, but the ask was 0.78 and the bid about 0.23. A bot buying 2 seconds later paid 0.81. Ten seconds after the jump the ask was back at 0.25, and the match ended in a draw.

Store the ask and the spread, not only the mid. The implied bid is easy to get back if you only kept mid and ask:

def spread_at_jump(mid: float, ask: float) -> float:
    bid = 2 * mid - ask          # implied bid
    return round(ask - bid, 2)   # e.g. mid 0.505, ask 0.78 -> 0.55

In our data 627 of 837 late jumps had a spread of 20 cents or more, and the jumping side won only 36% of those.

4. The "level score" can be fake too

Our rule also needed the draw to be the favorite 30 seconds before the jump. That condition is read from mids as well, so pulled quotes can fake it in a match one team already leads. When all three books of a 1X2 match are two-sided, the three mids add up to about 1.00. Check that before you trust the state:

def book_looks_clean(home_mid: float, draw_mid: float, away_mid: float) -> bool:
    return 0.95 <= home_mid + draw_mid + away_mid <= 1.05

In 51 of the 85 jumps that had a tight spread, the three mids before the jump added up to more than 1.10. One of them was a team that had led for 20 minutes: its bid disappeared for a moment, the score looked level, and the bid coming back looked like a late goal.

5. Daily batch files overlap

We ran the scan one day at a time, and each day file also covered the first hours after midnight UTC. Jumps after midnight landed in two files: 48 duplicates out of 885 raw rows. They did not change the conclusion, but they would have inflated every count and t-statistic. If you split a time series by day, check the joins.

6. The fastest entry is not reachable

Football markets have secondsDelay: 1 in the Gamma API: a taker order waits a second before it can match, and you cannot cancel it during that time. So a result "at +0 s" is not a strategy, it is a plot point. In our test the earliest entries lost the most (-$4.21 per $10 at +0 s, -$2.85 at +2 s), because the first seconds after a jump are when the price is most wrong in the direction you are buying.

The same delay hurts stops. Polymarket has no stop orders, so a stop is a bot watching trades and then market-selling after the delay, paying the taker fee a second time. In live football prices swing several cents within minutes, and a 3-cent stop fired on 86 to 96% of our replayed bets.

Reproduce it

The repo has data/late_goal_jumps.csv (one row per jump, with the asks 0 to 60 seconds after it and the result) and a standard-library script that recomputes every late-goal number:

python3 scripts/summarize_late_goals.py data/late_goal_jumps.csv

METHOD.md describes the recorder, the detection rule and each trap above in more detail.

What this does not show

About three weeks of football, mostly club leagues. Pre-match markets, other sports and stops on strategies whose entries already make money were not tested. Bets in the same match are not independent, so read t values near 2 with care.

Originally published on orcalayer.com. OrcaLayer is an independent Polymarket analytics provider, not affiliated with Polymarket.

Backtesting a Polymarket copy trading bot without fooling yourself

Sat, 10 Oct 2026 13:28:30 +0000

Copy trading is the most common bot idea on Polymarket: find the wallets that win and buy what they buy. We tested it on five sports (MLB, NFL, college football, League of Legends and Valorant) and it did not survive. The full results are on our blog and the data and script are on GitHub.

This post is about the backtest itself: how to set it up so it can tell you "no", and the one mistake that makes almost every copy bot backtest look better than it would be live.

1. Define a copy you could actually execute

A "copy" in our test is a wallet's first buy of at least $20 in a market, at a price between 0.30 and 0.85. We buy the same outcome for $10 at the wallet's price plus 1 cent, pay the sports taker fee and hold to resolution. Roughly, in code:

def copy_result(price: float, won: bool, stake: float = 10.0, slip: float = 0.01) -> float:
    p = price + slip                      # you never get the whale's exact price
    shares = stake / p
    fee = shares * 0.05 * p * (1 - p)     # Polymarket sports taker fee
    payout = shares if won else 0.0
    return payout - stake - fee

One cent is generous. In fast in-play markets the price moves much further before a copy fills. We also reran MLB at +3 cents: every result went negative, including the top 10.

2. Pick on one period, measure on the next

The rule: rank wallets by their copy results over the two months before the test month, then copy only in the test month. Nothing from the test month touches the selection. We used three rules fixed before the run:

ALL10: every wallet with at least 10 copies (the "average whale")
POS: at least 20 copies, mean above zero, t-statistic of 2 or more
TOP10: the 10 best by t-statistic

MLB, top 10, per $10 copied:

Test month	While picked	Month after
July 2026	+$3.65	+$0.16
August 2026	+$3.06	-$0.04
September 2026	+$2.72	-$0.47
Oct 1-4 2026	+$3.78	-$2.23 (n 7)

The same rule that showed +$3 in the pick window showed about zero the month after.

3. Check whether rank carries over at all

Before tuning thresholds, check if past performance predicts future performance for individual wallets. For MLB wallets with at least 10 copies in both periods, the Spearman correlation between the pick months and the next month was -0.01, +0.15, +0.08 and -0.03. NFL was between -0.09 and +0.03.

With correlations like that, picking "the best" is picking the luckiest. With thousands of active wallets, dozens will have a great two months by chance.

4. Look at the baseline before the winners

The average MLB whale, copied one cent worse than its own price, lost 31 to 63 cents per $10 in every test month. If the baseline is negative, a selection rule has to beat a loss before it makes anything. Check ALL10 first.

5. The trap: wallet labels computed today

This one is easy to miss. Analytics sites (ours included) label wallets: "smart money", "50+ resolved markets", win rate, profit factor. Those labels are computed today, on each wallet's full history, including the months you are about to backtest.

If you pick wallets with today's labels and backtest them on last summer, the selection already knows who survived. Wallets that blew up are not labeled "smart", so the backtest never copies them. It will always look better than it would have live.

We hit a mild version of this ourselves: one filter in our profile screen used each wallet's share of activity in the sport on its full history. We disclosed it in the methodology. It most likely flatters the pools, and they still showed no edge.

Rule of thumb: every feature used to pick a wallet must be computable from data strictly before the pick date.

6. Make it reproducible

The repo has scripts/copy_backtest.py (Python 3.9+, standard library only) that runs the same walk-forward on the OrcaLayer API for any league:

export ORCALAYER_API_KEY=sk_orca_...        # never commit it
python3 scripts/copy_backtest.py --league mlb --start 2026-05-01 --end 2026-09-30 --max-markets 800

To check that the API path and our internal database agree, we ran both on the same 800 MLB games: 161,094 copies in both, every wallet, price and result equal, total -$83,012.60 in both. The script output showed the same picture: top 10 from about +$3 per $10 to between -$1.29 and +$1.06 the month after.

The script needs a Premium API key. If you just want to look at a wallet's record before copying it, the free OrcaLayer MCP server works from Claude without a key.

What this does not show

Five sports, and picking by past results only. Slower markets like politics, where informed money can stay ahead for days, and picking wallets by how they trade rather than how much they made, were not tested.

Originally published on orcalayer.com. OrcaLayer is an independent Polymarket analytics provider, not affiliated with Polymarket.

Building a Better Market Microstructure Analyzer: Backtests, Reproducibility, and Honest Limits

Sat, 26 Sep 2026 09:42:15 +0000

In my first post, I introduced a project that processes five-level order-book snapshots and displays measures such as spread, order-flow imbalance (OFI), and VWAP.

After publishing it, I wanted to make it more than a basic demo. Adding another indicator would have been easy to describe, but it would not have answered the question I had started asking about the project: how much can I trust its outputs?

I went back to the backtesting methods, the data generator, and the parts of the pipeline that connect one calculation to the next. I also made the project’s licence and limitations easier to find. Here is what changed and what I learned.

A backtest needs to account for the whole trade

The project includes a directional backtester based on OFI. The initial version could produce a trade log and performance figures, but some of its accounting was too basic. In particular, transaction costs needed to be reconciled across entry and exit, and drawdown needed a meaningful starting capital value.

I corrected those calculations so that trade-level profit and loss can be checked against the change in final equity. I also removed an annualised return statistic that did not make sense for a sequence of synthetic ticks and replaced it with an explicitly unannualised completed-trade measure.

This may sound less exciting than adding a new strategy. It was more useful. If the accounting is inconsistent, a convincing-looking chart is not evidence of anything.

Testing one period is not enough

A backtest can look good because its parameters happen to suit the data used to choose them. To make that harder, I added a walk-forward evaluation workflow with chronological splits. Parameters are selected using earlier observations and assessed on later held-out observations. The workflow also checks what happens under harsher transaction costs and whether results are stable across folds.

That is a better test of the evaluation method than running one strategy over an entire dataset and reporting its best outcome. But there is an important boundary here: the project’s validated data workflow is still synthetic. Passing a walk-forward check on generated data does not establish that OFI predicts returns in Indian equities or that a strategy would be profitable in a live market.

I wanted the project to make that distinction clear. A backtester can be implemented and internally consistent without being a validated trading strategy.

Reproducing the same experiment

Earlier, the synthetic feed used global randomness and wall-clock time. That made it difficult to investigate a changed result: had the code changed, or had the input simply changed?

The generator now uses a local random-number generator, an explicit seed, a fixed clock when requested, and a defined tick count. Running the same configuration produces the same input records and analytics output. This lets me compare code changes against a stable example rather than a moving target.

The repository also has automated tests for the analytics engine and connected workflows. Its validation guide describes what those checks cover and, just as importantly, what they do not cover.

Fixing the stream, not only the formulas

Some problems only appeared when components ran together. The analytics engine initially failed on its first snapshot because an anomaly-detector argument did not match its constructor. Internal code also disagreed about whether a snapshot’s time field was called ts or timestamp. Tick classification returned text labels where signed-volume calculations needed numerical values.

I fixed these connections and added tests that exercise more than an isolated formula. I also changed the rolling OFI windows to use queues and running sums rather than scanning the retained history on each tick. Anomaly calculations similarly maintain rolling sums instead of repeatedly traversing their windows.

The lesson for me was that “real-time” is not just about displaying a changing chart. The calculations need to remain manageable as more observations arrive, and the entire path from input to output needs to work.

Naming results accurately

Reviewing the project also meant revisiting the labels on some outputs. A trade/quote variance diagnostic had been described as a classical Hasbrouck information-share estimate, although the project’s single-venue setup does not implement that method. It is now described as the diagnostic it actually calculates.

Similarly, the execution replay had called a change in the last fill price “market impact.” Because the replay uses a static order book, it cannot show the causal effect an order would have on the market. The output now calls this last-fill slippage, and the replay-VWAP comparison carries its look-ahead limitation.

I would rather have a narrower, accurate description of a result than a more impressive label that the code cannot defend.

What remains unfinished

There is no live exchange feed in the validated workflow. I do not currently have an Angel One account connected to the project, and the SmartAPI adapter in the repository remains a stub. The interactive demo replays simulated data; it does not show live NSE order books.

Before making claims about live performance or a trading signal, I would need appropriate real data and further validation. Live ingestion would also require careful handling of reconnects, gaps, rate limits, and market sessions.

I revisited the project’s licence as part of making the public repository clearer; it now displays its AGPL-3.0 terms alongside the code and documentation. The repository contains the current implementation, validation notes, and instructions for reproducing the synthetic-data workflow.

The project is stronger now because I can explain what runs, what has been tested, and what I still cannot claim. That is the standard I want to carry into the next stage of the work.

AutoTradingKit

Tue, 15 Apr 2025 00:43:56 +0000

ATK - Auto Trading Kit

Introduction - Elevate Your Trading with ATK

ATK (Auto Trading Kit) is a free, open-source platform engineered for traders and developers seeking to automate, backtest, and optimize their trading strategies. Whether you are a seasoned trader or a coding enthusiast, ATK empowers you to design, test, and execute strategies across popular exchanges with real-time analytics and advanced tools.

Tip: ATK is designed to reduce manual work, enhance strategy development, and enable efficient trade execution. Built using Python and PySide6, ATK is cross-platform (Windows, MacOS, and Linux) and features an intuitive UI inspired by trading industry leaders.

Key Features of ATK

Feature	All Plan
Number of Charts	Unlimited (PC performance dependent)
Number of Indicators	Unlimited
Alerts	Under Development
Historical Data	Unlimited
Data Export	Under Development
Customer Support	8/5
Real-time Data	Yes
Auto Trade	Under Development (API & Secret key required)
Backtesting	Yes
Drawing Tools (Basic & Advanced)	Yes
Multiple Tabs	Yes
Timeframe Support	Yes (1m to 1M)
Buy/Sell (Market, Limit, Trailing Stop)	Under Development
Crypto	Yes
Forex	Under Development
Stock	Under Development

How to Get Started with ATK

Prerequisites

Python 3.12
Windows 10/11 (64-bit), MacOS, or Linux

Installation Steps

Clone the repository:

git clone https://github.com/Khanhlinhdang/AutoTradingKit
cd AutoTradingKit

Set up a virtual environment:
```
python -m venv .venv
```
Activate the virtual environment:
- Windows:
```
.venv\Scripts\activate
```
- MacOS/Linux:
```
source .venv/bin/activate
```

Install dependencies:

Windows:
```
pip install -r requirements.txt
```

MacOS/Linux:

pip install -r mac_linux_requirements.txt

Run ATK:
```
python ATK.py
# or
python3 ATK.py
```

Build Application

Convert .py to .pyd/.so using Cython for performance.
Use pyinstaller to build executable files for your OS.

Supported Indicators

ATK integrates a wide range of indicators, sourced from pandas-ta and custom conversions from TradingView, MT4, and MT5.

Current Indicator List

Aroon
Average Directional Index (ADX)
Average True Range (ATR)
Bollinger Bands (BB)
Commodity Channel Index (CCI)
Donchian Channel (DC)
Keltner Channel (KC)
Moving Averages (ALMA, DEMA, EMA, HMA, KAMA, SMA, SMMA, T3, TEMA, VWMA, WMA, ZLEMA)
MACD
Rate of Change (ROC)
RSI
Schaff Trend Cycle (STC)
Stochastic Oscillator & Stochastic RSI
SuperTrend
TRIX
True Strength Index (TSI)
Ultimate Oscillator (UO)
Vortex Indicator (VTX)
VWAP
Smart Money Concept (SMC)
UTBOT
...and more!

Upcoming Indicators

TTM Squeeze, Standard Deviation, SFX TOR, Pivots High/Low, Parabolic SAR, OBV, SOBV, Mean Deviation, McGinley Dynamic, Mass Index, KST, KVO, Ichimoku, Force Index, DPO, IBS, EMV, Chaikin Oscillator, Chande Kroll Stop, Choppiness Index, Coppock Curve, Awesome Oscillator, Balance of Power, ADL, etc.

How to Add a New Indicator to ATK

How-to Guide:
Adding a new indicator follows a standardized structure. For example, to create a new "bop" indicator, follow these steps:

Create the calculation module:
Add bop.py in atklip/controls/momentum referencing pandas_ta calculations.
Implement the chart component:
Add bop.py in atklip/graphics/chart_component/indicators/sub_indicators/.
Register the model:
Update atklip/controls/models.py with the new indicator class.
Update the indicator menu:
Add the indicator to atklip/gui/top_bar/indicator/indicator_menu.py.
Register the IndicatorType:
If needed, update atklip/controls/ma_type.py.
Add to sub panel:
Update setup_indicator in atklip/graphics/chart_component/sub_panel_indicator.py.

FAQ:
How do I request a new indicator?
Submit a GitHub Issue with your request.

Roadmap 2025

Add more indicators (MT4, MT5, TradingView)
Expand trading strategies
Enable API/Secret integration with more exchanges (Binance, MEXC, ...)
Enhance drawing tools and charting features
Improve backtesting and replay
Layout customization & theme settings
Order/position management UI
Secure login and account management
Integrate AI-powered indicators and strategies

Support & Community

Get help or request features: GitHub Issues
Email: Emails are not allowed
YouTube: AutoTradingKit
Facebook: Pham Cong Che
Discord: ATK Community
Facebook Group: ATK Facebook Group

Support ATK Development

Note:
Maintaining and improving ATK requires resources. Your sponsorship helps us deliver new features, bug fixes, and better support for the community.

Ways to Sponsor:

Author & Acknowledgement

Pham Cong Che (BigD)
Trader, freelancer, and developer from Vietnam.

“Let’s build the future of algorithmic trading together!”

License

ATK is released under the MIT License.

References

Conclusion

In summary, ATK (Auto Trading Kit) is a robust and extensible platform for algorithmic traders and developers. With its cross-platform compatibility, support for unlimited charts and indicators, and a growing ecosystem, ATK is well-positioned for both beginners and professionals. The roadmap promises exciting features like AI-powered indicators and enhanced backtesting. Unlock your trading potential with ATK—explore, contribute, and join our thriving community today!

Coder Legion - Recent posts tagged backtesting

We pre-registered a Polymarket insider score. It passed, and we still didn't ship it

1. Write the rules down first

2. The score

3. Trap: wallets trading with each other at made-up prices

4. Trap: a thin "price after"

5. The test passed

6. The check that changed our mind: look at the mechanism

7. Money, not moves

Reproduce it

What this does not show

Backtesting live football on Polymarket: 6 traps in a recorded order book

1. You have to record the book yourself, then check the recording

2. Events arrive out of order

3. The mid is not a price you can trade

4. The "level score" can be fake too

5. Daily batch files overlap

6. The fastest entry is not reachable

Reproduce it

What this does not show

Backtesting a Polymarket copy trading bot without fooling yourself

1. Define a copy you could actually execute

2. Pick on one period, measure on the next

3. Check whether rank carries over at all

4. Look at the baseline before the winners

5. The trap: wallet labels computed today

6. Make it reproducible

What this does not show

Building a Better Market Microstructure Analyzer: Backtests, Reproducibility, and Honest Limits

A backtest needs to account for the whole trade

Testing one period is not enough

Reproducing the same experiment

Fixing the stream, not only the formulas

Naming results accurately

What remains unfinished

AutoTradingKit

ATK - Auto Trading Kit

Introduction - Elevate Your Trading with ATK

Key Features of ATK

How to Get Started with ATK

Prerequisites

Installation Steps

Build Application

Supported Indicators

Current Indicator List

Upcoming Indicators

How to Add a New Indicator to ATK

Roadmap 2025

Support & Community

Support ATK Development

Author & Acknowledgement

License

References

Tags

Conclusion