# Enhanced Block Reward Function

**URL:** <https://forum.tig.foundation/t/enhanced-block-reward-function/46>\
**Category:** Protocol Enhancements\
**Created:** [February 20, 2025, 1:05pm UTC](https://forum.tig.foundation/t/enhanced-block-reward-function/46 "2025-02-20T13:05:13Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![kilian](https://avatars.discourse-cdn.com/v4/letter/k/ee7513/32.png) [@kilian](https://forum.tig.foundation/u/kilian)\
**Post date:** [February 20, 2025, 1:05pm UTC](https://forum.tig.foundation/t/enhanced-block-reward-function/46/1 "2025-02-20T13:05:13Z")

</div>

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](https://europe1.discourse-cdn.com/flex018/uploads/tig/original/1X/9d6ef72a4b96b59ecf30838ef22940a4ed2258e2.jpeg)  
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

---

<div class="post-metadata">

**Author:** ![DanielAdams](https://avatars.discourse-cdn.com/v4/letter/d/da6949/32.png) [@DanielAdams](https://forum.tig.foundation/u/DanielAdams)\
**Post date:** [March 14, 2025, 4:51pm UTC](https://forum.tig.foundation/t/enhanced-block-reward-function/46/2 "2025-03-14T16:51:24Z")

</div>

## 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.

---

<div class="post-metadata">

**Author:** ![haver](https://avatars.discourse-cdn.com/v4/letter/h/76d3ee/32.png) [@haver](https://forum.tig.foundation/u/haver)\
**Post date:** [March 20, 2025, 5:01am UTC](https://forum.tig.foundation/t/enhanced-block-reward-function/46/3 "2025-03-20T05:01:33Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![DanielAdams](https://avatars.discourse-cdn.com/v4/letter/d/da6949/32.png) [@DanielAdams](https://forum.tig.foundation/u/DanielAdams)\
**Post date:** [March 21, 2025, 9:03am UTC](https://forum.tig.foundation/t/enhanced-block-reward-function/46/4 "2025-03-21T09:03:04Z")

</div>

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.