Skip to main content

AI Market Resolution V2

Purpose​

V2 expands Speculite from objective crypto and stock price markets into a permissionless market platform that supports many binary outcome types while preserving a verifiable resolution process.

The core idea is:

  • users can propose arbitrary binary markets
  • an AI planner decides whether the platform can resolve the market using an allowlisted set of sources and tool adapters
  • if the market is resolvable, the system generates a formal resolution spec
  • the market is created only with that stored spec
  • at expiry, the resolver executes the stored spec against the same fixed tools and produces an auditable evidence bundle
  • the resolution is challengeable before it becomes final

This document describes the target architecture for that system.

Current MVP Baseline​

The current platform supports a narrower market model:

  • price-based crypto and stock markets
  • binary YES/NO outcome tokens
  • strike price and expiry chosen at creation time
  • resolution derived from price data, currently centered on the Pyth-based path for objective price resolution

This works because the outcome can be reduced to a direct comparison:

  • fetch price at expiry
  • compare price to strike
  • set YES or NO as winner

V2 keeps this model for objective markets, but generalizes market creation and resolution beyond price feeds.

Product Goals​

Goals​

  • support permissionless creation of many binary market types
  • reject markets that cannot be resolved from approved sources
  • replace free-form human interpretation with stored machine-readable resolution rules
  • make every resolution reproducible from fixed inputs, tools, and source material
  • allow external observers to verify the evidence used for resolution
  • provide a challenge path for ambiguous or disputed outcomes

Non-goals​

  • fully solving truth for all possible market questions
  • allowing unrestricted AI browsing of the public internet
  • eliminating disputes entirely for subjective or delayed events
  • supporting vague, opinion-based, or underspecified questions

Core Principles​

1. AI is used to formalize, not to improvise​

The AI should help transform a user question into a strict resolution procedure. It should not invent new resolution logic at the time of settlement.

2. The platform resolves only what it can define​

A market is accepted only if the platform can derive an explicit resolution spec from the user prompt and the available tool catalog.

3. Tools are fixed adapters, not open browsing​

The AI resolver does not receive unrestricted web access. It can call only an allowlisted set of source adapters controlled by the platform.

4. Evidence matters as much as the answer​

The platform must record the evidence bundle used for resolution, not only the final YES or NO verdict.

5. Finality should be challengeable​

Even with fixed tools and evidence, some markets remain ambiguous. V2 should treat AI resolution as proposable and challengeable, not as unquestionable.

High-Level Architecture​

V2 introduces two major new subsystems:

  1. Market Creation Planner This service takes a proposed market question, checks whether it can be resolved using the approved tool catalog, and either rejects it or generates a resolution spec.

  2. Resolution Engine This service executes the stored resolution spec at resolution time, gathers source evidence through fixed adapters, derives a verdict, and submits a challengeable resolution proposal.

The complete lifecycle becomes:

  1. User submits a market question.
  2. AI planner parses the question and classifies the market type.
  3. Planner checks whether the question is resolvable with the allowlisted tool set.
  4. If not resolvable, market creation is rejected.
  5. If resolvable, planner generates a canonical market definition and resolution spec.
  6. Market is created with a hash of the resolution spec stored in immutable market metadata.
  7. At expiry, the resolver executes the stored spec using only approved adapters.
  8. Resolver creates an evidence bundle and resolution proposal.
  9. Proposal enters a challenge window.
  10. If unchallenged, resolution finalizes on-chain.
  11. If challenged, dispute rules determine the final outcome.

Market Types​

V2 should not treat all markets equally. Each market should be assigned a resolution tier at creation time.

Tier 1: Fully objective markets​

Examples:

  • price above or below a strike at a specific time
  • sports result from an official league API
  • regulatory filing published by an official government registry

Characteristics:

  • direct source of truth exists
  • minimal interpretation required
  • good candidates for fully autonomous finalization

Tier 2: Structured event markets​

Examples:

  • will a candidate win an election
  • will a company launch a named product before a date
  • will a bill pass a legislative chamber by a deadline

Characteristics:

  • resolvable if the source hierarchy is explicit
  • usually needs source precedence and invalid conditions
  • should be challengeable by default

Tier 3: Weakly structured news markets​

Examples:

  • will company X announce layoffs
  • will country Y declare a state of emergency

Characteristics:

  • source language may be ambiguous
  • extraction depends on article wording or source timing
  • should be accepted only with strict rule templates and a longer challenge window

Tier 4: Non-resolvable markets​

Examples:

  • will OpenAI dominate AI
  • will crypto become mainstream
  • will a politician perform well next year

Characteristics:

  • no clear canonical source
  • subjective or undefined outcome
  • must be rejected at creation time

Source and Tool Model​

