What Does It Take to Create a New Prediction Market?

1. What is an event contract?

An event contract—also called an event-based derivative—is a contract whose value or payment depends on a future real-world event or measurement. A derivative is a contract whose value depends on an underlying reference. Here, the underlying is the event, measurement, or other reference being observed. A contingency is a condition that may or may not occur. Examples include an election result, a match outcome, a published economic figure, a weather observation, or a disease count.

The federal Commodity Futures Trading Commission (CFTC) Division of Market Oversight Staff Advisory No. 26-08 describes event contracts as a type of derivative contract, “often a swap with a binary payoff structure,” whose settlement— the process of determining the final result and payment—depends on an underlying occurrence or event. A payoff is the amount and conditions of the payment. A swap is a derivative in which the parties exchange payments based on an agreed reference; a futures contract is a standardized contract traded on a regulated market for a future delivery or payment. The advisory explains that, depending on the structure, an event contract may instead be a futures contract under the Commodity Exchange Act (CEA).

The advisory also says that “event contract” is not a defined term in the CEA or the Commission’s regulations. Treat the description as a functional regulatory and market description, not as one statutory definition that decides the classification of every product.

A June 12, 2026 CFTC proposal in the Federal Register uses “prediction markets” for markets on which event-contract derivatives are traded and discusses event contracts based on an occurrence, the extent of an occurrence, or a contingency. It is a proposed rule, not a final rule, and should be cited as a proposal when describing the CFTC’s policy direction.

In practical terms, an event contract converts a future uncertainty into a pre-agreed rule: identify the event, observe the specified evidence at the specified time, apply the stated condition, and determine the resulting outcome and payment.

Binary payoffs are common, but not universal

A common design is a binary contract. One position pays a fixed amount if the defined condition is satisfied; the opposing position receives no settlement payment for that contract. For example, a contract with a $1.00 settlement value may pay $1.00 per winning contract and $0.00 per losing contract, before any trading fees or other account-level effects. The contract’s price, purchase cost, fees, and net result are separate questions.

“Yes” and “No” are labels for outcomes, not substitutes for the resolution rule—the rule for deciding which outcome applies. A “No” outcome normally means that the exact Yes condition was not met under the contract’s terms; it does not necessarily mean that the opposite real-world event occurred. Multi-outcome and range-based contracts are also possible, provided the outcome set is defined precisely.

Contract terms and conditions: the written rule set

It is common to describe an event contract as its Contract Terms and Conditions. The legal nuance is that the CFTC does not define the instrument simply as a document. Instead, the CFTC advisory describes the derivative and separately explains that a product submission must include the contract’s terms and conditions together with a complete explanation and analysis of compliance.

This distinction matters for drafting. The terms and conditions are the binding rule set a participant needs in order to know what is being measured, which evidence counts, when the contract closes, how the result is calculated, and how the payment follows from the result. A public KalshiEX product filing illustrates this structure with fields such as Official Product Name, Underlying, Source Agency, Payout Criterion, Expiration Value, Expiration Date and Time, Settlement Date, Settlement Value, and Contingencies.

The field list below uses those terms in a practical drafting sense. Venue rulebooks may use different labels, combine fields, or add additional trading and governance terms. The contract should always state which document controls if a display label, rulebook, or product-specific specification differs.

2. What does an event contract contain?

A well-defined event contract gives an independent reader enough information to classify the evidence in the same way as the drafter. The following fields form the core specification.

The field terminology below follows the structure in the CFTC advisory, the Federal Register proposal, and the public Kalshi terms-and-conditions filing. Labels vary by venue. The explanations here make each field’s function explicit.

1. Contract Title / Official Product Name. A short summary title identifies the contract. It is useful for navigation and display, but the title alone is not the resolution rule. The CFTC-filed Kalshi example separates its official product name and summary from the detailed Contract Terms and Conditions.
2. Underlying (Event). The Underlying is the real-world event, occurrence, contingency, or measurable quantity to which the contract refers. Define the subject, entity, jurisdiction, unit, geography, category, and any inclusions or exclusions. Examples include a published economic statistic, an election result, a sports result, a weather observation, or a disease count. The Underlying is the fact or value being observed—not the market price of the contract itself.
3. Display Question and Parameters. This is the short, understandable question shown to a reader, for example: “Will Law X be passed by the German Bundestag by 31 December 2027?” The parameters are part of this reader-facing question: here, they include Law X, the German Bundestag, and the deadline. A measurement question could say “Will disease cases in Germany be above 100 during January 2027?”, which includes the subject, geography, operator, threshold, and measurement period. The detailed terms must still define every parameter precisely; the question is the short form, not the complete rule.
   • Subject or event: the person, team, measure, occurrence, or other underlying fact being tested.
   • Person, jurisdiction, or category: the relevant individual, team, country, authority, geographic area, industry, or event classification.
   • Operator: the logical comparison, such as above, below, at least, at most, between, or exactly. “Above” is not the same as “at least”; the boundary must be stated.
   • Value / Strike / Threshold: the specific value against which the Underlying is tested, such as a Treasury yield of 4.25%, a count of 100, or a defined cryptocurrency price. State the unit, precision, rounding, and currency where relevant.
   • Time period: the exact point or interval over which the event is measured. State whether endpoints are inclusive, which time zone controls, and whether the period is a calendar interval, a relative deadline, or a snapshot.
   These parameter slots belong with the display question, while the binding terms define what each slot means. The public Kalshi filing is a useful example of how a product can define operators, inclusive ranges, date boundaries, time periods, and geography explicitly.
