Why My Polymarket Bot Watches Chainlink, Not Binance - The Oracle Gap That Changes Every Close Trade

For the first few weeks I was running my bot, I was comparing Polymarket prices against Binance spot. Seemed obvious. BTC/USD is BTC/USD, right?

Wrong. Cost me real money before I figured out why.

The bot is open source if you want to dig into the code: https://github.com/MalcolmMcGough/polymarket-trading-bot-scalping

The thing I didn't understand about how Polymarket actually resolves

Polymarket doesn't use Binance to settle crypto markets. They use Chainlink.

Specifically - Chainlink Data Streams combined with Chainlink Automation. The Data Streams deliver timestamped price reports at sub-second intervals. The Automation layer handles the on-chain settlement trigger at a predetermined time. The whole cycle - price confirmation, contract resolution, USDC payout - runs without human input.

This matters more than it sounds.

Chainlink aggregates across multiple independent node operators. Binance is one exchange. Those two numbers are usually close. But "usually close" is not the same as "identical at the exact millisecond a market closes." And in a binary market, the difference between $69,999 and $70,001 is the difference between winning and losing every position you're holding.

What actually happens at resolution

When a 5-minute or 15-minute crypto market closes on Polymarket, the settlement price is whatever Chainlink's oracle reports at that exact timestamp. Not Binance's last trade. Not a VWAP. Not a mid-price from your data provider.

The Chainlink oracle price. That's it.

So if your bot is monitoring Binance to decide whether a market is mispriced, you're comparing the wrong thing. You need to be watching what Chainlink is going to report - which means watching Chainlink's actual feed, not an exchange feed and hoping they're the same.

Here's the gap I kept running into:

During high-volatility windows - news events, macro data drops, liquidation cascades - Binance spot and Chainlink's aggregated price can diverge by 0.3% to 0.8% for 10 to 30 seconds. That sounds tiny. In a binary market resolving at that exact moment, it's everything.

How I changed the bot's data layer

Originally the price feed was:

# what I was doing before — wrong
def get_reference_price(symbol):
    ticker = binance_client.get_symbol_ticker(symbol=symbol)
    return float(ticker['price'])

Simple. Fast. Wrong reference point.

The fix was pulling directly from Chainlink's Data Streams API instead of exchange feeds for markets where Chainlink is the resolution oracle. Now the bot compares Polymarket implied probability against what Chainlink is actually reporting, not what Binance last traded.

# simplified version of what replaced it
def get_chainlink_price(pair_id):
    response = requests.get(
        f"{CHAINLINK_STREAMS_ENDPOINT}/price/{pair_id}",
        headers={"Authorization": f"Bearer {CL_API_KEY}"}
    )
    data = response.json()
    return {
        "price": float(data["answer"]) / 1e8,
        "timestamp": data["updatedAt"],
        "round_id": data["roundId"]
    }

The updatedAt field matters as much as the price. If the Chainlink feed hasn't updated in the last 2-3 seconds and a market is resolving in 30 seconds, you're flying blind. The bot now flags staleness explicitly.

The resolution timestamp problem

Here's another thing that bit me: the bot was calculating "time to resolution" wrong.

I was using the market's listed end time and assuming that's when settlement happens. It's not exactly when settlement happens. Chainlink Automation triggers the on-chain resolution, which means there's a small execution delay - usually a few seconds, sometimes more if the Polygon network is congested.

So the actual settlement price isn't the Chainlink price at the listed end time. It's the Chainlink price at the block where the Automation call lands.

For most trades this is a rounding error. For positions taken in the last 60 seconds before resolution, it's a variable you need to account for. The bot now reduces position size automatically in the final 90 seconds of any market. Not because the edge disappears - sometimes it gets bigger - but because the timing uncertainty increases and the price I'm using as reference might be 5-10 seconds stale by the time the actual settlement block lands.

What this changed in practice

Before switching to Chainlink feeds as the reference:

Win rate on 5-minute markets: 52%
Most losses came from markets that resolved at exactly the wrong moment during volatility

After:

Win rate on 5-minute markets: 57-58%
Close trades are still a coin flip, but I'm no longer getting systematically wrong-footed on resolution prices

The 5-6% improvement sounds modest. On binary markets at any reasonable volume, it's the difference between the strategy being viable or not.

The MEV problem you'll run into eventually

One thing I didn't fully appreciate until I looked at the data: on 5-minute Chainlink-resolved markets, there are bots that read both the Chainlink feed and Polymarket's order book simultaneously and lock in risk-free arb in the final seconds before resolution. These are well-capitalized MEV searchers running co-located infrastructure.

You're not going to beat them on speed. What this means practically: in the last 10-15 seconds of a 5-minute market, the order book gets weird. Spreads widen, liquidity disappears, prices jump. The bot ignores that window entirely now. If I don't have a position going into the last 15 seconds, I'm not opening one.

Which markets still use UMA instead of Chainlink

Not all Polymarket markets use Chainlink. The oracle split matters:

Chainlink-resolved:

Crypto price markets (5-min, 15-min, hourly, daily, weekly)
Some sports and weather feeds

UMA-resolved (optimistic oracle):

Politics
Geopolitics
Most "will X happen" markets
Anything subjective

The bot's logic for UMA markets is completely different. There's no oracle feed to watch - you're trading on information and crowd probability, not price convergence. I run separate strategies for each. The Chainlink feed approach described in this post only applies to price-based markets.

What I'd do differently from the start

If I was rebuilding the data layer from scratch:

Pull the resolution oracle type from the market contract before building any strategy
For Chainlink markets, subscribe to the actual feed - don't proxy through a CEX
Track updatedAt on every price pull. A stale feed near resolution is a red flag, not a data point
Hard cutoff for new positions at T-90 seconds. Non-negotiable
Don't trade 5-minute markets during macro events (FOMC, CPI, NFP). The Chainlink aggregation lag during sudden price moves is real and it will catch you

The bot's still running. Full code at https://github.com/MalcolmMcGough/polymarket-trading-bot-scalping - the oracle handling is in feeds/chainlink.py if you want to skip straight to the relevant part.

Willing to answer questions in the comments about the feed implementation or the resolution timing logic.

推荐订阅源

DEV Community