During the 2026 FIFA World Cup, prediction market platforms generated activity equivalent to an estimated 27% of legal US sportsbook volume, according to H2 Gambling Capital analysis reported by Bloomberg. At the start of the year that figure sat closer to 9%. Polymarket recorded more than $10.7 billion in trading volume in June alone and added over 174,000 new users, and its World Cup winner market became the largest single market in the platform's history.
Every operator with an audience and a payments rail has now had the same internal conversation. The question has moved from whether to add an event contract vertical to how.
We have just launched our own prediction market platform, and this piece covers the reasoning behind how we built it. It is written for operators at the scoping stage, and it spends most of its time on the two things that rarely make it into a scoping document.
What is not the Differentiator
Almost every vendor conversation in this category opens with the trading engine. Matching throughput, settlement architecture, risk management, concurrency under load.
These matter. They are also solved. Matching engines have been built and rebuilt across the financial exchange and gaming sectors for three decades, and the architectural patterns are well understood. Any competent vendor can supply one, and any competent internal team can build one given time.
If your differentiation strategy is a better order book, you do not have a differentiation strategy.
Two other things decide whether a prediction market works in practice, and both are usually treated as details to sort out after launch.
Problem One: A prediction market is an operations product
Before it is a trading product, a prediction market is an operations product.
Every contract has to be conceived, written, listed, priced continuously, monitored, and then resolved against evidence. That cycle repeats for every market on the platform, forever.
A single political market is a manageable manual task. A sports catalogue across multiple competitions is thousands of those cycles a week, running concurrently, with suspension windows measured in seconds and settlement following a final whistle by minutes.
There are two common responses to this. Both have a ceiling.
The Editorial Desk Ceiling
The first response is to hire well: a genuinely smart team writing markets by hand.
This produces excellent, distinctive questions. It is also capped in four ways that no amount of hiring fully solves.
Research time per market
Writing a market that resolves cleanly means defining the outcome unambiguously, identifying an authoritative source, setting a deadline that matches reality, and thinking through the edge cases. Done properly this takes time, and it takes it per market.
Overnight coverage
Breaking news does not respect a rota. Events that should have produced markets at 2am produce them at 9am, by which point the interest window has passed.
Language and region
An editorial desk covers the languages it speaks. Everything else stays uncovered, or arrives as a machine translation of a question written for a different audience.
Cost that scales with catalogue
Every additional market adds cost. There is no point at which the marginal market becomes free, which means catalogue size is permanently constrained by headcount budget.
The copying trap
The second response is to copy. Watch what the large platforms list, mirror it, ship it.
This is fast, cheap, and it is what most new platforms do. It also creates a strategic problem that worsens over time.
If your catalogue mirrors a larger platform's catalogue, you have given a user no reason to choose you. You are offering the same markets, slightly later, with less liquidity, on a less established brand. The only lever left is promotional spend, which is the most expensive and least durable form of differentiation there is.
Twelve months in, the operator copying markets is doing exactly the same work they were doing in month one, and offering exactly the same catalogue as every other operator running the same strategy.
What automation actually has to do
The answer is not less automation. It is automation an operator can constrain.
Pointing a language model at a news feed and generating a thousand questions is trivial and mostly counterproductive. Markets that are vague, off-category, duplicated or unresolvable damage a platform faster than having too few markets ever did. A user who opens a market and cannot work out what would make it resolve YES does not trade it, and trusts the next one slightly less.
Useful automation for prediction markets needs to do four things.
Generate continuously and originally, from live signals rather than from another platform's listings, so the catalogue is genuinely the operator's own.
Produce resolvable questions, meaning every generated market carries a clear deadline, an unambiguous outcome definition and a known authoritative source. This matters more than it sounds, and we return to it below.
Stay inside operator rules, covering market structure (binary or multi-option), outcome logic (single winner or multiple winning outcomes), resolution date limits, and category and language scope. Automation without constraint is the failure mode.
Improve from feedback, so that when a reviewer rejects a question as too broad or off-brand, the next generation cycle reflects that. Over months this compounds into a catalogue shaped by a specific team's editorial judgment, which is not something a competitor can copy.
This is what AI Market Creator was built to do.
Problem two: nobody plans for the cold start
This is the one we find operators are structurally blind to, and it is not a competence issue. It is an experience issue.
A sportsbook has never had an empty market
The book is the counterparty. A price exists because you set it. There has never been a moment in a sportsbook's operating history where a customer opened a market and found nothing to bet on. Thin interest shows up as low handle. It never shows up as a broken product.
So when a sportsbook team scopes an event contract vertical, they plan the things they have always had to plan: pricing, risk, compliance, user experience, acquisition. All correct, all necessary. Nobody adds "what happens if a user opens a market and there is nothing on the other side," because in twenty years of running a book, that has never been a thing that could happen.
An event contract exchange is the first product in most operators' careers where it can.
What the failure looks like
The launch goes fine. Markets are listed, the app works, the acquisition spend lands.
A user arrives, opens a market, and sees an empty order book. Or a spread wide enough that the trade is uneconomic before it starts. They do not file a complaint. They do not tell you why. They leave.
That market never attracts the volume that would have tightened the spread. The next user has the same experience. Meanwhile acquisition spend continues at full rate, buying people a first impression that teaches them the platform does not work.
Nothing about the product was wrong. It launched into a vacuum.
Why acquisition spend cannot fix it
Worth stating plainly, because this is where budgets get wasted.
If a user's first trade is a bad fill or an impossible fill, the acquisition spend that brought them has bought a churned account and a negative word-of-mouth event. Spending more accelerates the damage rather than solving it, because you are buying more people the same first impression.
Liquidity is not a marketing problem that marketing can solve. It is a product precondition.
What automated market making does about it
Automated market makers quote both sides of every listed contract from the moment of listing, so a user can always transact, subject to operator-defined size limits. That removes the empty-book scenario entirely.
The more interesting question is what happens next, because a naive AMM commits an operator's capital indefinitely across every market on the platform.
The design that matters has three properties.
Dynamic spread management
Spreads widen automatically in response to volatility, thin external reference pricing, time to resolution and inventory concentration, and tighten as confidence and organic depth improve.
Exposure and inventory control
Maximum inventory per contract, per category and in aggregate, with automated de-risking, so downside is bounded and known.
Progressive handoff
As organic order flow builds real depth on a contract, the AMM reduces its participation according to operator-defined thresholds, moving from primary liquidity provider to backstop. This confines the operator's ongoing capital commitment to the markets that genuinely need it.
The last one is the question to put to any vendor. An AMM that never steps back is a permanent capital line, not a launch mechanism. Our approach is covered in detail on the AMM engine page.
Why these are one problem, not two
This is the part that changes how the whole thing should be architected.
Automation determines whether you have a catalogue worth opening. Liquidity determines whether that catalogue is worth anything at all.
Get automation right and liquidity wrong, and you have a thousand automatically generated markets with nothing trading in any of them. You have automated your way into a worse problem, because you have multiplied the number of empty rooms a user can walk into.
Get liquidity right and automation wrong, and you have four excellent, liquid markets and no reason for anyone to come back tomorrow.
They are also mechanically the same loop. An automated market maker is continuous automated pricing, running on every listed contract, every second it is open. Treating liquidity as a commercial exercise the operator solves after launch, separate from the automation stack, is what produces platforms where the two are permanently out of step.
The third thing: settlement is where trust is decided
This deserves its own section, because it is the failure that does the most lasting damage.
Users see only a final label: YES or NO, this option won. What sits behind that label determines whether they trust the platform with the next trade.
A disputed settlement is not recoverable the way a thin order book is. An operator can fix liquidity in a week. An operator cannot un-disappoint a user who believes they were paid out wrongly, and in a market with real money in it, that user tells people.
Two things reduce that risk, and the first is upstream of the second.
Most settlement disputes originate at creation
A question written without a clear deadline, an unambiguous outcome definition or a known authoritative source is difficult to settle no matter how good the resolution process is. Ambiguity invisible on the day the question was written surfaces under an unusual outcome, and by then real money is on it.
Settlement needs to be evidence-led and auditable
The outcome should be supported by a stored record of what was checked, which sources agreed, when, and who reviewed it. The system should escalate to a human when sources conflict rather than picking one. And an operator should be able to explain, months later, exactly why a market resolved the way it did.
This is the design AI Market Resolver follows, and it is why we treat creation and settlement as one pipeline rather than two products.
Questions to ask before you scope
If you are at the planning stage, these are the questions we would put to a team, in roughly this order of importance.
On launch day, what happens to the user who opens your third-most-popular market?
If the answer is "there will probably be someone on the other side," that is a hope, not a plan.
How many decisions a day will this platform make without a human?
Multiply expected fixture volume by lifecycle events per market, then check whether the answer is survivable with the team you have.
Who writes market number four thousand?
And in which language, and at what hour of the night.
When a settlement is disputed six months from now, what can you show the user?
If the answer is a screenshot someone pulled at the time, that is not an audit trail.
How much capital does liquidity provision consume in the first ninety days, and under what conditions does that number rise?
Finance will ask eventually. Better to model it before signature.
What happens when you need something the platform does not do?
This is the question that separates infrastructure from a rented roadmap.
Where to go next
If you are evaluating whether to build or buy, our white label prediction market platform page covers the full module set, deployment models and what an operator actually receives.
If the operations problem is what you are sizing, start with AI Market Creator and AI Market Resolver.
If liquidity is the constraint, the AMM engine page goes into spread management, exposure control and progressive handoff.
For the commercial side, our prediction market revenue engine page covers how operators monetise an event contract vertical.
And if you would rather see a working platform than read about one, there is a live build at market.cricjam.com.
Frequently asked questions
What does it take to launch a prediction market?
At minimum: a matching and settlement engine, a market creation process, a liquidity mechanism, a resolution process with an audit trail, and compliance controls appropriate to the jurisdiction. The engine is the most discussed and least differentiating of these. Market creation at scale and liquidity at launch are where most operators underestimate the work.
Why do prediction markets fail to get traction?
Most commonly because of cold start liquidity. A user opens a market, finds an empty order book or an uneconomic spread, and leaves without explaining why. The market then never attracts the volume that would have tightened the spread. Acquisition spend accelerates this rather than fixing it.
How do prediction markets get liquidity at launch?
Through automated market makers that quote both sides of every contract from the moment of listing, with spreads that adjust against volatility and inventory, and with progressive handoff to the organic order book as real depth builds.
How many markets does a prediction market platform need?
It depends on category and audience, but the number matters less than the cycle. A platform is only as good as its next market, so what matters is whether new, timely, resolvable markets appear continuously without manual work, and whether there is liquidity in them when they do.
Can prediction markets be created automatically?
Yes, and increasingly they are. The useful version generates original markets from live signals rather than copying another platform's listings, produces questions carrying a clear deadline and authoritative source, and operates inside rules the operator defines covering market structure, outcome logic and resolution dates.
How are prediction markets resolved?
Approaches vary. Decentralised platforms typically use oracle protocols with dispute windows and token-holder voting. Licensed operators generally need something different: an internal, auditable process where evidence is collected from planned sources, outcomes are proposed against that evidence, ambiguous cases escalate to a human, and a permanent record explains every decision.
How is a prediction market different from a sportsbook?
In a sportsbook the operator sets the price and acts as counterparty, earning margin on outcomes. In a prediction market users trade against each other on an order book, the price reflects aggregate participant expectation, and the operator earns fees on transactions. The operational consequence is that a sportsbook always has a price and an exchange does not.
