Validator Spec

Validator Responsibilities#

Responsibility

Mechanism

Receipt verification

Verify operator-submitted service receipts against cryptographic proofs

Challenge-response

Issue random spot challenges to nodes; verify responses

Availability proof auditing

Verify storage nodes are actually holding claimed data

Fraud detection

Identify patterns inconsistent with genuine service delivery

Dispute resolution

Adjudicate disputes between operators and consumers

Penalty enforcement

Apply reputation penalties for verified fraud or SLA failure

Registration#

# 1. Install validator software
npm install -g @gao/validator-cli

# 2. Post collateral
gao-validator collateral --amount 1000 --token USDC
# → Locked in escrow for duration of validator participation

# 3. Register on-chain
gao-validator register --domain validator.gao

# 4. Begin verification duties
gao-validator start
# → Assigned to verification pool
# → Begins receiving receipts to verify

Collateral is locked in escrow for the duration of validator participation. Collateral requirements scale with verification volume — higher-volume validators post more collateral. Proportional accountability.

Receipt Verification Flow#

Node completes service (compute / storage / bandwidth)
  ↓
Node generates service receipt:
  {
    receipt_id:   "dp_rcpt_abc123",
    node_id:      "node.operator.gao",
    service_type: "compute",
    units:        150,           // CPU-seconds
    consumer:     "agent.merchant.gao",
    timestamp:    1710001234,
    proof:        "0x...",       // cryptographic proof of work
    node_sig:     "0x..."        // node key signature
  }
  ↓
Receipt submitted to Validator Pool
  ↓
Validator verifies:
  1. Receipt format valid
  2. Node signature valid
  3. Cryptographic proof valid (workload-specific)
  4. Node is registered and in good standing
  5. Receipt is not a replay (receipt_id unique)
  6. Timestamp within acceptance window
  ↓
Validator signs verified receipt
  ↓
Quorum reached
  (minimum 2-of-3 — MVP default, subject to governance; scales with network growth)
  ↓
Verified receipt submitted to Layer 4 (Gao Payment)
  ↓
Layer 4 releases compensation to node

No single validator can unilaterally approve or block compensation. Quorum is required.

Challenge-Response Verification#

Validators issue random spot challenges to verify ongoing service capability — not just claimed delivery. Challenge timing is randomized and on-chain verifiable. Nodes cannot predict when they will be challenged.

Compute Challenge#

Validator sends:  challenge_payload (encrypted computation task)
Node responds:    result + execution_proof
                  within 30s  ← MVP default — subject to governance

Verification:
  result == expected_result  → PASS
  result incorrect           → FAIL (reputation penalty)
  timeout                    → FAIL (SLA violation)

Storage Challenge (Proof of Retrievability)#

Validator selects: random data segment from node's declared holdings
Validator sends:   challenge (segment index + expected hash)
Node responds:     segment data + Merkle proof
                   within 10s  ← MVP default — subject to governance

Verification:
  hash(segment_data) == expected_hash  → PASS
  hash mismatch                        → FAIL (fraud alert)
  timeout                              → FAIL (availability violation)

Bandwidth Challenge#

Validator initiates: test data transfer through relay node
Validator measures:  actual throughput vs. declared capacity

Verification:
  throughput ≥ 80% declared  → PASS
  throughput < 80% declared  → SLA warning
  throughput < 50% declared  → FAIL (reputation penalty)

Fraud Detection#

The validator network runs continuous pattern analysis for fraud signals:

Pattern

Interpretation

Response

Receipt submitted without corresponding network traffic

Fake delivery

Immediate receipt rejection + fraud alert

Storage proof response without data retrieval I/O

Fake storage

Receipt rejection + challenge escalation

Compute receipt with impossible execution time

Timing fraud

Receipt rejection + investigation

Cluster of receipts from same IP/subnet

Sybil pattern

Investigation + collateral at risk

Receipt hash collision

Replay attack

Automatic rejection + penalty

Fraud requires real resource expenditure to defeat detection — the economic cost of genuine fraud resistance is built into the verification design.

Slashing Conditions#

Condition

Penalty

Signing a provably fraudulent receipt

50% collateral slash

Colluding with a node on fake receipts

100% collateral slash + permanent ban

Extended verification unavailability

Progressive penalty — 0.1% per day (MVP default — subject to governance)

Malicious dispute resolution

25% collateral slash

Slashing requires on-chain evidence and multi-validator consensus. Disputed slashing can be appealed through the governance dispute process.

Validator Compensation#

Validators are compensated from a protocol fee applied to verified receipts. The fee rate is governance-adjustable within defined bounds (subject to governance). Compensation is per verified receipt — validators earn by doing work, not by passive participation. Validators who issue challenges earn additional compensation for successful challenge completion.

Validator Invariants (Protocol invariants — not subject to governance change)#

ID

Invariant

VAL-INV01

No single validator can approve or block compensation unilaterally — quorum required

VAL-INV02

Collateral is locked for the duration of active participation; cannot be withdrawn during disputes

VAL-INV03

Challenge randomness is on-chain verifiable; no validator can predict challenge timing

VAL-INV04

Verified receipts are immutable; no validator can modify a receipt after signing

VAL-INV05

Validator slashing requires on-chain evidence; cannot be triggered by a single party

VAL-INV06

Validator governance weight decays; long-inactive validators lose influence

See proof-of-contribution.md for how verified receipts feed into the Rail A scoring model. See security-model.md for the full threat model and fraud economics.