Who runs prediction market creation and resolution?

Prediction market operators and event-contract platforms that list new markets on a fixed calendar.

Goldsky

Prediction market creation and resolution

Talk to our team

What is prediction market creation and resolution?

Prediction market creation and resolution is the work of opening each market onchain and, once it closes, reporting the outcome from the source the market named, so holders of the winning side can redeem; the second half is often called prediction market resolution.

Prediction market operators run it for every market they list, and a resolution that’s late, wrong or never confirmed leaves traders holding positions they can’t redeem.

Goldsky Compose runs the schedule, fetches outcome data and sends the onchain writes, retrying and logging each one; the questions, sources and resolution rules stay with your team.

How prediction markets are created and resolved

The diagram follows one cycle, from the markets your team defines to traders redeeming after resolution, and shows who does each step. Your setup may differ.

Define the marketsQuestions, sources and close times

ComposeFetch outcome dataOn schedule, from each market’s source

ComposeResolve ended marketsOutcomes reported onchain

ComposeLaunch new marketsNew conditions prepared onchain

Traders trade and redeemWinners redeem after resolution

ComposeRecord each resolutionEvery outcome reported, with its trace

Goldsky

How to create and resolve prediction markets

A set of TypeScript tasks that Goldsky hosts runs your market calendar: on each scheduled run it fetches outcome data, resolves the markets that have closed and opens the next ones onchain, retrying and logging every write.

What you’ll need

Goldsky Compose
A market contract, such as a conditional-tokens contract, that records an oracle address (the only address allowed to report outcomes)
An outcome data source for each market, reachable over HTTP
Written resolution rules for each market

Define each market
A market is a question with a fixed close time and an agreed source for the answer, and traders need all three before they trade.
Your team writes the question, the outcomes, the data source and the rule that turns the source’s answer into an outcome. If the rule leaves room for interpretation, a disputed result can’t be settled from the record alone.
Set up the wallet that reports outcomes
Handled by Goldsky Compose
Only the address recorded as a market’s oracle can report its outcome, so that address has to belong to the system that resolves markets.
The wallet that opens each market is usually recorded as its oracle, so it has to be fixed before the first launch. If its key is lost or replaced without updating the contract, open markets can’t be resolved.
With Goldsky, a task can create a named Compose wallet that signs both the market’s creation and its resolution, so the oracle address stays the same across runs. To sign with a key you already hold, a webhook wallet sends a signing endpoint you host each transaction as a UserOperation to sign, plus a one-time EIP-7702 authorization on each chain.
Learn about Compose wallets (opens in a new tab)
Fetch the outcome when each market closes
Handled by Goldsky Compose
When a market closes, someone has to look up the answer from the source the market named.
The lookup has to read the named source at the close and keep the exact answer it got. If the source revises its figure later, a retry that reads it again can resolve the market differently.
A cron trigger starts the task on your schedule, and ctx.fetch reads the source with retries. Saving the closing value before sending the resolution, as the prediction market guide does, means a retry reuses the same answer.
Call external APIs from a task (opens in a new tab)
Resolve the markets that have ended
Handled by Goldsky Compose
Resolution writes the outcome onchain, which is what lets holders of the winning side redeem.
Each resolution has to land once and stay landed. A transaction can be dropped before it’s included, or removed when the chain replaces its newest blocks (a reorg), and a market that looks resolved in your app but not onchain leaves winners unable to redeem.
Goldsky Compose sends the report with writeContract, waits for the confirmations you set and, with onReorg set to replay, sends it again if a reorg removes it later.
Handle confirmations and reorgs (opens in a new tab)
Open the next markets
Handled by Goldsky Compose
New markets have to exist onchain before anyone can trade them.
Each market needs an ID derived from its own terms, so a retry finds the market it already created. If a retry produces a new ID, you end up with two markets for one question.
An orchestrator task can call separate launch and resolve tasks with callTask and keep each market’s state in a collection. If it restarts mid-run, calls that already finished return their saved results instead of running again.
Call one task from another (opens in a new tab)
Let traders trade and redeem
Once a market resolves, holders of the winning outcome exchange their positions for the payout.
Trading and redemption run on the market contract and need nothing from you, as long as the resolution is final. Until then, traders see a closed market they can’t redeem.
Keep a record of every resolution
Handled by Goldsky Compose
Traders and partners may ask why a market resolved the way it did, and the answer has to come from records.
The record ties the market’s terms to the source value read, the time it was read and the transaction that reported it. Without it, settling a dispute means rebuilding the run from scattered logs.
Compose records every ctx.fetch call a task makes, with its URL and response, alongside each transaction, so each resolution traces back to the value it used.
How fetch calls are recorded (opens in a new tab)