TIP-084 - Changing the tBTC reward calculation to daily eligibility

Proposals
1

TL;DR

We propose changing the tBTC reward calculation from a monthly to a daily (which we can extend to a seconds) eligibility model.

Background

Every few months, the core team releases a new version of the tBTC application, as seen in the release notes. Following each release, node operators are given a three-week upgrade window to remain eligible for rewards.

Currently, according to the reward script, a node operator must meet the following requirements to be eligible for rewards:

  • Authorization of Random Beacon and tBTC app
  • Minimum 500 pre-params in average
  • Uptime ≥ 96%
  • Eligible client build version

During the upgrade window, both the old and new client versions are eligible for rewards. Under the current monthly eligibility model, if a node operator misses just one day within the upgrade window, they forfeit the entire month’s rewards. This situation is particularly harsh and unfair to operators who might miss the deadline by a very short margin.

It is essential to highlight that this proposal is not intended to blame or punish node operators who may miss the upgrade deadline by a few days. Under the current monthly model, missing the deadline results in forfeiting an entire month’s rewards, which can be disproportionate and discouraging. The daily eligibility model will allow for a more forgiving system where minor delays in upgrading do not lead to significant losses in rewards. This change will support node operators in maintaining their participation and motivation to keep the network secure and up-to-date.

Proposal

We propose modifying the reward mechanism so that node operators’ eligibility is evaluated daily rather than monthly.

To ensure fairness, we also recommend reviewing past rewards eligibility and compensating node operators who may have missed out on rewards due to the previous strict monthly calculation model.

This proposal involves three key workstreams:

  1. Updating the Reward Calculation Script: Implement a pull request (PR) to change the reward calculation from a monthly to a daily basis.
  2. Calculating Retroactive Compensation: Review past releases over the historical data availability period (1 year at the moment) to identify affected node operators and calculate the difference in rewards they would have received under the new daily model.
  3. Reimburse node operators: If using monthly calculation scheme any node operator had lost some rewards while being eligible for rewards using new daily calculation scheme - then need to calculate the difference and reimburse such node operator during next calculation period.

For example, consider the following scenario:

  • On May 1st, 2024, rewards are calculated for the month of April.
  • A new version of the tBTC application was announced on April 4th, 2024, with a required upgrade by April 26th, 2024.
  • StakingProvider1 and StakingProvider2 were fully compliant until April 26th, 2024.
    • However, because they missed the upgrade deadline by a few days, they lost all of April’s rewards, resulting in an unfair situation where they received 0 T rewards.

Under our proposal, these node operators would be rewarded for the 25 days they were active. Their compensation would be calculated as (authorizedAmount * tBTCRewardRate * daysInDuty / daysInYear).

image
image2000Ă—712 99.5 KB

ineligible 5 days includes 26th of April

Rationale

Switching to a daily eligibility model ensures that node operators are consistently maintaining and updating their systems. This approach mitigates the risk of having outdated software running on the network, which can lead to potential vulnerabilities and reduced performance. The daily eligibility model will allow for a more forgiving system where minor delays in upgrading do not lead to significant losses in rewards. This change will support node operators in maintaining their participation and motivation to keep the network secure and up-to-date.

Historical Context

The community has seen several version announcements, such as:

image
image2000Ă—875 133 KB

This chart shows announcement of the releases might lead loss of rewards partially or fully depending on the announcement date.

2

While it would be helpful to see data on how many providers miss the upgrade deadline and by how many days, I’d first ask why you think that relaxing the deadline requirement would “ensures that node operators are consistently maintaining and updating their systems”. Aren’t some likely to be slower to update if there’s a lot less to lose?

1 Like
3

I second this question @JohnPackel. Personally, I’ve always thought that a three week window to upgrade a node was a very long time. I can see how the loss of rewards is painful, and it’s happened, however, that has been motivation to upgrade promptly, especially if this is going to be a primary business activity.

This (above) I CANNOT support. Retroactively awarding rewards for nodes that did not meet the requirements is essentially punishing those that did upgrade timely.