4. Event Deadline / Observation End. This is the last moment by which the event must occur, or the moment at which the measurement period ends. It is often shown in the display question—for example, “by 31 December 2027”—but it is still useful to state it as a separate binding field. Give the exact date, time, time zone, and whether the boundary is inclusive. For a measurement, state the start and end of the observation window.
5. Last Trading Time / Market Close. This is when trading in the contract stops. It may be earlier than the event deadline or observation end, so that trading does not continue while the result is being determined. State the date, clock time, and time zone. Market close does not by itself decide whether the underlying event occurred.
6. Expiration Date and Expiration Time. This is when the contract expires and the final Expiration Value or Market Outcome is determined under the contract terms. It may coincide with the observation end, but it may also be later if the authoritative source publishes afterward or a defined review is required. State it separately, including the time zone. A public product filing may list Last Trading Date and Time separately from Expiration Date and Expiration Time.
7. Outcome Set / Market Outcomes. State the possible outcomes and make them mutually exclusive. A binary contract usually uses Yes and No, while a different design may use several named outcomes or value ranges. The set should be collectively exhaustive, or contain an explicit rule such as “None of the above” or an invalid/no-result outcome where that is appropriate.
8. Resolution Criteria. These are the exact event definitions: what must happen for Yes to be true, what expressly does not count, and how No or any alternative outcome is established. Define the relevant act, result, announcement, measurement, or procedural stage. The CFTC’s Federal Register proposal emphasizes that settlement criteria should be clear, objective, and publicly verifiable, and that the contract should identify both the triggering event and how its occurrence is determined.
9. Resolution Source / Source Agency hierarchy. Name the objective reference source or sources and rank them in priority. A source hierarchy is an ordered list that says which source controls first and which source is used if the first is unavailable. Identify the exact page, dataset, publication, timestamp, feed, or data field where possible. A third-party data feed, including a specified market-data or decentralized feed, should be named precisely rather than referenced as “consensus.”

   The CFTC advisory and proposed rule both focus on source reliability, objectivity, availability, accuracy, and resistance to manipulation. The public Kalshi filing gives a concrete example by listing its Source Agencies in a stated hierarchy. A source hierarchy is not a guarantee of truth; it is a pre-agreed method for identifying the evidence that controls.

10. Resolution Outcome / Expiration Value / Market Outcome. Separate the observed fact from the categorical result. The Expiration Value is the value established from the Underlying and the selected Source Agency at expiration—for example, a reported count of 145. The Market Outcome is the resulting Yes, No, named outcome, or range after the contract’s criterion has been applied. Venue-specific rules may use “resolution outcome” as an umbrella term, so the specification should define its own terminology.
11. Settlement Methodology / Resolution Methodology. This is the procedure that translates observed facts into the Expiration Value and then into the Market Outcome and payout. It may specify a single snapshot, a time-weighted or simple average, a high or low, a count, a published final result, a rounding rule, or a sequence of fallback calculations. State the calculation precisely, including data windows, units, timestamps, revisions, and missing-data treatment. The CFTC advisory specifically expects product submissions to describe the settlement methodology and identify the data sources and their reliability, objectivity, and manipulation resistance.
12. Settlement Value / Payout. Specify the amount paid for each winning position and whether the amount is fixed, scalar, or otherwise calculated. In a simple binary example, the winning side might receive $1.00 per contract and the losing side $0.00. State the contract unit, currency, and any distinction between gross settlement value and the participant’s net result after purchase price or fees. The public Kalshi filing illustrates a one-dollar Settlement Value and a payment to the side whose outcome satisfies the Payout Criterion.
13. Settlement Date. State when the final payment is credited after the Market Outcome has been determined. The Settlement Date may be later than the Expiration Date because a source may publish after the observation period or a defined review may be required. If review can delay settlement, say who conducts it, what information is considered, and when the determination becomes final.
14. Payout Criterion / Condition. The Payout Criterion is the mathematical or logical rule that maps the Expiration Value to a payout. This is closely related to the Resolution Criteria, but the distinction is useful: Resolution Criteria describe the qualifying facts, while the Payout Criterion states how the observed value produces Yes, No, a range outcome, or a payment. For example, “the average value during the final 60 seconds must be above the threshold” is different from “the value must touch the threshold at any time.” State whether equality counts, how values are rounded, and what happens when the calculation is unavailable.
15. Contingency rules and edge cases. Write the treatment for unavailable or conflicting data, obvious source errors, later corrections, postponed or cancelled events, non-starts, ties, partial completion, changed venues, renamed entities, acting or interim officeholders, and ambiguous outcomes. A robust contract also states the Market Outcome Review Process: when a review can begin, who may conduct it, which evidence is considered, how participants are notified, whether the Expiration Date or Settlement Date can move, and what makes the result final.

    Public CFTC-filed materials show why this belongs in the contract. The Kalshi filing includes contingency language for an undetermined Expiration Value and a review process, while the public Polymarket US Rulebook contains separate provisions for contract specifications, material event changes, delayed data, and a Contract Outcome Review Process. These are venue-specific examples, not a universal rulebook.