The platform should expose a fixed catalog of source adapters to the AI system.

This is the main design constraint that makes the system auditable.

What the AI should not have​

  • unrestricted browser access
  • arbitrary search engine access
  • direct freedom to visit unknown URLs
  • free-form tool use outside the allowlisted catalog

What the AI should have​

  • a closed set of platform-defined adapters
  • schemas for the inputs and outputs of each adapter
  • source metadata such as reliability tier, jurisdiction, and supported market types

Tool Adapter Design​

Tool adapters should be narrow, versioned, and evidence-producing.

Examples:

search_articles(source, query, from, to)
fetch_article(source, article_id_or_url)
fetch_feed_entry(source, identifier, as_of)
fetch_official_page(source, url)
extract_structured_fact(document_hash, schema_name)
compare_claims(claim_set, rule_id)

Each adapter call should return:

  • tool name and tool version
  • source identifier
  • requested parameters
  • canonical source URL or API endpoint
  • retrieval timestamp
  • raw response snapshot or archived pointer
  • content hash
  • parser version
  • normalized output
  • error state if retrieval or parsing failed

The result should be append-only and tamper-evident.

Source Classes​

The source catalog should be organized by trust level.

Class A: Official sources​

Examples:

  • election commissions
  • SEC or EDGAR
  • court dockets
  • exchange filings
  • league or federation APIs
  • government press registries

Preferred use:

  • primary source of truth whenever available

Class B: Structured commercial data providers​

Examples:

  • licensed market data APIs
  • sports data feeds
  • corporate action feeds

Preferred use:

  • when official sources are too slow or too difficult to query directly

Class C: Approved news outlets​

Examples:

  • Reuters
  • AP
  • New York Times
  • Financial Times
  • Bloomberg
  • Fox News

Preferred use:

  • supporting evidence
  • fallback when official sources are unavailable
  • never the only truth source for high-value markets unless the market template explicitly allows it

Resolution Spec​

The resolution spec is the central artifact of V2.

It should be generated at market creation time, stored immutably by hash, and reused exactly at resolution time.

The user-facing question is not enough. The platform needs a machine-readable contract for how truth will be derived.

Resolution Spec Responsibilities​

The spec must define:

  • what the question means in canonical form
  • which sources are allowed
  • which sources have priority
  • what exact queries or retrieval patterns are allowed
  • what counts as YES
  • what counts as NO
  • what makes the market invalid
  • what to do if sources disagree or are unavailable
  • which challenge window applies

Example Structure​

{
  "version": "1.0",
  "marketType": "election_result",
  "canonicalQuestion": "Will candidate X be declared winner of office Y in jurisdiction Z for election E?",
  "resolverMode": "challengeable-ai",
  "resolutionTimestamp": "2026-11-04T05:00:00Z",
  "sourcePolicy": {
    "primary": ["official_election_commission"],
    "fallback": ["reuters", "ap"],
    "minimumConfirmations": 1
  },
  "allowedTools": [
    "search_articles@1",
    "fetch_article@1",
    "fetch_official_page@1",
    "extract_structured_fact@2"
  ],
  "queries": [
    {
      "source": "official_election_commission",
      "template": "winner of office Y in jurisdiction Z for election E"
    },
    {
      "source": "reuters",
      "template": "candidate X election result office Y jurisdiction Z"
    }
  ],
  "decisionRules": [
    "YES if primary source declares candidate X winner",
    "NO if primary source declares another candidate winner",
    "use fallback only if primary source is unavailable"
  ],
  "invalidConditions": [
    "no valid source result by final resolution deadline",
    "conflicting official results with no platform tie-break rule"
  ],
  "challengePeriodSeconds": 86400
}

Spec Hashing​

Each market should store:

  • resolutionSpecHash
  • marketRulesHash
  • sourcePolicyHash

The full document can live off-chain in durable storage, but the contract must anchor the hash on-chain.

Market Creation Flow​

Step 1: User submits a proposed market​

Example:

Will Alice Smith be the next president of Country Z?

Step 2: Planner normalizes the question​

The AI planner should:

  • rewrite the market in canonical form
  • identify the market type
  • extract entities, dates, offices, jurisdictions, and deadlines
  • identify whether the question is underspecified

Step 3: Planner checks resolvability​

The planner compares the normalized question against:

  • the available source catalog
  • the available tool adapters
  • the supported templates for that market type

If the platform cannot define a safe resolution path, it rejects the market.

Step 4: Planner generates a resolution spec​

If resolvable, the planner produces:

  • canonical question
  • outcome rules
  • invalid conditions
  • source hierarchy
  • allowed tools
  • query templates
  • challenge period
  • confidence or risk classification

Step 5: Policy gate​

