You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
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.assert_outcometime.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.