> ## Documentation Index
> Fetch the complete documentation index at: https://docs.presschain.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Evidence Voting & Finalization

> Read evidence tallies, submit one vote per address and understand administrative finalization.

# 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

```solidity theme={null}
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.

```solidity theme={null}
voteOnEvidence(uint256 evidenceId, bool support)
```

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

```ts theme={null}
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:

```text theme={null}
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.