How to write a market that can actually be resolved

Start with an event people can disagree about

“Is this game going to go crazy?” has energy, but it has no agreed finish line. A usable market keeps the interesting event and removes the ambiguity. Name the game, studio, operator or person; choose one observable outcome; then specify when and where it will be measured.

The title should be short enough to scan. The conditions underneath carry the precise definition. That does not mean hiding an exception that reverses the apparent question: the title and the rules must describe the same bet.

Choose the proof before the threshold

Suppose you want a market about a game becoming popular. An official table of bet counts may support a question about its reported rank. It cannot automatically answer how many viewers watched a streamer play it, whether all its players made money, or how many bets came specifically from one casino.

Inspect the actual data before writing the claim. Identify its units, coverage, update schedule and time range. Stake Engine data, for example, must be read according to the period and metric the chosen endpoint documents. A response collected today is not necessarily a record of activity that occurred today.

This is also a product choice. A source may make hundreds of questions technically possible while only a few are recognisable or timely enough for people to care about. Ask why somebody following that game or creator would have a view on this particular event.

• What Stake Engine rankings can actually prove →

Write the question and its finish line together

Here is an illustrative template, not an offered market: “Will Game A finish ahead of Game B in the provider’s seven-day bets ranking at the agreed observation?” The conditions identify both games by stable identifiers, name the exact ranking and specify the source’s seven-day period. “Popular” becomes a particular measurement.

Next, define the times separately: betting ends before the observation; the observation has an exact UTC window; and there is a deadline for collecting a valid response. A locally displayed date can be convenient, but every participant must be able to determine the same cutoff.

Finally, map evidence to outcomes. YES might require A’s reported count to exceed B’s. NO might require B’s to exceed A’s. The example still needs explicit rules for a tie, a missing game, an invalid response and a source outage. Do not silently turn any of those into a loss for one side.

Make sure NO is observable too

For “will any bet exceed this payout?”, one qualifying, authenticated and correctly timestamped bet can prove that the event occurred. A feed containing no such example proves NO only if it covers the relevant universe and period well enough to support that conclusion. A sample of public bets or selected wins does not automatically do that.

For a named streamer announcement, decide which official channel counts, what constitutes an announcement and how the full relevant period will be checked. A deleted post, an inaccessible stream or a rumour repeated by another account needs a rule before anyone enters.

Provably fair verification answers another question: whether a supplied result follows a committed calculation. It does not, by itself, provide a complete history of every bet made on a platform.

• Fairness verification versus complete market evidence →

Save what the source actually said

A result should preserve the evidence needed to repeat the decision: source address, collection time, relevant identifiers, raw response where appropriate and the outcome calculation. A hash can help show that a saved response was not subsequently changed. It cannot establish that the provider’s original report was truthful or complete.

Record the source’s observation time separately from the time your system downloaded it, when both are available. Otherwise a stale cached response can look like a fresh measurement. If the source changes its format or meaning, pause unsupported new questions rather than quietly rewriting existing commitments.

Try to resolve it before you publish it

Walk through a YES example, a NO example and a source-failure example using the written rules. If two reasonable readers can reach different answers from the same evidence, tighten the question. If the source cannot support one outcome, choose a narrower event or a different source.

Then review the actual player experience: one clear question, a deadline people can understand, and decision conditions that can be opened without covering the bet. Automation is useful when it consistently applies those commitments. It is not a reason to publish an uninteresting or unprovable question.

• Create a market on Inari →
• Understand the result review and settlement process →