I feel this proposal will undermine the serious nature and responsibility that node operators choose to accept when they spin up their nodes. Switching to daily reward calculations will create a disincentive to stay focused and upgrade timely.

1 Like
4

Hey @JohnPackel
Thank you for sharing your view. It’s totally valid to ask.
In a short while, I’ll prepare a rough report to share with you about the impacted providers.

Firstly, I want to emphasize that this isn’t about relaxing the deadline requirement. It’s about creating a fair environment for all contributors in the network. While the wording in your quoted section might seem off, the intention is to support the ecosystem and lower barriers for newcomers to operate their own nodes. How?

Message is simple:

  • As long as a node operator comply with the network qualifications, they get rewarded at the end of the month for the days they contributed.
    – This TIP aims to address concerns by isolating rewards from the release calendar. Why?
    – In previous releases, such as before v2.0.0, node operators were still eligible for rewards even with the older version due to the transition period.
    – The release announcement date is creating either unfair advantage or a risk of partial reward loss. Especially when updates are announced in the beginning of the month.

Therefore, this approach contradicts our current practice, and we believe it needs to be revised.

Lastly, you’re correct in your observation, and I’d like to offer another perspective.

Aren’t some likely to be slower to update if there’s a lot less to lose?

What’s the incentive to update early if the deadline doesn’t impact rewards? Only if the deadline has passed and the upgrade hasn’t been made should there be consequences. The key here isn’t the deadline—it’s fairness, sustainability, and predictability.

Let me know your thoughts!

5

Hey @Vict0r
Thanks for your perspective. I also agree with you in some aspects.

Yes, 3-week window sounds like really long time. However, I believe this window needs to be irrelevant from the rewards. In the future, we can decide to make it 5-weeks or just 1-week. These may sound exaggerated examples however let’s say

  • if we agree in 5-weeks window,
    • a node operator with the old version might still receive the month rewards in full,
  • if we agree being 1-week window
    • then again, it’ll create unfair advantage or unnecessary slashing of the node operators. Especially when updates are announced in the end of the month.

The network contributors should be rewarded by the number of days they’re qualified within the requirement set.

I understand your point about the retroactive compensation however, this is not making ineligible nodes eligible or vice versa. It’s about recognizing the honest nodes that continued to contribute to the network during the transition phase properly.

According to your view, node operators in below who did not complete the upgrade by the end of February should not have received rewards, yet they did.

image
image2640Ă—488 36.4 KB

We rewarded these node operators because it was fair and their right to receive what they had earned. They were supportive of the network by the 4th of March, however, they are disqualified if they haven’t upgraded.

  • A binary, all-or-nothing approach sets the bar too high for introducing new node operators and creates scarcity. We only have 12 opportunities to compensate them for their contributions, and the current method discourages participation.
  • As we plan to introduce a slashing mechanism with the sunset of the Beta Staker Program to address dishonest operators, the current implementation is already somewhat punitive.
  • The retrospective approach helps correct this unfair advantage. An alternative method would be to disqualify these node operators and asking them to pay back the amount you believe should be disqualified, which is impractical.

I believe you will see the fairness and predictability of the mechanisms we are proposing.
Happy to answer your further concerns

6

Thanks for the explanation, however, I’m afraid I don’t follow. I read the phrase “unfair advantage” and “fair.” The playing field is flat, everybody is subject to the same rules.

Can you explain why three weeks is not enough time? The timing of a client upgrade cannot always be predicted, particularly if there’s security related patch.

I’m also not clear why upgrading seems to be a heavy lift. I run multiple nodes, each via Docker, no K8s. I use compose. Even if you start the node manually - an upgrade can be deployed in minutes. Stop node, pull new image, (adjust run command if you specify version), restart node, verify it’s running.

1 Like
7

Hey again @Vict0r
We’re on the same page. Neither I excuse about the 3-weeks window nor I’m not complaining the complexity of the upgrade.

