Original Title: I built a Polymarket bot and tested multiple parameter setups, here are the results.

Original Author: @thesmartape, Crypto Researcher

Original Compilation: Bitpush News

A few weeks ago, I decided to build my own Polymarket bot. The complete version took me several weeks to develop.

I was willing to invest this effort because there are indeed efficiency gaps on Polymarket. Although there are already some bots profiting from these inefficiencies, it is still far from enough; the opportunities in this market far exceed the number of bots.

Bot Construction Logic

The logic of the bot is based on a set of strategies I previously executed manually, which I automated to improve efficiency. The bot operates in the "BTC 15-minute UP/DOWN" market.

The bot runs a real-time monitoring program that can automatically switch to the current BTC 15-minute round, streaming the best bid/ask prices via WebSocket, displaying a fixed terminal UI, and allowing comprehensive control through text commands.

In manual mode, you can place orders directly.

buy up usd> / buy down usd>: Buy a specific dollar amount.

buyshares up shares> / buyshares down shares>: Purchase an exact number of shares, using user-friendly LIMIT + GTC orders, executed at the current best ask price.

The automatic mode runs a repeating two-leg cycle.

In the first step, it only observes price fluctuations within windowMin minutes after the start of each round. If either side drops fast enough (a drop of at least movePct within about 3 seconds), it triggers "Leg 1," buying the side that has plummeted.

After completing Leg 1, the bot will never buy the same side again. It will wait for "Leg 2" (the hedge) and will only trigger when the following condition is met: leg1EntryPrice + oppositeAsk = sumTarget.

When this condition is met, it buys the opposite side. After Leg 2 is completed, the cycle ends, and the bot returns to observation mode, waiting for the next signal of a drop using the same parameters.

The parameter settings for automatic mode are as follows: auto on shares> [sum=0.95] [move=0.15] [windowMin=2]

· shares: Position size for the two-leg trade.

· sum: Threshold for allowing hedging.

· move (movePct): Drop threshold (e.g., 0.15 = 15%).

· windowMin: Duration allowed for executing Leg 1 from the start of each round.

Backtesting

The logic of the bot is simple: wait for a violent sell-off, buy the side that has just dropped, then wait for the price to stabilize and hedge by buying the opposite side, while ensuring: priceUP + priceDOWN = 1.

But this logic needs to be tested. Is it really effective in the long run? More importantly, the bot has many parameters (number of shares, sum, move percentage, window minutes, etc.). Which set of parameters is optimal and can maximize profits?

My first thought was to let the bot run in real-time for a week and observe the results. The problem is that this takes too long and can only test one set of parameters, while I need to test many sets.

My second thought was to use online historical data from the Polymarket CLOB API for backtesting. Unfortunately, for the BTC 15-minute UP/DOWN market, the historical data endpoint consistently returned empty datasets. Without historical price ticks, backtesting cannot detect "drops within about 3 seconds," failing to trigger Leg 1, resulting in 0 cycles and 0% ROI regardless of parameters.

Upon further investigation, I found that other users also encountered the same issue when retrieving historical data for certain markets. I tested other markets that did return historical data and concluded that for this specific market, historical data was simply not retained.

Due to this limitation, the only reliable way to backtest the strategy was to create my own historical dataset by recording real-time best ask prices while the bot was running.

The recorder writes snapshots to disk, containing the following:

· Timestamp

· Round identifier (round slug)

· Remaining seconds

· UP/DOWN token ID

· UP/DOWN best ask price

Subsequently, the "recorded backtest" replays these snapshots and deterministically applies the same automatic logic. This ensures the acquisition of high-frequency data needed to detect drops and hedge conditions.

I collected a total of 6 GB of data over 4 days. I could have recorded more, but I thought this was sufficient to test different parameter sets.

I started testing this set of parameters:

· Initial balance: $1,000

· 20 shares per trade

· sumTarget = 0.95

· Drop threshold = 15%

· windowMin = 2 minutes

I also applied a constant 0.5% fee and a 2% spread to maintain a conservative scenario.

The backtest showed an ROI of 86%, turning $1,000 into $1,869 in just a few days.

Then I tested a more aggressive parameter set:

· Initial balance: $1,000

· 20 shares per trade

· sumTarget = 0.6

· Drop threshold = 1%

· windowMin = 15 minutes

Result: -50% ROI after 2 days.

This clearly indicates that parameter selection is the most important factor. It can lead to significant profits or substantial losses.

Limitations of Backtesting

Even with fees and spreads included, backtesting has its limitations.

· First, it only used a few days of data, which may not be sufficient for a comprehensive market perspective.

· It relies on recorded best ask price snapshots; in reality, orders may be partially filled or filled at different prices. Additionally, order book depth and available volume were not modeled.

· It did not capture micro-fluctuations below the second level (data sampled once per second). Although backtesting has 1-second timestamps, many things can happen between each second.

· In backtesting, slippage is constant, with no simulation of variable delays (e.g., 200–1500 milliseconds) or network peaks.

· Each leg of the trade is treated as "instant" execution (no order queuing, no pending orders).

· Fees are uniformly charged, while in reality, fees may depend on: market/token, maker vs. taker, fee tier, or conditions.

To remain pessimistic (prudent), I applied a rule: if Leg 2 fails to execute before the market closes, Leg 1 will be considered a total loss.

This is deliberately conservative but does not always reflect reality:

· Sometimes Leg 1 can be closed early,

· Sometimes it ends up in the money (ITM) and wins,

· Sometimes losses can be partial rather than total.

While losses may be overestimated, this provides a practical "worst-case" scenario.

Most importantly, backtesting cannot simulate the impact of your large orders on the order book or attract other traders to hunt your actions. In reality, your orders can:

· Disturb the order book,

· Attract or repel other traders,

· Cause nonlinear slippage.

Backtesting assumes you are a pure price taker with no impact.

Finally, it does not simulate rate limits, API errors, order rejections, pauses, timeouts, reconnections, or situations where the bot is busy and misses signals.

Backtesting is extremely valuable for identifying good parameter ranges, but it is not a 100% guarantee, as some real-world effects cannot be modeled.

Infrastructure

I plan to run the bot on a Raspberry Pi to avoid consuming resources on my main machine and to keep it running 24/7.

However, there is still significant room for improvement:

· Using Rust instead of JavaScript would provide far superior performance and processing time.

· Running a dedicated Polygon RPC node would further reduce latency.

· Deploying on a VPS close to Polymarket servers would also significantly lower latency.

There are certainly other optimizations I have yet to discover. Currently, I am learning Rust, as it is becoming an indispensable language in Web3 development.

Original Link

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。