作者：区块律动
Original title: How to build a Polymarket bot (after new rules edition)
Original author: @_dominatos
Compiled by: Peggy, BlockBeats
Editor's Note: Polymarket removed the 500ms latency and introduced dynamic fees without prior notice, rendering many existing bots ineffective overnight. This article systematically outlines the correct way to build trading bots under the new rules, from fee mechanisms and order signing to market-making logic and low-latency architecture, providing a clear and actionable path.
The article garnered 1.1 million views after its publication, sparking widespread discussion. Under the new Polymarket rules, the advantage is shifting from taker arbitrage to a long-term structure centered on market making and liquidity provision.
The following is the original text:
Polymarket quietly removed the 500ms latency.
The following explains how to build a truly functional and profitable robot under the new rules.
Two days ago, Polymarket removed the 500ms taker quote delay from its crypto marketplace. There was no announcement, no warning. Overnight, half the bots on the platform became unusable. But at the same time, this created the biggest window of opportunity for new bots since Polymarket's launch.
Today I will explain in detail how to build a robot that still works under the new rules.
Because all the solutions you saw before February 18th are now outdated.
If you were to ask an AI model to write code for your Polymarket bot now, it would still provide the old-fashioned solution: REST polling, no handling of fees, and complete unaware that the 500ms buffer no longer exists.
Such a robot will lose money from its very first transaction.
Now I will explain what has changed and how to redesign the robot around these changes.
What changes have occurred?
Three key changes have occurred in the past two months:
The 1,500 ms taker latency was removed (February 18, 2026).
Previously, all taker orders would wait 500 milliseconds before execution. Market makers relied on this buffer time to cancel "expired" quotes, which was almost like a free insurance mechanism.
Things are different now. Taker orders are executed immediately, with no cancellation window.
2. Crypto Markets Introduce Dynamic Taker Fees (January 2026)
The 15-minute and 5-minute crypto markets now charge takers a fee, calculated as follows: Fee = C × 0.25 × (p × (1 - p))²
Peak transaction fees: Approximately 1.56% with a 50% probability.
In extreme probability ranges (close to 0 or 1), transaction fees are close to 0.
Remember that bot that made $515,000 a month with a 99% win rate by arbitrage between Binance and Polymarket price delays?
That strategy is completely dead. The transaction fees alone are already higher than the arbitrage spread.
What is the new Meta?
In short: Be a maker, not a taker.
The reason is simple:
Maker does not require any transaction fees.
Maker can earn USDC rebates daily (subsidized by taker transaction fees).
• After a 500ms delay in cancellation, Maker's order execution speed is actually faster.
The top-tier bots nowadays can profit solely from rebates, without even needing to profit from price differences. If you're still using a taker bot, you're facing a constantly rising fee curve. Around a 50% probability, you need an advantage of at least 1.56% just to break even.
Good luck.
So, what should a truly feasible robot look like in 2026?
Below is a robot architecture design approach that will remain valid in 2026:
Core components:
1. Use WebSocket instead of REST.
REST polling is completely ineffective. By the time your HTTP request completes a round trip, the opportunity has long passed. What you need is a real-time order book data stream based on WebSocket, not intermittent pulls.
2. Fee-aware order signing
This is a new requirement that didn't exist before. Now, the feeRateBps field must be included in the payload of your signed orders. If you omit this field, your order will be rejected outright in markets where fees are enabled.
3. Rapid order cancellation/replacement loop
After the 500ms buffer is removed: If your order cancellation-resubmission process takes longer than 200ms, you will be subject to "adverse selection." Others will take your expired orders before you can update your quotes.
How to build
1. Obtain your private key
You can use the same private key you use to log in to Polymarket (EOA / MetaMask / hardware wallet).
export POLYMARKET_PRIVATE_KEY="0xyour_private_key_here"
2. Configure authorization (one-time operation)
Before Polymarket can execute your trades, you need to authorize the following contracts: USDC and conditional tokens.
Each wallet only needs to do this once.
3. Connect to CLOB (Central Price Limit Order Book)
The official Python client can be used directly: pip install py-clob-client
However, there are now faster options in the Rust ecosystem:
• polyfill-rs (hot path zero allocation, SIMD JSON parsing, performance improvement of approximately 21%)
• polymarket-client-sdk (Polymarket's official Rust SDK)
• polymarket-hft (a complete HFT framework, integrating CLOB + WebSocket)
Which one you choose isn't important; the key is to choose the solution that you can get online and running the fastest.
4. Check the commission rate before placing each order.
GET /fee-rate?tokenID={token_id}
Never hardcode transaction fees.
Transaction fees vary depending on the market, and Polymarket can adjust them at any time.
5. Include a transaction fee field in the order signature.
When signing an order, the transaction fee field must be written into the payload. Without this field, the order will not be accepted in markets where transaction fees are enabled.
{
"salt": "...",
"maker": "0x...",
"signer": "0x...",
"taker": "0x...",
"tokenId": "...",
"makerAmount": "50000000",
"takerAmount": "100000000",
"feeRateBps": "150"
}
CLOB verifies your order signature based on feeRateBps. If the rate in the signature does not match the current actual rate, the order will be rejected immediately.
If you are using the official SDK (Python or Rust), this logic will be handled automatically; however, if you are implementing the signature logic yourself, you must handle this yourself, otherwise the order will not be sent out at all.
6. Place maker orders on both the buy and sell sides simultaneously.
Provide liquidity to the market by placing limit orders: on both YES and NO tokens; simultaneously placing BUY and SELL orders. This is the core way you earn rebates.
7. Run the cancel/replace loop.
You need to monitor: external price sources (such as Binance's WebSocket); and your current orders on Polymarket.
If the price changes: immediately cancel the expired quote; re-place the order at the new price. The goal is to keep the entire cycle within 100ms.
Special Notes on 5-Minute Markets
The 5-minute timeframe for BTC price movements is predictable.
You can directly calculate the specific market using only the timestamp:
There are 288 markets every day. Each one represents a brand new opportunity.
The currently validated strategy is that the direction of BTC's rise or fall is approximately 85% certain 10 seconds before the window ends, but Polymarket's odds do not yet fully reflect this information.
The strategy is to place a maker order at a price of $0.90–$0.95 on the side with the higher probability of winning.
If the contract is closed: you will receive a profit of $0.05–$0.10 per contract at settlement; zero commission; and you will also receive rebates.
The real advantage comes from the fact that you can determine the direction of BTC faster than other market makers and place your orders earlier.
Common mistakes that will directly "eliminate you"
• Still using REST, not WebSocket
The order signature does not include feeRateBps.
• Running the bot on home Wi-Fi (latency over 150ms, compared to<5ms on a data center VPS)
• Market making was conducted within a range with a probability close to 50%, without considering the risk of adverse selection.
Hard-coded transaction fee rate
• Failure to merge YES/NO positions (resulting in funds being locked up)
Still using the same taker arbitrage strategy from 2025?
The correct way to use AI
That concludes the technical section. You now have a grasp of: architecture design fees, calculation methods, and new market rules.
Next, open Claude or any reliable AI model and give it a clear and specific task description, such as: "This is the Polymarket SDK. Please help me write a maker bot for the 5-minute BTC market: listen to Binance WebSocket to get the price, place maker orders on both YES and NO sides simultaneously, include feeRateBps in the order signature, use WebSocket to get order book data, and keep the order cancellation/re-placement loop within 100ms."
The correct workflow is: you define the technology stack, infrastructure, and constraints, and AI generates specific strategies and implementation logic on top of that.
Of course, no matter how perfectly you describe the robot's logic, you must test it before going live. Especially at this stage, transaction fees have begun to substantially erode profit margins, and backtesting under the actual transaction fee curve has become a mandatory course before going live.
The robots that will truly win in 2026 will not be the fastest takers, but the best liquidity providers.
Please build your system in this direction.