Our point in simple words:

  • The monthly calculation is problematic particularly when a release announced.
    Below, I have added more explanation:
    image
    image3096Ă—857 208 KB

We just need this behavior to be corrected to ensure fairness, sustainability, and predictability of the network. This TIP explains how.

8

Let me add my vision/explanation as well. As I see there is some mess between several topics:

  1. 3-week upgrade window
  2. automatic upgrades
  3. Threshold Network approach to calculate rewards based on metrics stored in Prometheus database (uptime, version, pre-generated parameters, etc)

This TIP is about the last point - enhancing the script/approach Threshold Network uses to calculate rewards. It doesn’t deal with upgrade window length and doesn’t affect all the reasons why these eligibility parameters were set in the past - they are in place still cause we don’t change them, all the requirements are working fine.
And there is nothing about upgrade procedure itself - it can be automated in many ways, upgrade window period can be discussed/changed in some other TIP if needed, this TIP is not about all of this, let’s put all these topics away and concentrate on proposal idea itself.

All we propose in this TIP is improvement, as it’s supposed to be in TIPs. Actually, we just suggest to improve the calculation resolution, cause right now it’s too rough. Prometheus stores all the parameters in seconds resolution, but the outcome of calculations is done in months. That’s a too big difference, which can create unfair conditions.
E.g. we had such a case when a node was mistakenly downgraded for 7 minutes, then we got an alert about and fixed the issue. But Prometheus caught this change and since the version was not eligible - we lost rewards for the whole month, although being not eligible for 7 mins only. This seems unfair to me.
That’s the type of cases we want to escape for all node operators by improving resolution. And once we have the technical possibility to improve it - let’s do it. It would be a win-win solution - node operators are motivated to upgrade in time still - no one wants to lose rewards, Threshold Network would keep most of the nodes available and upgraded in time, and node operators would not be stressed/scared by too rough/unfair calculation of rewards. That’s the idea.
Moreover, I want to emphasize, that the current approach/script resolution doesn’t help to escape such cases as too-late node upgrades or misconfiguration/wrong version. That just happened for us in April/May and I believe we were not the first ones and not the last ones. It just happens, no one can escape the human factor by any of the restrictions. But we can improve restrictions to be more fair.
I think the current script implementation is a result of some simplification which was like “well, we accept it right now” in the past, but as time goes by and we have this TIPs system in place and we can improve some code - I believe that’s a good time to just do it.

I hope the idea is clear now and doesn’t contradict other topics. Let me address some other questions here.

There were questions about this part of the proposal

Switching to a daily eligibility model ensures that node operators are consistently maintaining and updating their systems. This approach mitigates the risk of having outdated software running on the network, which can lead to potential vulnerabilities and reduced performance.

That’s a good point and I can only admit that switching to a daily eligibility model doesn’t have such an effect. These sentences were put here by mistake, we had multiple versions of this proposal over time and it’s just a copy-paste issue. I thought we removed them from the final version, but unfortunately, these phrases leaked here somehow.
Anyway, these sentences don’t affect the idea of this TIP, so I assume we can just ignore them as I acknowledged this was a copy-past issue.

Few things I want to share my vision about. As Victor posted:

Retroactively awarding rewards for nodes that did not meet the requirements is essentially punishing those that did upgrade timely

I cannot agree with this cause technically it’s not the case. Those node operators who did upgrade in time - they got their fair rewards. No punishing, nobody reduces their rewards. At the same time “Reimburse node operators” part of this proposal aims to return more fairness to this process. As I described above, there might be cases when a node was technically not eligible for rewards for some small time (even less than 10 mins), but it had lost whole month rewards.
As the reason is just a technical one (the way the rewards calculation script is implemented) - we can resolve it technically. Moreover, we have historical data for 1 year - let’s fix the possible issues in the past (especially once we know about them) - this would be a proactive fair step towards all the node operators who might lose rewards because of too rough calculation scheme.
This truly correlates with principles of equality, and fairness and would be an improvement for all the node operators, and all the community.

