Enhanced Block Reward Function

We are excited to announce a proposal to revise the block reward function. We encourage discussion of this new design.

\textbf{Motivation}

Currently, TIG’s OPoW mechanism determines the block reward for a benchmarker i with a novel \href{https://docs.tig.foundation/opow#benchmarker-influence}{influence} function that monotonically increases with the benchmarker’s factors:
\begin{equation} reward_i \propto \mathrm{influence}(f1_i, f2_i,.., fn_i). \end{equation}

In particular, for factors based on challenges, the factor is calculated using the number of qualifying solutions found by benchmarker i out of all benchmarkers B over the recent 120 blocks:
\begin{equation} f_i = \frac{\mathrm{num\_qualifiers}_i}{\sum_{b \in B} \mathrm{num\_qualifiers}_b}. \end{equation}

Thus, in order to increase their rewards, benchmarkers are incentivised to maximise their solution rate. However, this introduces an inherent bias in algorithm adoption by benchmarkers. The current structure favors exploitative algorithms over those that balance exploration and exploitation.

Specifically, algorithms that prioritize exploitation (e.g. greedy algorithms) tend to have have lower startup and execution costs, allowing for higher parallelisation, resulting in a more stable and likely higher solution rate. Current low fuel limits and execution overhead from WASM virtual machine exacerbates the exploitation advantage, although these issues will be addressed with future updates to increase fuel limits and to execute algorithms on native hardware.

This bias misaligns innovation in TIG with what the real-world adopts: valuable algorithms are ones that effectively balance the exploration-exploitation trade-off for discovering high-quality solutions within limited computational budgets, as pure exploitation often leads to sub-optimal quality solutions.

In the next section, we outline our proposed changes to address this bias.

\textbf{Reward function design}

To address the exploitation bias, we propose an enhanced factor calculation that incorporates a benchmarker reliability score \mathcal{R}:

\begin{equation} f_i = \frac{\mathcal{R}_i \times \mathrm{num\_qualifiers}_i}{\sum_{b \in B} \mathcal{R}_b \times \mathrm{num\_qualifiers}_b}. \end{equation}

The reliability score \mathcal{R}_i for benchmarker i is the weighted average of their qualifying benchmarks’ reliability scores, where a benchmark’s reliability score is based on that benchmark’s ratio of solutions to attempts. See the next section for details.

To enable a configurable limit on the maximum relative advantage that can be gained through reliability, \mathcal{R} is bounded to the range [\mathcal{R}_{\min}, \mathcal{R}_{\max}]. The constant \frac{\mathcal{R}_{\max}}{\mathcal{R}_{\min}} = C determines the strength of the direct incentive for benchmarkers to adopt algorithms that achieve higher ratios of solutions to attempts, a characteristic we expect to be associated with more explorative algorithms that invest computational resources in finding higher-quality solutions.

With the revised calculation we account for the aspects we care about:

  • \textbf{Quality}: This refers to how close solutions are to the optimal value. The new direct incentive for high solutions to attempts ratio means the difficulty frontier for each challenge better represents the true quality achievable with current algorithms and computational resources in the network.
  • \textbf{Speed}: This refers to the speed at which solutions are produced. While this is already naturally incentivized through higher solution rates leading to greater rewards, the previous mechanism lacked sufficient emphasis on solution quality. The revised calculation creates a better balance between these two aspects.

\textbf{Calculating} \mathcal{R}

For each challenge, a benchmarker’s reliability score is calculated through the following process:

  1. For each qualifying benchmark k, calculate its solution ratio r_k:
    \begin{equation} r_k = \frac{num\_solutions_k}{num\_nonces_k}, \end{equation}
    where num\_nonces_k represents the number of challenge instances the benchmarker attempted to solve for that benchmark.

  2. Determine the solution ratios a and b at a lower and upper weighted percentiles respectively, using num\_nonces as weights. The weighted percentiles are the sorted solution ratios at the p-th per cent of the total num\_nonces weight. This ensures benchmarks with more attempts have proportionally greater impact on the percentile boundaries.

  3. For each benchmark k, calculate {w}_k:
    \begin{equation} {w}_k \equiv f(r_k) := \begin{cases} \mathcal{R}_{\min}, \ r_k < a \\ \mathcal{R}_{\min} + \frac{\mathcal{R}_{\max} - R_{\min} }{b-a} (r_k-a), \ a \leq r_k < b \\ \mathcal{R}_{\max}, \ r_k \ge b \end{cases} \end{equation}.
    Hence, the solution ratios a and b are defined such that f(a) \equiv \mathcal{R}_{\min} and f(b) \equiv \mathcal{R}_{\max}.

  4. For each benchmarker i, compute their overall reliability score as the weighted average score of their benchmarks K_i: \{{{w}}\}_i
    \begin{equation} \mathcal{R}_i = \frac{\sum_{k \in K_i} num\_nonces_k \times {w}_k}{\sum_{k \in K_i} num\_nonces_k}. \end{equation}

\textbf{Parameter Selection}

We propose an initial setting of \mathcal{R}_{\max}=1.5 and \mathcal{R}_{\min}=0.5 such that \frac{\mathcal{R}_{\max}}{\mathcal{R}_{\min}} = 3 to provide a meaningful incentive for innovation of algorithms with improved reliability, and use of 25th and 75th percentiles for robustness against manipulation (see next section).
These settings can be adjusted in the future based on observations of the network and/or expert feedback.

The block reward weighting is visualised here:


Bounded linear reward function with the requirements f: [\mathcal{R}_{\min}, \mathcal{R}_{\max}] and \frac{\mathcal{R}_{\max}}{\mathcal{R}_{\min}} =3. \mathcal{R}_{\min} and \mathcal{R}_{\max} reflect the 25th and 75th weighted percentile respectively. \mathcal{R}_{\mathrm{med.}} is the weighted median for the challenge. The red reference points in the figure are from some arbitrary distribution of r_k for illustrative purposes.

\textbf{Discussion}

The proposed enhanced calculation has two key advantages:

  1. \textbf{Dynamic Adaptation:}
    As algorithms improve, the use of percentiles ensures the calculation automatically adjusts, maintaining consistent incentives for higher reliability.

  2. \textbf{Robustness Against Manipulation}
    The choice of 25th and 75th weighted percentiles provides resistance against manipulation strategies such as submission of many small benchmarks. Also, the piece-wise linear function ensures smooth transitions, discouraging threshold-gaming behaviour

2 Likes

A Revised Enhancement of the Block Reward Function.

Before diving in, I’d like to introduce myself—I’m Daniel, a new member of TIG Labs.

We are simplifying our proposed revision to the block reward function and invite discussion on this new design.

Overall Motivation

Our motivation remains the same: Benchmarkers are currently incentivized to maximize the number of qualified solutions. However, this creates a bias toward greedy algorithms, misaligning innovation in TIG with real-world adoption.

Motivation for Revising Our Proposal

The previous proposal had a fundamental flaw. By using weighted percentiles based on the number of nonces, greedy algorithms— which naturally generate far more nonces— could disproportionately skew the percentiles. As a result, greedy algorithms could achieve high reliability scores, undermining the mechanism’s core purpose: to favor sophisticated algorithms over greedy ones.

This revised proposal addresses the flaw by eliminating the use of a global metric (i.e., percentiles). Instead, each Benchmarker’s score will be calculated solely based on their own benchmarks.

The New Proposal

A Benchmarker’s reward across all challenges is an increasing function of their reward factors. Reward factors are calculated using all qualified benchmarks over the recent 120 blocks.

For a challenge x, and Benchmarker i, denote:

  • S^i_x total number of solutions,
  • V^i_x total number of nonces,
  • f_x^i total number of qualified solutions,

in their qualified benchmarks for challenge x. Also denote their solution ratio as

r_x^i= \frac{S^i_x}{V^i_x},

and their reward factor as

\hat f_x^i := \frac{f^i_x (r_x^i)^{\alpha_x}}{\sum_j f^j_x (r^j_x)^{\alpha_x}}.

The exponent \alpha_x controls sensitivity to greediness. Initially, we set \alpha_x = 1 for all x. The logic for adopting this expression of \hat f_x^i is that

\text{reward factor} \propto \text{(qualified solutions)} \times \text{(solution ratio)}^\alpha.

This encourages Benchmarkers to adopt algorithms that generate many qualified solutions while also favoring those with a higher solution ratio.

Example
Benchmarker Solutions S_x^i Nonces V_x^i Solution Ratio r_x^i Qualified Solutions f_x^i Reward Factor \hat f_x^i
Alice 100 200 0.50 80 0.625
Bob 300 3000 0.10 240 0.375
Totals 400 3200 320 1

We see from the table that even though Bob has 3× more qualified solutions than Alice, his low solution ratio (0.10) reduces his reward factor significantly.

Effect on the Frontier.

We expect that Benchmarkers will begin to adopt less greedy algorithms, but since fewer solutions will be found, the frontier will initially recede. As players create better algorithms with good solution ratios, the frontier will again grow.

A Failsafe Feature

In addition to the incentive structure favoring less greedy algorithms, we introduce a failsafe criterion to ensure that benchmarks maintain a minimum level of reliability.

For a benchmark to qualify in a given block, its solution ratio must be at least 10% of the previous block’s average solution ratio. That is, if the average solution ratio of all qualified benchmarks in the previous block was r, then a benchmark can only qualify if its solution ratio is at least 0.1 \times r.

Benchmarkers may still submit benchmarks with a lower solution ratio, but these will not qualify for rewards in that block.

Like the exponent parameter \alpha_x introduced earlier, the 10% threshold is subject to future tuning.

This mechanism prevents a potential cyclic equilibrium, where:

  1. Sophisticated algorithms push the frontier down by favoring high-quality solutions over sheer quantity.
  2. Once the frontier is sufficiently low, greedy algorithms regain an advantage by exploiting their sheer volume of nonces.
  3. This cycle could repeat indefinitely, preventing stable progress.

By enforcing a minimum reliability threshold, we prevent greedy strategies from dominating the system once the frontier has receded.

Am I right in thinking that benchmarkers that work at higher difficulty levels closer to “scaled” in order to produce qualified solutions (since the nonce/solution count will be higher), end up with a worse ratio. As a result, their profitability is lower than at lower difficulty. Moreover, such a benchmarker can end up with no reward for its solution if it fails to meet the failsafe threshold, even if it does have a valid solution on the most difficult frontier.

Hi Haver,

Glad to have you involved in the conversation. That is a great question!

If a benchmarker has two benchmarks within the frontier’s difficulty band, we expect the band to be narrow enough that the solution ratio between the benchmarks remains relatively constant. This stability implies that their profitability will not drop significantly, and the failsafe should not be triggered.

Ultimately, the primary objective is to achieve qualifying solutions, so targeting a slightly easier difficulty will not provide a meaningful advantage.