Before a market is created, the system should run policy checks such as:

  • prohibited content
  • impossible or self-referential markets
  • lack of sufficient specificity
  • unsupported jurisdiction
  • unsupported source availability
  • unacceptable ambiguity score

Step 6: Market creation​

Only after the spec passes validation should the market be deployed and indexed.

Resolution Flow​

At expiry, the resolver does not reinterpret the question. It executes the stored spec.

Step 1: Load immutable market metadata​

The resolver loads:

  • market id
  • canonical question
  • expiry
  • resolutionSpecHash
  • allowed source policy

Step 2: Execute approved tool calls​

The resolver may call only tools listed in the spec.

No new sources, URLs, or workflows should be introduced at this stage unless the market is explicitly shifted into a dispute mode.

Step 3: Build evidence bundle​

For each tool call, the resolver archives:

  • exact request parameters
  • exact response snapshot
  • content hash
  • parser output
  • extractor output
  • timestamps

Step 4: Apply decision rules​

The resolver should derive a structured decision trace such as:

  • source available: yes
  • source says candidate X winner: yes
  • fallback used: no
  • invalid condition triggered: no
  • final verdict: YES

Step 5: Submit challengeable resolution proposal​

The resolver submits:

  • verdict
  • evidence bundle hash
  • decision trace hash
  • attestation or proof bundle

Step 6: Finalization or dispute​

If no challenge is raised before the challenge period ends, the resolution finalizes.

If challenged, the market moves to a dispute process.

Evidence Bundle​

The evidence bundle should be first-class protocol data.

It should be stored off-chain in durable object storage or content-addressed storage, with hashes anchored on-chain.

Evidence Bundle Contents​

{
  "marketId": "123",
  "resolutionSpecHash": "0x...",
  "resolverVersion": "resolver-engine@1.2.0",
  "toolCalls": [
    {
      "tool": "fetch_official_page@1",
      "source": "official_election_commission",
      "request": {
        "url": "https://..."
      },
      "retrievedAt": "2026-11-04T05:01:10Z",
      "contentHash": "0x...",
      "parserVersion": "official-page-parser@1.0.3",
      "normalizedOutputHash": "0x..."
    }
  ],
  "decisionTrace": {
    "primarySourceAvailable": true,
    "winnerDeclared": "Alice Smith",
    "verdict": "YES"
  },
  "verdict": "YES"
}

Verification Goals​

External observers should be able to verify:

  • the resolver used the stored spec
  • the resolver used only approved tools
  • the fetched content matches the archived hashes
  • the parsing and extraction steps were run with declared versions
  • the verdict matches the evidence and rule trace

Verification and Attestation​

V2 needs stronger guarantees than standard backend logs.

There are several levels of verifiability:

Level 1: Hash-anchored auditability​

The minimum viable model:

  • hash every evidence artifact
  • store hashes on-chain
  • archive raw inputs and normalized outputs
  • allow anyone to recompute the verdict from the evidence

This is the fastest path to production and likely the right first version.

Level 2: Attested execution​

A stronger model:

  • run the resolver inside an attested execution environment
  • sign the execution result with a hardware-backed attestation
  • anchor the attestation and evidence hashes on-chain

This improves tamper resistance but still depends on trust in the attestation system.

Level 3: Cryptographic compute verification​

The strongest model:

  • use zero-knowledge or equivalent proof systems for parts of the execution
  • prove that the declared program was run against the declared inputs

This is expensive and difficult for general web content flows, especially when parsing news pages and using large language models.

For V2, the recommended model is:

  • hash-anchored evidence by default
  • attested execution for the resolver if operationally feasible
  • challenge window for markets above a configurable risk threshold

An external attested compute network such as Ritual Infernet or an equivalent coprocessor design may be a good fit for the execution layer, but the protocol should remain vendor-neutral at the architecture level.

Why Free-Form News Reading Is Not Enough​

The platform can allow approved news sources, but only as constrained adapters.

This matters because:

  • article wording can be ambiguous
  • multiple outlets can disagree temporarily
  • articles can be updated after publication
  • raw HTML is brittle
  • AI extraction can differ across model versions

Therefore approved news sources must be paired with:

  • explicit extraction schemas
  • source precedence
  • fallback rules
  • invalid conditions
  • durable snapshots
  • parser and model version pinning

Dispute and Challenge Model​

A permissionless market system should expect edge cases.

Challenge triggers​

A challenge may be raised when:

  • evidence does not match anchored hashes
  • resolver used a tool not present in the spec
  • parser or extractor produced an inconsistent result
  • a higher-priority source was ignored
  • source conflict rules were applied incorrectly
  • an invalid condition should have been triggered

Challenge outcomes​

