Evidence voting and finalization

Evidence in V3 can accumulate support or reject votes and later be finalized. Voting records participation. Finalization applies a protocol decision rule to the tally. They are separate lifecycle steps.

Tally structure

struct EvidenceTally {
    uint256 supportCount;
    uint256 rejectCount;
    uint256 participationCount;
    EvidenceStatus status;
    bool finalized;
}

The status enum is:

Value	Status
`0`	`NONE`
`1`	`OPEN`
`2`	`SUPPORTED`
`3`	`REJECTED`
`4`	`DISPUTED`
`5`	`FINALIZED`

The current finalization function sets a supported, rejected or disputed result and separately marks finalized = true. Applications should therefore trust the boolean for finalization rather than assuming enum value 5 is the only final state.

One vote per address

voteOnEvidence rejects a second vote from the same address for the same evidence item. It also rejects inactive evidence and evidence that has already been finalized.

voteOnEvidence(uint256 evidenceId, bool support)

A product should read the existing vote record before prompting the user.

const vote = await evidenceRegistry.getEvidenceVote(evidenceId, account);
if (vote.exists) {
  return showExistingVote(vote.support, vote.votedAt);
}

This avoids asking a user to sign a transaction that is guaranteed to revert.

Finalization rule

Current contract finalization is administrative and accepts minimumSupport and minimumParticipation parameters. It requires the participation threshold, then marks evidence supported when support reaches the threshold and exceeds reject count. If rejects are greater than or equal to support, it marks rejected. Otherwise it marks disputed. Because these threshold inputs are part of an admin operation, public applications should not invent a different finalization formula and call it protocol status.

Present counts, not just color

A label such as “Supported” is more informative when accompanied by its basis:

Supported
36 support · 7 reject · 43 participants
Finalized at block 12,345

This keeps the result inspectable and makes changes in participation rules easier to understand.

Voting is not a scientific truth engine

A protocol vote can establish the result of the protocol’s evidence process. It cannot make an unsupported claim true merely because more addresses clicked support. Applications should pair voting state with the artifact itself, submitter provenance and content hash verification.

Indexing votes

The contract emits EvidenceVoted and EvidenceFinalized. An indexer can maintain current tallies from events, but should periodically reconcile with getEvidenceTally if correctness matters. Store finalization transaction coordinates so an audit view can link the displayed result to the actual state transition.

Start Here

Build Your First App

Network

Identity & Roles

Capsules

Evidence

Verification

Provenance

PRESS Economy

Bounties

Data Model

API

RPC

PressKey

SDK & Integration

Operations & Security

Reference

Evidence Voting & Finalization

Evidence voting and finalization

Tally structure

One vote per address

Finalization rule

Present counts, not just color

Voting is not a scientific truth engine

Indexing votes

​Evidence voting and finalization

​Tally structure

​One vote per address

​Finalization rule

​Present counts, not just color

​Voting is not a scientific truth engine

​Indexing votes

Evidence voting and finalization

Tally structure

One vote per address

Finalization rule

Present counts, not just color

Voting is not a scientific truth engine

Indexing votes