Yield Farming at 86% APY? How to Use Bots to "Earn While You Sleep" on Polymarket

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

Original Author: @the_smart_ape, Crypto Researcher

Original Translation: Bitpush News

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

I was willing to put in this effort because there is indeed an efficiency gap on Polymarket. Although some bots in the market are already taking advantage of these inefficiencies, it is still far from enough, and the opportunities in this market are still far greater than the number of bots.

Bot Building Logic

The bot's logic is based on a set of strategies I have manually executed in the past, which I automated to improve efficiency. The bot runs on 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, streamlining the best bid/ask through a 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 amount in USD.

buyshares up <shares> / buyshares down <shares>: Purchase an exact amount of shares, using a user-friendly LIMIT + GTC (Good 'Til Canceled) order, executed at the current best ask price.

Automatic mode runs a recurring two-leg loop.

First, it only observes price movements within the windowMin minutes at the start of each round. If either side drops fast enough (reaching a drop percentage of at least movePct in about 3 seconds), it triggers "Leg 1," buying the side that experienced the sharp decline.

After completing Leg 1, the bot will never again buy the same side. It will wait for the "Second Leg (Leg 2, i.e., hedge)" and only trigger if 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, the bot returns to watching mode, waiting for the next flash crash signal using the same parameters.

If there is a change in the round during the cycle, the bot abandons the open cycle and restarts with the same settings in the next round.

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

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

· sum: Threshold for allowed hedging.

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

· windowMin: Time from the start of each round to allow the execution of Leg 1.

Backtesting

The bot's logic is simple: wait for a violent flash crash, buy the side that just dropped, then wait for the price to stabilize and hedge by buying the opposite side, ensuring that 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 (shares, sum, move percentage, window minutes, etc.). Which parameter set is optimal and maximizes profit?

My first thought is to have the bot run live for a week and observe the results. The issue is that this takes too long and can only test one set of parameters, whereas I need to test many.

My second thought is to backtest using online historical data from the Polymarket CLOB API. Unfortunately, for the BTC 15-minute up/down market, the historical data endpoint consistently returns empty datasets. Without historical price ticks, the backtest cannot detect an "approximately 3-second flash crash," cannot trigger Leg 1, and regardless of the parameters used, results in 0 cycles and 0% return on investment (ROI).

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 indeed return historical data and concluded that for this particular market, historical data simply was not preserved.

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

The recorder will write snapshots to disk, including the following:

· Timestamp

· Round Slug

· Remaining Seconds

· UP/DOWN Token ID

· UP/DOWN Best Ask Price

Subsequently, the "recorded backtest" will replay these snapshots and deterministically apply the same automated logic. This ensures the ability to obtain the high-frequency data needed to detect flash crashes and hedge conditions.

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

I began testing this set of parameters:

· Initial Balance: $1,000

· 20 Shares per Trade

· sumTarget = 0.95

· Flash Crash Threshold = 15%

· windowMin = 2 minutes

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

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

Next, I tested a more aggressive set of parameters:

· Initial Balance: $1,000

· 20 Shares per Trade

· sumTarget = 0.6

· Flash Crash Threshold = 1%

· windowMin = 15 minutes

Outcome: After 2 days, the investment had a return rate of -50%.

This clearly demonstrates that parameter selection is the most critical factor. It can make you a lot of money or lead to significant losses.

Limitations of Backtesting

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

· Firstly, it only uses a few days' worth of data, which may not be sufficient to gain a comprehensive market perspective.

· It relies on recorded optimal sell price snapshots; in reality, orders may partially fill or fill at different prices. Additionally, order book depth and available volume are not modeled.

· Sub-second micro-fluctuations are not captured (data sampled every second). While backtesting has timestamps at a 1-second level, a lot can happen between each second.

· Slippage is constant in backtesting, without simulating variable delays (e.g., 200–1500 milliseconds) or network congestion peaks.

· Each trade segment is assumed to be executed “instantaneously” (no order queueing, no resting orders).

· Costs are uniformly charged, whereas in reality, costs may depend on: Market/Token, Maker-Taker, Fee Tiers, or Conditions.

To maintain a pessimistic (cautious) approach, I applied a rule: if Leg 2 fails to execute before the market close, Leg 1 is considered a total loss.

While intentionally conservative, this doesn’t always align with reality:

· Sometimes Leg 1 can close early,

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

· Sometimes the loss can be partial rather than total.

While the loss 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 predatory behavior from other traders. In reality, your order can:

· Disrupt the order book,

· Attract or repel other traders,

· Cause non-linear slippage.

Backtesting assumes you are a pure liquidity extractor (price taker) with no influence.

Lastly, it does not simulate rate limits, API errors, order rejections, halts, timeouts, reconnects, or situations where the bot is busy and misses signals.

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

Infrastructure

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

However, there is still significant room for improvement:

· Using Rust instead of JavaScript will provide much better performance and processing time.

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

· Deploying on a VPS close to the Polymarket server will also significantly reduce latency.

I'm sure there are other optimization methods that I have not yet discovered. Currently, I am learning Rust as it is becoming an essential language in Web3 development.

Original Article Link