I understand @Vict0r’s concerns about “this proposal will undermine the serious nature and responsibility” - node operators can indeed feel more relaxed and miss some upgrades in time not being scared to lose all month rewards. That’s a good point, I agree. At the same time everyone is in the same conditions and if a node is not eligible - it would lose rewards still.
That’s more a philosophic aspect which I don’t think we need to go deep into (cause it’s TIP) - what is better to rely on: fear and punishment, or willingness to have a win-win cooperation. For some people the first scheme works better, for others - the second one. I don’t think we would find the truth here.
At the same time each and every node operator is motivated to upgrade nodes in time, cause anyway even if they don’t lose whole month rewards - they would lose every second/day of rewards, when their node was not eligible. Thus motivations and rules are in place still, I see no issue here.

To be honest and trying to find an even better solution - I think it worth to raise another TIP about shortening upgrade window. 3 weeks is a really long period, especially when nodes can be upgraded automatically if someone doesn’t want to track the upgrades schedule tightly. So at least there is an option for lazy/nondisciplined people.
And as Threshold Network moves toward exiting the beta stakers program, the time when most of the nodes must be upgraded should be shortened I think.
Moreover, as per my understanding this TIP and the one which might shorten the upgrade window period - these 2 ideas work perfectly with each other. I think one of the reasons the 3-week period is used to ensure that all the community members have enough time to upgrade taking into account that if someone missed - all the rewards would be lost.
But once we say: no worries, you would lose rewards for those secs/mins/days you missed the upgrade timing - then we can truly shorten upgrade window time, it would be wise and fair at the same time. We do improvement in this TIP and after this we can do another improvement, which would NOT be so stressful once the calculation resolution is changed. I see a win-win solution here.

1 Like
9

This proposal has moved to Snapshot

1 Like
10

Thanks for all the explanations. I’m trying to understand them fully before voting.

This scenario you describe isn’t clear to me: “E.g. we had such a case when a node was mistakenly downgraded for 7 minutes, then we got an alert about and fixed the issue. But Prometheus caught this change and since the version was not eligible - we lost rewards for the whole month, although being not eligible for 7 mins only. This seems unfair to me.”

7 minutes is 0.016% of a month, so I assume the uptime wasn’t the issue. Does “since the version was not eligible” mean that the mistaken downgrade reverted to an old version, and that’s an automatic disqualifier for rewards?

@Vict0r when you have a chance to help clarify my understanding I’d appreciate it. Thanks

11

@JohnPackel the scenario described here is not a matter or uptime, like you concluded. Spinning up a node with an old or ineligible version is indeed treated harshly and leads to loss of rewards. The reasoning behind this is straight forward: security. Fortunately, we have not had a situation where an exploit had to be patched in a hurry, but, IF a release contained a zero day that was patched in a subsequent release, and a node is brought online with the old, unpatched version, the network could be exploitable.

This exactly what I’m talking about. This proposal will create a situation where misbehavior is no longer disincentivized or punished.

The current system isn’t perfect, but the rules are uniform for everybody, there’s nothing “unfair” afoot. tBTC nodes custody millions in funds, it would be unfair to not have heavy penalties for this. Running a node is not easy.

I understand that lost rewards are painful. But i maintain the stance that I will oppose this proposal, particularly because its goal is to reimburse rewards lost due to human error (not upgrading in time is human error).

1 Like
12

Following the Snapshot vote we find that this proposal has been declined by the DAO with the following results:

  • Decline: 1B T - 97.69%
  • Approve: 24M T - 2.31%
  • Abstain: 0 T - 0%

We want to thank @metoinside and the P2P team for your availability and responsiveness around this proposal, we appreciate everyone’s participation in this process.

1 Like
13

Yes, thank you @metoinside and @Asmanx for the proposal and discussion. While token holders didn’t support the reward calculation change, I think we need to remain responsive to the views of node operators and should “support the ecosystem and lower barriers for newcomers to operate their own nodes”.

If there are other aspects noted here (e.g., support with upgrades) you’d like to discuss further please let me know. I’m happy to host a call.

2 Likes