BenchmarkersBenchmark Validation

Benchmark Validation

After the Proof of Work phase of a benchmark is complete, a Benchmarker’s direct involvement ends. The benchmark is then part of the protocol and goes through a process of verification and rewards, which we call the validation part of the benchmark.

The TIG protocol implements a lifecycle mechanism that ensures proper verification while incentivizing prompt submissions. This process is summarized in the diagram below:


Validation Lifecycle Steps


Validation Lifecycle Steps

The validation lifecycle of a benchmark consists of several key steps, each with specific conditions and transitions. Refer to the Validation Lifecycle diagram above for a visual representation of these steps:

  • Proof of Work Completion (1) - This refers to the completed Proof of Work phase of the benchmark.

  • Pending Status (2) - Once proofs are submitted, the benchmark automatically moves to pending status.

  • Transition to Verification (3) - At each block, benchmarks have a chance to move from pending to verifying. This transition occurs when their number of bundles being verified is low relative to their cutoff. This mechanism prevents benchmarkers from overwhelming the verification system with bundles that won’t qualify for rewards due to cutoff limits.

  • Verification Process (4) - Solutions undergo a comprehensive verification process lasting 1.2×delay1.2 \times \text{delay} blocks. During this phase: sampled nonces have their hashes checked, solutions are verified for correctness, methods are validated.

    For more details, check Probabilistic Verification.

  • Active Phase and Rewards (5) - After verification is complete, a benchmark becomes active. Only the bundles that passed the quality threshold during Protocol Sampling and were successfully verified enter the active phase. Each active bundle retains its “quality” (the average quality of its solutions) which determines its reward eligibility.

    Benchmarks have a total lifespan of 120 blocks from their referenced precommit block. They remain active for the remaining blocks after (1+1.2)×delay(1 + 1.2) \times \text{delay} blocks have elapsed since the initial reference. Active bundles remain active for the duration of their benchmark’s active phase.

    Once a benchmark is active, its bundles can earn rewards based on the Frontier mechanism.