Dota 2 prediction markets: draft, patch and roster uncertainty

What actually decides a Dota 2 market

You can record a pre-match Dota 2 forecast before either team has drafted. Track the event, announced roster and tournament patch. Once the draft is shown, record picks and any stand-in updates with a timestamp before revising your forecast. Those observations document the information behind your estimate; a change in your estimate can occur without a change in the market price.

Before you form any view, read the market rules for the exact market you are considering. A binary market pays 1 to the winning share and 0 to the losing share, and only in a rare unknown case does it settle at .50 each, which is a partial payout, not a refund. The rules also fix the resolution source, the deadline and the edge cases, so the title alone never tells you what you are trading.

A key mismatch is scope. One market may resolve on the series result while your evidence comes from a single game, and another may resolve on an individual game while your evidence is a series-level roster report. Keeping those scopes straight is more valuable than any single probability you write down.

Patch notes tell you the version, not who wins

Valve publishes Dota 2 changes through its official patch notes feed, version by version. The captured data here is patch 7.40, checked on 2026-10-10, and it is one version rather than proof of which patch a later tournament uses. A hero or item change you read in that list is a version-specific adjustment, not a win rate and not a team statistic, and nothing in the feed predicts draft outcomes.

So whenever you price a match, be able to name the version you assumed and the date you assumed it. If the event later confirms a different patch, your earlier reasoning was built on the wrong input, and you want to notice that rather than quietly adjust the story. Nothing in this material claims a measured effect of any patch on results.

An illustrative checklist with 2 timestamps

The checklist below is author-designed and illustrative, not an empirical study, and the numbers in it are hypothetical judgment rather than a measured improvement. Write down 2 separate versions of your view. The pre-draft version records what you knew before heroes were shown: event, patch version, announced roster, stand-in expectation. The post-draft version records what changed once the draft and the confirmed participants were visible. Never overwrite the first with the second.

4 questions drive the separation. Record the patch confirmed for the event, the 5 players who actually play, whether resolution covers a series or a single game, and whether a stand-in changes the role assignments. Each answer either narrows or widens your uncertainty, and each belongs to a specific timestamp rather than to a general feeling about the team.

Keeping both versions costs almost nothing and pays off later, when you review how your process behaved across many matches. If you want a structured way to compare recorded forecasts against results, the backtest material gives you a framework for that instead of trusting your memory of one tournament.

A worked example of a revision, including the losing case

Illustrative inputs only. At 09:00, before the draft, you judge team A at p=.55 to win the series and the market also trades at .55, so your edge is zero under your own judgment. You save that timestamped view. At 09:25 the draft is shown, the event patch matches the version you recorded, and the opponent's stand-in is confirmed. You revise to p=.65. That revision is your judgment, not a measured improvement, and the correct comparison is against the price that exists after the draft, not against your own earlier number.

If the price is still .55 after your revision, your hypothetical edge is .65 minus .55, or 10 percentage points in your own judgment. If the price is already .70, your revised view sits below the market, and the conditional choices are to pass or to ask which new information the market has priced in that you have not. The losing case is concrete: revise to .65, buy at .55, the team loses the series, and each share settles at 0. Nothing here justifies a trade on the strength of a positive expected value alone, and the example names no real team, event or patch.

Illustrative decision states by market scope

The table is an illustrative decision map, not a ranking and not a fee schedule. All probabilities in this case are hypothetical judgments. The applicable venue’s current fees and available liquidity must be checked separately.

Roster, stand-in and the series versus game trap

Roster uncertainty has 2 layers: the announced roster and the players who actually sit down. A stand-in can shift roles and narrow a hero pool without appearing in pre-event material. Because the checklist keeps the 2 timestamps separate, the stand-in belongs in the post-draft version, at the moment it is confirmed, while the pre-draft entry stays as it was.

The series versus individual game distinction is a resolution question first. Ordinary binary markets settle at 1 or 0, and a rare unknown outcome can settle at .50 each rather than cancelling. That is why you check what the specific market says about source and deadline. If the rules name the series, one game's draft is partial information. If the rules name a single game, a series-level roster report is partial information instead. Align the scope of your evidence with the scope of the question before you do any further work.

Limits, then pick your next step

The checklist is author-designed, the .55 and .65 values are hypothetical, and no accuracy claim is made for any model. No current hero win rate, tournament fact or roster fact is asserted anywhere here, and patch notes captured at one version may not describe the patch used at a later event. Rules differ market by market and have to be read individually each time.

Your next step should follow your actual question. For the wider picture of how these markets are structured, start with esports markets. To test whether your process beats a simple baseline, go to backtest. To store timestamped forecasts you can review later, use journal. If what you really need is to know how an outcome gets decided, read resolution before doing any further analysis, because it changes which evidence you should collect first.