The dispute process can:

  • uphold the proposed resolution
  • overturn the resolution
  • mark the market invalid
  • escalate the market to a manual review or governance path
  • short challenge period for Tier 1 markets
  • longer challenge period for Tier 2 and Tier 3 markets
  • economic bond for proposers and challengers
  • slashing or fee penalties for clearly bad proposals

On-Chain Design Changes​

The current on-chain model is optimized for objective price markets. V2 requires more generic resolution metadata and proposal state.

New market metadata​

Each market should add fields such as:

  • marketType
  • resolverMode
  • resolutionSpecHash
  • marketRulesHash
  • challengePeriodSeconds
  • resolutionDeadline
  • status

Resolution states​

A more complete state machine should include:

  • Open
  • Expired
  • ResolutionProposed
  • Challenged
  • Resolved
  • Invalid

New contract functions​

Examples:

function proposeResolution(
    uint256 marketId,
    uint8 verdict,
    bytes32 resolutionSpecHash,
    bytes32 evidenceBundleHash,
    bytes32 decisionTraceHash,
    bytes calldata attestation
) external;

function challengeResolution(
    uint256 marketId,
    bytes32 challengeEvidenceHash
) external payable;

function finalizeResolution(uint256 marketId) external;

function resolveInvalid(uint256 marketId) external;

Event model​

The protocol should emit events for:

  • market created with resolutionSpecHash
  • resolution proposed
  • resolution challenged
  • resolution finalized
  • market invalidated

Off-Chain Services​

V2 requires new backend services beyond the current market data and settlement stack.

1. Tool Registry Service​

Responsibilities:

  • store the catalog of approved adapters
  • version tool schemas
  • define source metadata and precedence

2. Market Creation Planner​

Responsibilities:

  • parse proposed market questions
  • classify market type
  • generate resolution spec
  • reject unsupported or ambiguous markets

3. Resolution Executor​

Responsibilities:

  • load stored specs
  • execute approved tool flows
  • build evidence bundles
  • derive verdicts and decision traces

4. Evidence Archive​

Responsibilities:

  • store raw source snapshots
  • store normalized outputs
  • expose public verification endpoints

5. Watcher and Challenger​

Responsibilities:

  • independently recompute resolutions
  • identify mismatches
  • submit challenges

Acceptance Policy for User-Generated Markets​

The planner should reject a market if any of the following is true:

  • the question is subjective
  • the time condition is ambiguous
  • the entities are unclear or missing
  • no supported source hierarchy exists
  • the outcome cannot be encoded in a deterministic decision rule
  • the market would require unrestricted browsing
  • the source language would require open-ended interpretation with no tie-break rule

The product should bias toward rejection rather than pretending everything is resolvable.

Example: Presidency Market​

User input:

Will Alice Smith be the next president of Country Z?

Planner output:

  • market type: election_result
  • canonical question: Will Alice Smith be declared winner of the 2028 presidential election in Country Z?
  • primary source: official election commission
  • fallback sources: Reuters, AP
  • YES rule: official result names Alice Smith winner
  • NO rule: official result names another candidate winner
  • invalid rule: no certified result by final deadline

Resolution execution:

  1. Check official election commission source.
  2. If available and parseable, use it.
  3. If unavailable, use fallback rules exactly as encoded.
  4. Produce evidence bundle.
  5. Propose resolution with challenge period.

This is a valid V2 market.

Example: Unsupported Market​

User input:

Will OpenAI dominate AI by 2030?

Planner output:

  • reject market

Reason:

  • no objective source of truth
  • no deterministic YES or NO rule
  • no safe resolution spec can be generated from the current tool catalog

Rollout Plan​

Phase 1: Structured templates only​

Support only a few templates:

  • price markets
  • election results
  • sports results
  • company announcement markets tied to official filings or press releases

Characteristics:

  • strict source hierarchies
  • short adapter catalog
  • strong rejection rules

Phase 2: Challengeable AI resolution​

Add:

  • evidence archive
  • public verification endpoints
  • proposer and challenger roles
  • challenge periods and bonds

Phase 3: Attested execution​

Add:

  • attested runtime for resolver execution
  • signed execution receipts
  • public proof verification tooling

Phase 4: Broader market surface​

Add more templates only after:

  • tool adapters are stable
  • dispute rates are acceptable
  • invalid market handling is proven in production

The first V2 release should not target "all markets" in practice. It should target:

  • all supported market templates that can be reduced to a clear source hierarchy and deterministic rule set

This keeps the product honest while still allowing permissionless creation inside a bounded resolution framework.

Summary​

V2 should be built around one rule:

a market can exist only if the platform can write down, store, and later execute an auditable resolution spec using an allowlisted set of source adapters

That gives the platform a path from the current objective price-market MVP to a broader AI-assisted prediction market system without relying on unrestricted browsing or opaque human intervention.