16. Additional trading and governance terms. Where applicable, the full terms and conditions may also state the contract unit or notional value (the amount used to calculate exposure), smallest price increment, trading schedule, fees, position or accountability limits, participant restrictions, amendment and notice rules, and the governing rulebook. These terms do not define the event by themselves, but they can affect how the contract is traded, administered, and reviewed.

3. A practical resolution test

When I review a specification, I ask an independent reader to resolve several plausible scenarios without oral explanation from the drafter. I include at least one ordinary result, one boundary value, one source failure, one delayed or revised publication, and one cancellation or postponement.

If two reasonable readers reach different outcomes from the same evidence, the problem is usually in the Underlying, a parameter, the source hierarchy, the Payout Criterion, or the contingency rule. If the contract can be resolved only by asking what the drafter “meant,” it is not yet sufficiently specified.

A compact event-contract outline

Official Product Name: [short title]
Underlying: [observable event or measured quantity]
Display Question: [short question containing the key parameters]
Parameters in Display Question: [subject, person/jurisdiction/category, operator, threshold]
Event Deadline / Observation End: [date, time, time zone; measurement window if relevant]
Outcome Set: [Yes / No or defined alternatives]
Last Trading / Market Close: [date, time, time zone]
Expiration Date and Time: [date, time, time zone]
Resolution Criteria: [what counts; what does not count]
Source Agency hierarchy: [primary source; fallback sources]
Expiration Value: [how the observed value is established]
Market Outcome: [how the value becomes an outcome]
Settlement Methodology: [calculation, snapshot, averaging, rounding]
Payout Criterion: [logical rule mapping value to payout]
Settlement Value / Payout: [amount and currency]
Settlement Date: [when payment is credited]
Contingencies: [data failure, corrections, postponement, cancellation, review]

This outline is a starting structure, not a universal form. The right level of detail depends on the event, the source, the number of variables, the cost of ambiguity, and the applicable legal and venue review.

Sources and citation note

The following primary materials support the definitions and distinctions used in this article. The CFTC materials explain the regulatory context; the venue filings show how product-specific terms can be documented. They are examples, not universal forms.

• CFTC Staff Advisory No. 26-08, Prediction Markets Advisory (12 March 2026): operational description of event contracts, their possible swap or futures structure, binary payoff language, terms and conditions, settlement methodology, and source-integrity considerations.
• Federal Register, “Prediction Markets; Public Interest Determinations” (12 June 2026): a proposed rule discussing event contracts, clear and publicly verifiable settlement criteria, source data, settlement integrity, and dispute-resolution processes. It is cited here as a proposal.
• KalshiEX LLC, DISEASECASECOUNT product filing (5 June 2026): a public example of an Official Product Name, Underlying, Source Agency hierarchy, comparison operators, Payout Criterion, Expiration Value, settlement fields, and contingencies. It is an example, not a universal template.
• Polymarket US Rulebook, Chapter 10 (20 March 2026): a public venue-specific example covering contract specifications, material changes, delayed data, and a Contract Outcome Review Process.

This article provides technical and conceptual guidance. It is not legal advice, a regulatory assessment, investment advice, a recommendation to trade, or a determination that a particular contract is lawful or suitable for listing. Legal and venue questions require review by the responsible organization and qualified advisers.