7. Attestation and Validator Protocol

7.1 Validator Role

Validators are independent actors that attest to the correctness of verification execution. They assert that the system was run correctly, NOT that a claim is true.

7.2 Seven-Step Replay Protocol

Step 1: RECEIVE

• Validator receives a verification request containing: claimId, voId, engineVersion
• Validator confirms it supports the specified engine version

Step 2: RETRIEVE

Validators MUST retrieve the original claim definition and all referenced evidence units. Evidence retrieval follows a tiered protocol that balances trust minimization against availability.

Evidence Verifiability Classification:

Retrieval Hierarchy (in priority order):

For each evidence unit referenced by evidenceId:

1. Independent re-fetch (ONCHAIN evidence only, highest trust):

   • Using the evidence unit's retrievalMethod and anchor fields (Section 3.1), the validator re-executes the same RPC call against its own archive RPC node at the specified block/slot
   • Apply BCE canonicalization (Section 3.4) to the RPC response
   • Compute candidateId = Keccak-256(canonicalForm)
   • If candidateId == evidenceId: evidence is independently verified
   • If candidateId != evidenceId: flag as EVIDENCE_DIVERGENCE (see Step 2 failure modes below)
   • This is the gold standard — the validator trusts no one but the chain itself

2. Operator data layer (all evidence types, medium trust):

   • Validator requests evidence from the operator's Evidence Serving API (Section 8.5) by evidenceId
   • The API returns the canonicalForm bytes
   • Validator computes Keccak-256(canonicalForm) and verifies it matches evidenceId
   • Trust model: The integrity hash guarantees the content hasn't been tampered with, but does NOT guarantee the evidence was correctly derived from chain state. A malicious operator could fabricate a canonicalForm that hashes to a chosen evidenceId only if they can break Keccak-256 preimage resistance (computationally infeasible)
   • However: the operator chose which evidence to collect and how to canonicalize it. The integrity hash only proves consistency, not correctness of the original observation

3. Decentralized storage (all evidence types, medium trust):

   • Fetch from IPFS/Filecoin by CID (derived from BCE-encoded payload) or Arweave by transaction ID
   • Same integrity verification as (2): compute hash, verify against evidenceId
   • Available for evidence units that have been promoted to cold storage (Section 8.5)

4. Cross-validator sharing (all evidence types, medium trust):

   • Request evidence from other validators who have previously replayed this VO
   • Same integrity verification: compute hash, verify against evidenceId
   • Useful when the operator's data layer is unavailable

Step 2 Failure Modes:

Required Verification per Retrieval Source:

Minimum Verification Threshold:

Validators MUST, at minimum:

• Verify the integrity hash of every evidence unit regardless of retrieval source
• Independently re-fetch at least 20% of ONCHAIN evidence units (selected deterministically: evidence units whose evidenceId has first byte < 0x33) from their own archive RPC
• If any independently re-fetched evidence unit has a hash mismatch, escalate ALL evidence units to independent re-fetch before deciding match/mismatch

This probabilistic verification creates a credible deterrent against evidence fabrication without requiring every validator to re-fetch every evidence unit (which would be prohibitively slow for large evidence graphs).

Step 3: RECONSTRUCT

• Reconstruct the Evidence Graph from retrieved evidence
• Apply the same scope constraints as the original evaluation

Step 4: REPLAY

• Execute the evaluation using the specified engine version
• Apply the same methods at the same versions

Step 5: COMPARE

• Compare the replayed Verification Object with the original
• Comparison is on the content-addressed voId:
  • If replay_voId == original_voId: MATCH
  • Else: MISMATCH

Step 6: ATTEST (if MATCH)

• Create attestation record:

{
  "voId":           "string",
  "validatorId":    "string",
  "engineVersion":  "string",
  "replayedAt":     "string       // ISO 8601",
  "sig":            "string       // Ed25519 signature over (voId + validatorId + replayedAt)"
}

Step 7: REPORT (if MISMATCH)

• Record the mismatch details
• Submit divergence report to the protocol
• If the original VO has accumulated attestations, this triggers a dispute

7.3 Attestation Schema

{
  "attestationId":    "string         // Unique identifier",
  "voId":             "string         // Verification Object being attested",
  "validatorId":      "string         // Validator public key / identity",
  "engineVersion":    "string         // Engine version used for replay",
  "methodVersions":   "Record<string, string>  // Method versions used",
  "replayedAt":       "string         // ISO 8601",
  "replayDuration":   "number         // Milliseconds taken for replay",
  "sig":              "string         // Cryptographic signature"
}

Signature Scheme:

• Default: Ed25519 (inherited from FirmaChain / Cosmos SDK)
• Message: Keccak-256(voId || validatorId || engineVersion || replayedAt)
• Validators MUST register their public keys on-chain before attesting

7.4 Validator Requirements

Hardware:

Software:

• Specific engine version binaries (distributed via protocol updates)
• Chain-specific RPC client libraries
• FirmaChain node client (for attestation submission)
• IPFS client (for decentralized evidence retrieval)

Evidence Retrieval Infrastructure:

Validators without archive RPC access MAY still operate but are limited to operator-served evidence retrieval (trust level: medium). Such validators MUST declare archiveAccess: false in their on-chain registration, and their attestations carry reduced weight in dispute resolution.

Operational:

• Maximum replay latency: 60 seconds per verification (excluding evidence retrieval; retrieval budget is separate, see below)
• Maximum evidence retrieval time: 120 seconds total per VO (across all evidence units)
• If retrieval exceeds this budget, validator reports EVIDENCE_RETRIEVAL_TIMEOUT (not a replay failure — no attestation or dispute is produced)
• Minimum uptime: 95% over rolling 30-day window
• Validators MUST support all CURRENT and SUPPORTED engine versions

7.5 Incentive Design

Fee Distribution:

When a verification fee (denominated in LINE) is collected:

7.5.1 Staking Requirements

Dynamic Minimum Stake:

The minimum stake is defined relative to the protocol's economic activity, not as a fixed token amount. This ensures the stake remains meaningful as token price fluctuates.

minimumStake = max(FLOOR_STAKE, MEDIAN_FEE_30D * STAKE_MULTIPLIER)

At current economics (estimated 0.1 LINE per VO fee, LINE ~$0.03): minimumStake = max(50,000, 0.1 * 1,000) = 50,000 LINE = ~$1,500. This makes Sybil attacks economically meaningful — spinning up 10 validators requires $15,000 at stake.

Staking mechanics:

• Staking locks for the duration of active validator status
• Unstaking cooldown: 21 days (aligned with FirmaChain unbonding)
• Validators MAY stake more than the minimum to increase their validatorWeight (see Section 7.5.3)
• Stake is denominated in LINE and subject to on-chain governance for parameter updates to FLOOR_STAKE and STAKE_MULTIPLIER

7.5.2 Slashing Conditions

Dispute Escrow:

Filing a MsgDisputeVO (Section 8.4) requires a stake escrow of 0.1 * minimumStake. If the dispute is upheld (the original attestation is proven false), the escrow is returned plus the 50% bounty from the slash. If the dispute is rejected, the escrow is burned. This prevents frivolous disputes while maintaining a credible challenge mechanism.

Progressive slashing rationale: A single honest mistake (e.g., due to a transient RPC inconsistency that wasn't caught by the 20% re-fetch threshold in Section 7.2 Step 2) costs 10% of stake — painful but recoverable. Repeated false attestations escalate rapidly to ejection, making sustained fraudulent attestation economically irrational.

7.5.3 Validator Weight and Sybil Resistance

Raw attestation count is a weak signal — an attacker with N cheap validators can generate N attestations. To resist Sybil attacks, the protocol weights attestations by validator economic commitment and track record.

Validator Weight Formula:

validatorWeight = stakeWeight * reputationMultiplier * archiveMultiplier

Sybil resistance properties:

• New validator penalty: A freshly registered validator has reputationMultiplier = 0.5, meaning its attestations carry half the weight of a mature validator. An attacker spinning up 10 new validators gets 10 * 0.5 = 5.0 effective weight, equivalent to 2.5 established validators.
• Capital inefficiency of splitting: Due to sqrt(stake) weighting, splitting 100,000 LINE across 2 validators (each 50,000 LINE) yields 2 * sqrt(1) = 2.0 total weight, while staking 100,000 LINE on one validator yields sqrt(2) = 1.41. Splitting is better for raw count but worse for weighted influence per LINE staked — the diminishing returns are intentional to balance decentralization against Sybil resistance.
• Reputation is non-transferable: reputationMultiplier is tied to the validatorId and cannot be sold, delegated, or transferred. Ejected validators (3+ offenses) lose all accumulated reputation.

Weighted attestation threshold:

A VO is considered "well-attested" when its weighted attestation score exceeds a threshold:

attestationScore = sum(validatorWeight_i) for all attestors i
wellAttested = attestationScore >= ATTESTATION_THRESHOLD

This replaces the simple "3+ attestations" rule used elsewhere in the spec (e.g., Section 8.5 Arweave promotion). All references to attestation count thresholds SHOULD be interpreted as weighted attestation score thresholds.