Skip to content

[Feature] V2: design canonical market/question identifier and evidence convention #76

Description

@collinsezedike

Summary

V1 stores only a boolean per assertion and leaves it entirely to the integrator to map their own market to an assertion id off-chain. That works when only the asserter and disputer ever look at a dispute, but v2 opens voting to an unbounded set of third parties who need to know what they're actually voting on. This issue designs (not yet implements) an unambiguous, on-chain-anchored reference for what a v2 assertion actually claims.

Scope

  • Decide whether v2 commits an on-chain identifier or content hash for the claim/question directly in AssertionV2 (see [Feature] V2: implement PolicySnapshot and versioned assertion state #64), or instead relies on a versioned off-chain integrator registry that maps assertion ids to claims, with only a reference/hash on-chain.
  • If an on-chain identifier: define its format (a URI, a content hash of an off-chain document, a structured claim schema) and how it's validated or left unvalidated at assert_outcome time.
  • Cover evidence: does v2 need any on-chain convention for where supporting evidence lives (a URI field, an event, nothing), or is evidence entirely an off-chain concern between the integrator and voters, as v1 already treats it?
  • This is explicitly flagged in docs/src/V2_RESOLUTION.md's threat table as "an adjacent design dependency, not a decision approved by this issue" (referring to the original design issue [Feature] Design stake-weighted resolver voting (v2 resolution mechanism) #19), meaning it was deliberately deferred rather than decided. This issue is where it actually gets decided.
  • Output: a short design doc (docs/src/V2_CLAIM_IDENTIFIER.md or similar) with the recommendation, reviewed the same way V2_RESOLUTION.md itself was, before any implementation issue is opened against it.

Depends on

None directly, but should land before or alongside #65 (bonded assertion posting), since the assertion's shape may need to include whatever this issue decides.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestspikeResearch or design-only, no implementation

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions