The Contract Doesn't Pay at the Price You're Watching: the Oracle, the Strike, and the Danger Zone
Published 2026-07-31 · By Drew Shelem
Your signal watches Binance spot, but the outcome is decided by the Chainlink aggregate at a preset instant — and near the strike these are different prices that determine win and loss
A new article in the cycle. The last one showed that the price you get on entry isn’t the one in the backtest. This one is about an even more insidious gap: the price at which the contract resolves isn’t the one you’re watching while you trade. You follow Binance spot, your signal is built on it, and at expiry bitcoin on Binance is above the opening price — you’re sure you won. But the contract doesn’t pay on Binance. It pays on the aggregated Chainlink oracle price at a specific timestamp — and it can read otherwise. Near the strike, your “win on spot” turns out to be a “loss on the oracle.” Let’s take apart what actually resolves the contract and where this danger zone hides.
You won on Binance — and lost at resolution
Here’s a plot that breaks intuition. You trade a “BTC up by the end of the 15-minute window” contract. Your bot watches Binance spot, the signal fired, you bought “up.” At expiry bitcoin on Binance is five dollars above the window’s opening price. You won — obviously, right?
Not obviously. The contract resolves not on the Binance spot you’re following. It resolves on the Chainlink oracle price — an aggregate of several exchanges, fixed at a specific moment in time. That price isn’t obligated to match your Binance spot: other exchanges may have stood slightly differently, and the oracle’s timestamp may have landed on a slightly different instant. If bitcoin near the strike is hovering close to the opening price, a difference of a couple of dollars between “your” spot and the oracle decides the outcome — and your obvious win becomes a loss.
This isn’t rare exotica but a systemic feature: the source of your signal and the source of resolution are different prices. Let’s take apart what the contract actually pays on, how far these prices diverge, and how because of this you calibrate to the oracle rather than the spot.
Step 1. What actually resolves the contract
First the facts — verified, not from memory. Polymarket’s crypto UP/DOWN markets resolve through Chainlink, with a two-part mechanism. First, Chainlink Data Streams: low-latency, timestamped price reports. Second, Chainlink Automation: it triggers on-chain settlement at a preset moment. The oracle aggregates the price from several verified sources (exchanges) — that is, the outcome is determined not by one exchange but by a price averaged across several, taken at a specific timestamp. This replaced the earlier “social voting” on the outcome and made resolution fast and resistant to manipulation of a single source.
From this, two consequences that matter for trading:
- The aggregate resolves it, not Binance. The price you watch on one exchange isn’t the one they pay on. The average across several pays.
- A specific timestamp resolves it. Not “somewhere at the end of the window,” but the oracle’s value at a preset moment. What the spot did a second before or after doesn’t matter; what matters is the aggregate’s value exactly at the settlement point.
A useful fact: this oracle feed is observable in real time — Polymarket serves it through its real-time data service. That is, you can watch exactly the price that will resolve the contract, rather than guessing from Binance.
Step 2. How far the oracle and spot diverge — and where
Since the aggregate at a timestamp resolves it, while the signal watches the spot, there’s a difference between them. How important is it? The key is that it’s almost always small — but near the strike it decides everything. Let’s look at a model (I took the divergence magnitude illustratively — you have to measure your own):
| How often the oracle and spot give a DIFFERENT outcome | Share |
|---|---|
| Across all contracts | 6.3% |
| Near the strike: move to resolution < 0.5 of typical | 16% |
| Near the strike: move < 0.2 of typical | 32% |
| Near the strike: move < 0.1 of typical | 40% |
It reads like this. If bitcoin by resolution moved far from the strike — the oracle and spot agree, the difference doesn’t matter, you won on both. But the closer the price is to the strike at the moment of resolution, the more often they diverge: in the narrow zone near the strike (a move less than a tenth of typical) the outcome on the oracle differs from the outcome on the spot in 40% of cases — nearly a coin flip. This is the danger zone: contracts that, by resolution, stand close to the opening price. There your spot “win” is, with high probability, an oracle loss, and vice versa.
The practical meaning is harsh: near the strike, don’t trust your spot. A contract you “won” by a hair on Binance isn’t a win but a coin flip on the oracle-spot difference. There’s no edge there, only the noise of the resolution source.
Step 3. How to calibrate to the oracle if the backtester has no oracle data
Here’s an important practical subtlety, easy to get wrong. “Calibrate to the oracle” sounds as if you need the historical Chainlink oracle price — and the backtester doesn’t have it, it has only Polymarket and Binance. This resolves simply.
You don’t need the oracle price. You need the fact of the outcome — and you have it. Every completed contract on Polymarket has a recorded result: up won or down. That result is already the oracle’s verdict, baked into it. So calibrating to the oracle = taking as your label the real Polymarket settlement, not the outcome you computed from Binance spot.
Here’s the mistake you must not make: if your backtester determines the outcome itself — “Binance spot at resolution is above the open, so up won” — it labels by the spot, and near the strike that diverges from what actually paid. But if you take the label from the actual Polymarket settlement, the calibration is automatically on the oracle: win-rate-at-price, Brier, edge — everything is computed against the real outcome, and that’s the oracle’s. Let’s compare the two labels by Brier (lower is a more accurate forecast):
| What you calibrate against | Brier (lower = more accurate) |
|---|---|
| Label by Binance spot (you computed the outcome) | 0.0628 |
| Label by the actual Polymarket settlement (= the oracle) | 0.0443 |
The difference sits entirely near the strike: far from it the spot label and the real outcome coincide, while in the danger zone the spot label lies, and a model trained on it is penalized. This is exactly the principle from the article on strategy types — calibrate to Polymarket’s resolution, not to the spot — and now it’s doable with what you have: take the outcome from Polymarket’s settlement, don’t compute it from Binance.
And you’ll measure the danger zone from those same two sources. For each historical contract, compare: what Binance spot said at the moment of resolution (up/down by the distance to the strike) against how the contract actually resolved on Polymarket. The share of mismatches near the strike is your measured danger zone, with no oracle price at all. The synthetic above showed the shape (the divergence grows near the strike); this is how you get your real numbers from Binance + Polymarket.
The oracle’s RTDS feed is about live trading, not the backtest. In real time, watching the price about to resolve the contract is useful — it’s closer to the outcome than Binance alone. But for calibrating history it isn’t needed: you have the fact of the outcome itself, and it’s better than any proxy.
What would refute this — and what to do about it
The condition on which the thesis would collapse (and didn’t). If the oracle always matched the spot — the resolution source wouldn’t matter, and the spot signal would be honest all the way. But across all contracts the outcome diverges in 6.3% of cases, and near the strike up to 40%. And if the spot label were as accurate as the oracle label — calibrating to the oracle would be a nitpick. But the spot label’s Brier is noticeably worse. Both attempts confirmed: the resolution source is a separate, not-free variable.
What to do — four rules.
- Take the outcome label from Polymarket’s settlement, don’t compute it from the spot. Then win rate, Brier, and edge are automatically calibrated to the oracle — the oracle price isn’t needed for this, the fact of the outcome is, and you have it.
- Mark the danger zone near the strike and avoid it or cut the bet in it. Contracts standing close to the open by resolution are a lottery on the oracle-spot difference, not an edge. Don’t confuse “won by a hair on the spot” with a win.
- Measure your divergence from Binance + Polymarket. For each contract: the spot outcome at resolution against Polymarket’s actual settlement. The share of mismatches near the strike is the width of your danger zone; no oracle price required.
- Remember the timestamp. What matters is the aggregate’s value at the settlement point, not what flashed on the spot a moment before. The last seconds of the window are a separate time-alignment risk.
What I don’t know, and where the limits are
- The divergence magnitude is empirical; I took it illustratively. The real one depends on the composition of exchanges in the aggregate, volatility, and timestamp accuracy; measure your own, on your resolutions.
- The oracle mechanics are a volatile parameter. The exact set of sources, the Data Streams update frequency, the settlement moment can change; verify in the current Polymarket and Chainlink documentation as of the date, don’t rely on this article (the facts are verified as of writing, but that goes stale).
- I don’t know the exact width of your danger zone — it follows from your measured divergence; the synthetic shows the shape (it grows near the strike), not a specific threshold for your market.
- The timestamp mechanics in detail (which exact moment, how the last second is captured) have to be verified on-chain — that’s a Tier-0 question for real resolutions, not for a retelling.
What to do tomorrow
- Check how your backtester labels the outcome. If it computes the outcome from Binance spot — switch it to Polymarket’s actual settlement. That is calibration to the oracle, and it doesn’t need the oracle price.
- Measure your danger zone from Binance + Polymarket. The spot outcome at resolution against the real settlement — the share of mismatches near the strike gives the width of the zone where the spot lies.
- In the danger zone, don’t trade for an edge — there isn’t one. Close to the strike the outcome is decided by source noise; cut the bet or skip.
- Account for the timestamp, especially in the last seconds. What pays is the aggregate at the settlement point; align your model to that moment.
- Check calibration and the danger zone without risking money. You can run a model against Polymarket’s actual outcome and see the danger zone near the strike in paper mode — free, before any subscription.
FAQ
I can see BTC on Binance is above the open — how could I have lost? Because it’s not Binance that pays, but the Chainlink aggregate at a specific timestamp. Other exchanges in the aggregate may have stood slightly differently, and the moment of the snapshot may have landed on a different instant. If you won on the spot “by a hair,” near the strike that’s often an oracle loss.
How common a problem is this? Far from the strike — almost never: the oracle and spot agree. All the danger is near the strike: in the narrow zone around the opening price the outcome on the oracle differs from the spot up to 40% of the time. Across all contracts it’s about 6%, but it’s concentrated in exactly the near-strike trades.
What does “calibrate to the oracle” mean if I don’t have the oracle price? It isn’t needed. Take as your outcome label the actual Polymarket settlement (it exists for every completed contract), not the outcome you computed from Binance spot. Polymarket’s settlement is already the oracle’s verdict, so win rate, Brier, and edge are automatically calibrated to it. The mistake is labeling the outcome by the spot; the fix is labeling by the real settlement.
Then what are the oracle price and RTDS even for? For live trading: in real time, watching the price about to resolve the contract is useful — it’s closer to the outcome than Binance alone. For the backtest and calibration it isn’t needed: there you have the fact of the outcome itself, and it’s better than any proxy.
How do I protect against the danger zone? Mark the contracts standing close to the strike by resolution and don’t count them as an edge — cut the bet or skip. Your measured size of the oracle-spot divergence sets the width of this zone.
Disclaimer
This material is educational and is not financial advice. Past results do not predict future results. Trading on prediction markets carries real risk, up to and including the total loss of capital. The resolution mechanics (oracle, sources, timestamp) may change — verify the current Polymarket and Chainlink documentation. Access to Polymarket is restricted or prohibited in some jurisdictions — verify legality where you live before trading.