Polymarket's New Rules Released: How to Build a New Trading Bot
- Core Viewpoint: After Polymarket removed the 500ms delay and introduced dynamic fees, the profit model for trading bots has fundamentally shifted. The core advantage has moved from taker arbitrage to providing liquidity as a maker, generating profits through rebates and spreads.
- Key Elements:
- Rule Changes: The 500ms taker delay has been removed, allowing taker orders to execute immediately; crypto markets have introduced dynamic taker fees based on probability, peaking at approximately 1.56%.
- New Profit Core: Becoming a maker allows for zero fees and earns USDC rebates. With the delay removed, limit orders fill faster, enabling top-tier bots to profit from rebates alone.
- Technical Architecture Essentials: Must use WebSocket instead of REST for real-time data; order signatures must include the `feeRateBps` field; requires establishing an ultra-fast cancel/replace loop (target <100ms).
- Strategy Example: In a 5-minute BTC market, about 10 seconds before the window closes, place maker orders on the side with a high win probability (e.g., at $0.90–0.95) based on the determined direction, profiting from settlement and rebates.
- Fatal Errors: Include using REST, omitting the fee field in signatures, operating on high-latency networks, market-making in the 50% probability zone without risk management, and persisting with old taker arbitrage logic.
Editor's Note: Polymarket removed the 500ms delay without prior announcement and introduced dynamic fees, rendering a large number of existing bots obsolete overnight. This article systematically outlines the correct way to build trading bots under the new rules, covering fee mechanisms, order signing, market-making logic, and low-latency architecture, providing a clear and actionable path.
After publication, the article received 1.1M views, sparking widespread discussion. Under the new Polymarket rules, the advantage is shifting from taker arbitrage to long-term structures centered around market-making and liquidity provision.
The following is the original article:
Polymarket Quietly Removed the 500ms Delay
Let's get this straight: How to build a bot that actually runs and makes money under the new rules.
Two days ago, Polymarket removed the 500ms taker quote delay in crypto markets. No announcement, no warning. Overnight, half the bots on the platform became ineffective. But at the same time, this created the biggest opportunity window for new bots since Polymarket's launch.
Today, I will explain in detail: how to build a bot that still works under the new rules.
Because every strategy you saw before February 18th is now outdated.
If you ask an AI model to write Polymarket bot code for you now, it will give you a solution based on the old rules: REST polling, no fee handling, completely unaware that the 500ms buffer no longer exists.
Such a bot will start losing money from its very first trade.
Let me explain: what exactly changed, and how to redesign bots around these changes.
What Changed?
Over the past two months, three key changes occurred:
1. The 500ms taker delay was removed (February 18, 2026)
In the past, all taker orders waited 500ms before execution. Market makers relied on this buffer time to cancel "stale" quotes, which was almost like a free insurance mechanism.
Now it's different. Taker orders are executed immediately, with no cancellation window.
2. Dynamic taker fees introduced in crypto markets (January 2026)
The 15-minute and 5-minute crypto markets now charge taker fees. The formula is: Fee = C × 0.25 × (p × (1 - p))²
Fee peak: Approximately 1.56% around 50% probability.
Fee approaches 0 in extreme probability ranges (close to 0 or 1).
Remember that bot that made $515,000 in a month with a 99% win rate by arbitraging price delays between Binance and Polymarket?
That strategy is completely dead. Because the fee alone is already higher than the arbitrageable spread.
What is the New Meta?
In one sentence: Be a maker, not a taker.
The reason is simple:
· Makers pay zero fees.
· Makers earn daily USDC rebates (subsidized by taker fees).
· With the 500ms delay gone, maker orders fill even faster.
The top bots now profit just from rebates, without even needing to capture spreads. If you're still running a taker bot, you're facing an ever-increasing fee curve. Around 50% probability, you need an edge of over 1.56% just to break even.
Good luck.
So, how should a truly viable bot be built in 2026?
Here is a design framework for a bot architecture that remains effective in 2026:
Core Components:
1. Use WebSocket, not REST
REST polling is completely obsolete. By the time your HTTP request completes a round trip, the opportunity is long gone. You need real-time order book data streams via WebSocket, not intermittent pulls.
2. Fee-aware order signing
This is a new requirement that didn't exist before. Now, your signed order payload must include the `feeRateBps` field. If you omit this field, orders will be rejected outright in markets with fees enabled.
3. Ultra-fast cancel/replace loop
With the 500ms buffer gone: if your cancel-replace cycle exceeds 200ms, you will suffer from adverse selection. Others will eat your stale quotes before you can update them.
How to Build It
1. Get Your Private Key
Use the same private key you use to log into Polymarket (EOA / MetaMask / Hardware Wallet).
export POLYMARKET_PRIVATE_KEY="0xyour_private_key_here"
2. Set Up Approvals (One-time operation)
Before Polymarket can execute your trades, you need to approve the following contracts: USDC, Conditional Tokens.
This only needs to be done once per wallet.
3. Connect to the CLOB (Central 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 (zero allocation on hot path, SIMD JSON parsing, ~21% performance boost)
· polymarket-client-sdk (Official Polymarket Rust SDK)
· polymarket-hft (Complete HFT framework, integrates CLOB + WebSocket)
The choice doesn't matter much; the key is to pick a solution you can deploy and run the fastest.
4. Query the Fee Rate Before Every Order
GET /fee-rate?tokenID={token_id}
Never hardcode fees.
Fees are market-specific, and Polymarket can adjust them at any time.
5. Include the Fee Field in Order Signing
When signing an order, the fee field must be included in the payload. Missing this will prevent the order from being accepted in fee-enabled markets.
{
"salt": "...",
"maker": "0x...",
"signer": "0x...",
"taker": "0x...",
"tokenId": "...",
"makerAmount": "50000000",
"takerAmount": "100000000",
"feeRateBps": "150"
}
The CLOB validates your order signature based on `feeRateBps`. If the fee rate in your signature doesn't match the current actual rate, the order is rejected.
If you use the official SDK (Python or Rust), this logic is handled automatically. But if you implement your own signing logic, you must handle this yourself, or your orders won't go through.
6. Place Maker Orders on Both Sides
Provide liquidity to the market by placing limit orders: on both YES and NO tokens; simultaneously place BUY and SELL orders. This is the core way you earn rebates.
7. Run a Cancel/Replace Loop
You need to monitor simultaneously: external price feeds (e.g., Binance WebSocket); your current open orders on Polymarket.
Once the price changes: immediately cancel stale quotes; place new orders at the updated price. The goal: keep the entire cycle under 100ms.
Special Note on 5-Minute Markets
The 5-minute BTC up/down markets are deterministic.
You can directly calculate the specific market corresponding to a timestamp:
There are 288 markets per day. Each one is a fresh opportunity.
Currently validated effective strategy: At T–10 seconds before the window closes, the BTC direction is already about 85% determined, but Polymarket odds haven't fully reflected this information.
The method: On the side with higher probability; place maker orders at a price of $0.90–$0.95.
If filled: At settlement, each contract yields $0.05–$0.10 profit; zero fees; plus you earn rebates.
The real edge comes from: determining BTC's direction faster than other market makers and placing your orders earlier.
Common Mistakes That Will "Take You Out"
· Still using REST instead of WebSocket.
· Not including `feeRateBps` in order signing.
· Running the bot on home Wi-Fi (150ms+ latency vs. <5ms for data center VPS).
· Market-making near the 50% probability range without considering adverse selection risk.
· Hardcoding fee rates.
· Not merging YES / NO positions (locking up capital).
· Still using the 2025 taker arbitrage mindset.
The Right Way to Use AI
The technical part ends here. Now you have the: architecture design, fee calculation method, new market rules.
Next, open Claude or any reliable AI model, and give it a sufficiently clear and specific task description, for example: "Here is Polymarket's SDK. Please write a maker bot for the 5-minute BTC market: Listens to Binance WebSocket for prices. Places maker orders on both YES / NO sides. Includes feeRateBps in order signing. Uses WebSocket to get order book data. Keeps cancel/replace cycle under 100ms."
The correct workflow is: You define the tech stack, infrastructure, and constraints; the AI generates the specific strategy and implementation logic on top of that.
Of course, no matter how perfectly you describe the bot's logic, you must test it before going live. Especially at this stage, where fees are already materially eroding profit margins, backtesting under the real fee curve is a mandatory step before deployment.
The bots that will truly win in 2026 are not the fastest takers, but the best liquidity providers.
Build your system in this direction.
