How to assess a Polymarket bot repository before running it

AI Trading Ranked

Last Updated: 2026-10-26

The earlier seven-bot ranking did not provide repository URLs, owners, pinned commits or the records behind its claimed returns. It cannot support an identifiable shortlist, so those recommendations are withdrawn. This page is an assessment worksheet, not a substitute list of newly invented projects.

Establish what you are reviewing

Copy the exact owner/repository URL, full commit identifier, licence and relevant source paths. A project name, screenshot or star count is not enough to distinguish a maintained project from a similarly named copy. GitHub documents permanent links to a file at a commit; a moving branch link may show different code later.

Record the runtime, manifest, lockfile, install hooks and external services. GitHub's dependency graph can help inspect dependencies, but a clean alert list is not a security audit. Do not run installation scripts just to find out what they do.

For platform compatibility, start with Polymarket's official documentation, including the separate US documentation linked there. Identify the relevant API, authentication method, order lifecycle and product. A public market-data response does not establish eligibility or permission to trade.

Separate observation from execution

Scroll sideways to see every column. Keyboard: focus the table region and use the arrow keys.

ModeExpected accessEvidence required
Read public market dataPublic endpoints onlyNo signer or order submission path invoked
Replay recorded eventsLocal fixturesFixed inputs, timestamps and reproducible output
Simulate ordersSynthetic balances and fillsNo live transport; explicit fill and fee assumptions
Place real ordersAccount authorityA separate operational review; not certified by the first three modes

A “dry-run” flag is only a claim until its call paths are inspected. A small funded order is live trading, not paper trading. Do not supply a wallet seed or production key to an unidentified project.

Test the failures before interpreting a return

Use fake balances and a stub order service. These examples describe expected evidence, not commands to connect an account.

For each case keep the input fixture, expected result, actual log and source commit. A green unit test is useful only for the behavior it exercises; it does not establish profitability, security or reliable live execution.

A candidate record you can actually compare

Repository and owner:
Commit and review date:
Licence / runtime / lockfile:
Public-data-only entry point:
Signing and order-submission entry points:
Inventory and unresolved-order accounting:
Persistent halt and restart behavior:
Failure fixtures run / not run:
Costs included / omitted:
Unresolved questions and decision:

“Needs review: sends a second order after a timeout” is more useful than an 8.7/10 score. A project with no resolvable identity stays unassessed; an identified project with missing controls is not promoted because it has more stars.

If a performance record is later supplied, require every fill, open position, transfer, fee, infrastructure cost and evaluation period. Distinguish a backtest from forward simulation and live activity. One positive month cannot establish a predictable monthly return. The equity journal shows why closed-trade profits alone are insufficient.

Trading automation can lose funds. No repository here has been installed, connected to an account or endorsed for production. AITR may earn referral commissions elsewhere; this worksheet contains no paid-bot recommendation.