How to Verify an Oracle's Resolution Data On-Chain

11 October 2026

To verify an oracle's resolution data on-chain, you read the relevant blockchain transaction where the oracle submitted its outcome, cross-check that data against the prediction-markets/prediction-market-smart-contract-exploit-risk/">smart contract's stored resolution, and confirm it matches the real-world event you expected. The process is straightforward but requires attention to the specific market contract and the oracle type used.

What resolution data looks like on-chain

When an oracle resolves a prediction market, it submits a transaction that calls a function on the market's smart contract. That function passes an outcome identifier - usually a single byte or a bytes32 hash - corresponding to a specific result (e.g., "Yes" or "No" for a binary market). The contract then updates its internal state, locking the outcome so traders can redeem their shares.

On Ethereum or Polygon, you can see this transaction by searching the market contract address on a block explorer like Etherscan or Polygonscan. Look for the function name such as resolve, setOutcome, or reportPayouts, depending on the platform. The input data typically contains the outcome value.

Steps to Verify the Resolution

1. Find the Market Contract and Resolution Transaction

• Go to the prediction market platform (e.g., Polymarket, Augur, or a custom dApp) and locate the market's unique identifier - often a hex string or numeric ID.
• Use that ID on a block explorer to find the market's deployed contract address. Many platforms list this directly on the market page.
• Filter the contract's transaction history for the resolution call. You can search by function signature or look for transactions around the expiry time.

2. Read the Outcome Parameter

• Open the resolution transaction and decode the Input Data field. Block explorers often show decoded parameters automatically. The outcome parameter is usually a number (e.g., 0 for No, 1 for Yes) or a hash mapping to a specific categorical result.
• Compare this value to the market's predefined outcomes. For example, in a binary market where outcome 0 is "Trump wins" and outcome 1 is "Biden wins", if the oracle submitted 1, that means Biden wins.

3. Verify the Oracle Source

• Check the transaction sender address. This should match the oracle contract address or a known oracle operator, depending on the system. For UMA's optimistic oracle, the resolution is submitted by a disputer or prover; for Kleros, it comes from a governance vote.
• Read the oracle's own contract to see how it derives the outcome. Some oracles (like Chainlink) push data from external APIs; others (like UMA) rely on a dispute window where anyone can challenge the result.

4. Confirm the Contract State Reflects the Resolution

• After the resolution transaction, call the market contract's getOutcome or isResolved function using a read method on the block explorer. This returns the stored outcome and a boolean indicating resolution.
• If the contract shows the same outcome as the oracle transaction, the resolution is consistent. Discrepancies may indicate a failed attempt or a dispute pending.

Tools That Help

• Etherscan's Read Contract feature: Allows you to call any contract's view functions directly, no transaction needed.
• The Graph: Platforms like Polymarket index market data via subgraphs. You can query the resolved outcome using GraphQL without manually scanning blocks.
• Dune Analytics: Community-built dashboards often display oracle resolution data for popular markets.

What to watch for

• Oracle type differences: UMA's optimistic oracle allows a 2-hour challenge window after resolution. If you verify during that window, the outcome might still change. Check the dispute status field in the contract.
• Duplicate resolutions: Rarely, an oracle may submit multiple transactions. The last accepted one is valid. Check the transaction timestamp and any dispute events.
• Bridge delays: If the market runs on a Layer 2 like Polygon, but the oracle operates on Ethereum, resolution data must cross a bridge. Allow time for finality and confirm the bridged transaction on the destination chain.

A Practical Example

Suppose you see a market "Will BTC exceed $50k on Dec 31, 2026?" resolved as "Yes". On Polymarket, the resolvers contract calls reportPayouts with an outcome array [0, 1] (0 for No shares, 1 for Yes shares). You verify:

1. The transaction hash on Polygonscan shows input 0x... decoded as outcome: [0, 1].
2. The sender is the UMA oracle contract (address confirmed from UMA's docs).
3. You call getOutcome() on the market contract and get true (resolved) with value 1.
4. You check Bitcoin price data for Dec 31, 2026 from a trusted source. If it exceeds $50k, the oracle matches reality.

If any step fails - mismatched outcome, wrong sender, or unresolved contract - the oracle data is questionable. Contact the market creator or check platform dispute channels.

Why Verification Matters

Smart contracts execute exactly as written, but oracles are subject to manipulation or error. Verifying on-chain gives you cryptographic proof of the resolution, independent of the platform's frontend. This is the only way to be certain your share redemptions will work correctly.

Back to prediction markets