GEP - Minting and Farming Rewards Updates (March 2024)

#1

Contents

  • Introduction
  • Proposal Summary
  • Proposal Details
  • GEP Conclusion
  • Remarks

Introduction

The following is a new grid enhancement proposal (GEP) for the ThreeFold Grid (TFGrid). We built this GEP thanks to the amazing feedback of the whole ThreeFold community, farmers and users alike.

The goal of this GEP is to set new rules to make the TFGrid more reliable for utilization and bring the interests of all parties together for the greater good of the grid.

The following GEP applies for all nodes within the current grid.

Note that there is not yet an on chain vote live for this proposal. We’ll allow a week for any comments and discussion, and then proceed with a vote.

Proposal Summary

  • 95% and 98% uptime requirement for DIY and certified nodes respectively
  • 50% of proof-of-utilization revenues will go to the farmer running the 3Node
  • Minting will be slashed for 1 month if the node cannot wake up within 30-minutes twice within the same minting period
  • When we reach 1 Billion TFT on Stellar, minting stops on Stellar
  • TFT burning will stop

Proposal Details

We provide the basic updates to the TFGrid.

Uptime Requirements

  • DIY Nodes: 95% uptime per month
  • Certified Nodes: 98% uptime per month

Proof-of-Utilization Revenues

  • 50% of the proof-of-utilization revenues from grid use will go to the farmer running the 3Node being used

Notes

The farmers receive 50% of the utilization of the grid. TF Engineers are investigating how to implement this best, it’s not certain that this will happen on TFChain maybe it will be a combination of a new API gateway running with the cooperative as well as TFChain launched workloads.

The remaining 50% will be distributed as follows: 40% will go to TF cooperative (TF DMCC for now) and 10% to the stakers on the validators.

30-Minute Wake-up Minting rule

  • Minting will be slashed for 1 month if the node cannot wake up within 30-minutes twice within the same minting period.

Notes

The idea is to give a pass for low probability events (like brief power/network outages for the farmer, TFHub going down), while still ensuring that nodes with chronic issues can’t continue using Farmerbot to mint. It also gives the farmer an opportunity to correct any issues that come up in their infrastructure without an immediate loss of earnings.

TFT Minting Cap

  • When we reach 1 Billion TFT on Stellar, minting stops on Stellar

TFT Burning Stops

  • We will stop burning TFT

GEP Conclusion

We invite community members to vote for this GEP.

Thank you for your time and we hope this GEP answers many feedback and queries from all of you.

Remarks

Utilization Revenue

Note that accumulated revenue from past utilization will go to the cooperative treasury.

Contact Info for Farmers

To improve the quality of the network, TF needs to be able to communicate with the farmers hosting workloads from users on the grid. For this reason, farmers need to supply their email address and telephone number.

This is needed to resolve support issues and allow TF to communicate with the farmers. The exact way to implement this is not yet decided. We don’t know how to implement it yet. When this will be implemented, the idea is that if farmers do not provide the relevant information within a given amount of time, the nodes of the farmer would not be eligible on the grid.

Users KYC

Users that spend over 1000 USD on the TFGrid will need to go through a KYC process.

Pricing Adjustment for Older Hardware

There was a suggestion to change the way we mint for Nodes with DDR3 or lower type of RAMs. With the feedback we had from the TF Engineers, it seems that DDR3 is not sufficient by itself as a quality measurement of a node. We are looking for other ways to measure in a more objective way if hardware is getting too old and users pay according to the node quality.

GEP implementation time

Not all propositions here might be implemented in the short term. The goal of this GEP is to have a clear agreement with the community of where the project is heading.

Terms and Conditions Reminder

As a reminder, ThreeFold reserves the right to stop minting for and otherwise blacklist any node that is in violation of the terms and conditions.

Node Monitoring will be visible in Explorer and UI

We are planning to add many features on the Dashboard to make sure users can know as much as possible on the nodes they are deploying on (e.g. uptime, bandwidth, hardware used). We aim to implement this for 3.14.

Farmers and Farmerbot Notes

Bugs in the code (e.g. ZOS or other components) can happen. If this is the case, there might be a loss of tokens during minting which won’t be refunded by ThreeFold. If there are minting code errors, ThreeFold will try its best to fix the minting code and remint nodes that were affected by such errors.

The Farmerbot is an optional feature developed by ThreeFold. Please use at your own risk. While ThreeFold will do its best to fix any issues with the Farmerbot and minting, if minting is affected by the use of the Farmerbot, ThreeFold cannot be held responsible.

4 Likes
Vote: Minting & Farming Rewards GEP + Upcoming Community Calls
Farmerbot Bonus
Bot Synergy: Node Status Bot + Farmerbot
Farming rewards proposal: adjusted handling of violations
#2

  1. proof of utilization should come with a change in fixed rewards, ie don’t just add on rewards instead it should displace some of the fixed rewards

  2. no broad kyc. All kyc should be p2p and individually selected by the farmer and the deployer. 3node farmers can choose to provide a kyc’d node or not and if they will allow non-kyc utilizers or not. Tf gird utilizers can choose if they want kyc’d nodes and if they want to undergo kyc to access better nodes. kyc should be stored in smart contracts that neither party can access without mutual permission from both parties or possibly the local validator and one party.

  3. A new GEP should be made to disallow having GEP’s with multiple unrelated changes being bundled together

5 Likes
#3

adding on to the kyc aspect…it could be programmed to meet local laws where some places may not allow non-kyc’d transactions. I don’t like this idea but respect that may be necessary to avoid problems

1 Like
#4

To add back up to my 2nd paragraph I quote Jerzy for the chat

“but just think : you can spend like 2 days deploying something awesome and then a farmer will think - i dont need this and turn off”

(this post should follow the one below)

2 Likes
#5

Monthly token distributions continue to destroy the token due to supply increases. I propose to enact the originally planned token lockup. This solves monthly supply rushes and further incentivizes better quality hardware as the lockup is released with 30% utilization. This is the perfect time to exact as most higher quality hardware already over this threshold. The ability to have this balance build up with earnings is a possibility too.

Further, I propose a modest balance requirement of xxx TFT per CU on all new hardware after node XXXX. Slashing for various infractions can be built in after this requirement. Even without slashing, it will add utility to the token and put slight resistance on network growth outstripping demand. Unfettered capacity growth is only a drag on the project. Alternatively, lowering the idle TFT base rewards as also suggested by testtrack can have a similar benefit.

3 Likes
#6
  • 95% and 98% uptime requirement for DIY and certified nodes respectively

This is essential. There are numerous reports of farmers shutting down or re-registering nodes once a workload is deployed which is obviously detrimental to the project. It’s damaging in multiple ways - not only to the user who loses their deployment but from a project marketing perspective it’s a huge red flag on reliability. Having said that, the current incentive structure strongly discourages hosting workloads - if earnings are the same regardless of whether a node is sleeping, idle or maxed out the rational thing to do is wipe the node and start over - hopefully uptime requirement along with revenue share is enough to tilt the incentives.

For clarity, and assuming a DIY node, the uptime proposal means new nodes will earn nothing for their first minting period (besides potential revenue share) unless they’re deployed within the first 1.5 days of the cycle.

  • 50% of proof-of-utilization revenues will go to the farmer running the 3Node

This is needed to help bring project and farmer incentives in line. Curious how it will be implemented, especially with regards to the token lock proposal, but expect details to follow.

  • Minting will be slashed for 1 month if the node cannot wake up within 30-minutes twice within the same minting period

Again, necessary to encourage grid reliability. I feel there needs to be a reliable way for farmers to be notified of violations and maybe this will be integrated into the KYC proposal, although having someone from Threefold manually send an email on violation is obviously unworkable. Scott’s telegram bot is great and I believe there was a discussion around integrating random wake violation notifications. An alternative would be for the grid to deny sleep ability (for the remainder of the minting period) to any node with a single violation however I have no idea whether this is technically feasible and it’s questionable whether it’s desirable from either the grid or farmers perspective.

  • When we reach 1 Billion TFT on Stellar, minting stops on Stellar

Reduced token cap can only be a good thing.

  • TFT burning will stop

I’d like to play devils advocate and ask “why?” along with the question of how many tokens have been burned so far? I’m assuming the burned tokens make up a proportion of the 1bn total supply but will obviously never be included in circulating supply.

  • KYC

In terms of farmer KYC/contact requirements, my understanding is it’ll be limited to email and sms, both of which can be handled with burner accounts. It seems KYC in this fashion is limited in its efficacy however I fear if the project were to require too intrusive (from each farmers’ subjective definition of intrusive) KYC, the grid will take a step backwards. I can imagine a Government issued ID requirement to run a node would be too much to bear for some.

As far as KYC for customers - is this a monthly spend? Lifetime? Clarification needed.

  • Hardware

There appears to be a consensus over hardware with regards to its usefulness on the grid. A few ideas have been floated, from different tiers to outright banning of hardware beyond an arbitrary age/technology/benchmark. Something needs to be done to ensure the grid stays attractive but I think to some degree this will fix itself with higher visibilty in regards to node specifications at the time of workload deployment, especially once v4 comes with earnings linked entirely to utility. Those using the grid are likely to be aware of their requirements and will vote with their tokens, so to speak. I like the idea of tiers but the details will need to make sense for all stakeholders. I’m also curious how any adjustments would fit with the 5 year agreement made between farmers and the grid.

  • Token lock

This isn’t mentioned in the GEP but I feel I need to say something on the topic. Personally I’m against any kind of token lock beyond maybe a requirement for staking on individual nodes or farms - I think the market should decide the value of an asset and any attempt to manipulate the price by way of supply restrictions is not something I can get behind. I understand this goes against a vocal minority, including from within the Threefold foundation, but when I read things like Kristof’s comments here: https://github.com/threefoldtech/home/issues/1448 in particular “we should make liquidity less important compared to price, so if not < 0.1, then is harder for people to sell” and “we show the token distribution in clear way also on website, so people know where tokens are and who is selling” - this is not how the free market works. I’m not sure what the implication of these comments are - whether there’s a conflation of “if you sell you’re not supporting the project” or tying together economics and some idea of virtue? Regardless, when the market places enough value on the product, there will be no need for restrictions or, what I can only interpret as a need to shame or flag sellers.

2 Likes
#7

Regarding pricing adjustments:
As an early adopter promised fixed rewards for five years, these changes feel unfair, especially for those of us who invested based on initial guarantees.

I propose the following for consideration:

Grandfather Clause for existing nodes, preserving initial reward terms.

Adapting and evolving the grid is crucial, but so is honoring the trust and investments of its early supporters. I believe in our project and am keen on working together towards solutions that respect both the grid’s future and its founding contributors.

Thank you for your attention to this matter.

2 Likes
#8

Rewards are increasing. What are you referring to?

#9

Question about the minting stop after the 1 billion is reached.
It is mentioned it will stop on the stellar chain, but it doesn’t mention about the other chains. Will we still received rewards but from different chain?
If not, are we actually still going to get rewards after that point or is it going to be stopped?
As of now, it looks like we have about 1 year worth left. ±940M total supply left - 885M minted = 55M left at a monthly mint rate of ±5M = 11 months (got this info from the stellar explorer, if it’s incorrect, please correct me!!)

If the burning is stopped, what will those coins be used for? Why hasn’t those coins be put back into the rewards pool?

To lock rewards for a certain time, I am not supporting this. With the excessive kWh rates, I do need to be able to pay my electricity bill from the rewards received.

Maybe a dynamic reward system, where you earn a set amount of tokens depending on the actual token price, uptime % and system hardware, would have been a better strategy.

Pricing adjustment for older hardware, in my opinion, is not fair. First, not everyone can afford new up to date hardware. Second, isn’t it also to promote to actually repurpose older equipment? Maybe for new farms, there can be a minimum requirement. But would suggest not for existing ones. If the system can keep up with the 95% uptime requirement, it should matter if it’s DDR3 or 4 or 5. If it does starts to fail that, then farmer can decide to upgrade or not.

KYC for users and for farmers might be needed above certain $ spending/earnings depending on country laws/taxes. Not sure if this is something TFT needs to oversee or the individual him/herself.

Staking to new and existing nodes might be useful to reduce the floating coins on the open market. There should be a clear difference between old and new nodes stake requirement. Even between 5 year old nodes and 1 year.
But the main challenge to reduce the sell pressure is demand in utility. There should be bigger and better promotion of our grid services. Maybe look into paid influencers. If Flux can continue to grow, so can we. We should become a better competitor of them. For example, why are people running presearch or timpi nodes on flux and not on Threefold. Mainly because they do not know they can.
I did run 6 presearch nodes on Threefold. I had them first on VPS services, but changed that when I noticed it was cheaper to run them on Threefold and also because I was able to use my earned TFT.

Grandfather clause should be set for staking requirements or use of older equipment, but should not for rewards distribution. Older farms, should have ROI’ed already on the initial cost. Rewards distribution should be adjusted for the longevity of the project.

4 Likes
#10

Hey John!

As per this GEP, farming rewards from proof of capacity stay the same, they do not decrease. Farners will get more revenues from proof of utilization also.

If we were to reduce poc rewards it would be for newly registered nodes after a potential GEP would be voted on. Hope that clears things up!

1 Like
#11

Why is everybody concerned about the token supply side, and not working on the demand side?

3 Likes
#12

I had it confused… regarding: Pricing Adjustment for Older Hardware.

#13

I think it’s a good idea to reduce token gaming. If farmers turn off nodes that are deployed on that will quickly earn the whole ecosystem a bad reputation. Locking up some initial amount of tokens based upon maximum potential earning per node makes sense to me. If my 48 core server returns 3000 tokens per month than 3000 tokens should be held as collateral and used as a collateral prize to deployers that go to invest time in creating workloads only to have them wiped out by a stingy farmer. First month in operation your tokens get held, next month you start getting paid. the initial months tokens can be transferred to other nodes so as to upgrade hardware, used directly on self deployments, or fully released one month? after an old node is laid to rest

1 Like
#14

system gaming will just discourage any new interest in by new demandees

#15

I think instead of uptime requirements there should instead simply be bouties people can earn from bad nodes. Your deployment goes down and you get back a certain number of tokens like maybe 4 weeks of deployments costs. The effect would be the same but add a more fun hunting aspect to it. I’m ready to root out bad farmers

#16

50% of what? The entire node? So only when 44 cores 350+ RAM and 4 TB is in use in some cases?
If so, that hardly seems to justify my electricity bill doubling…

I’d propose to find a way to decentralise this too. I’m fairly sure we’ll lose a lot of potential customers if they have to leave their details to “TF” but they may be willing to one of the many “TF-representatives” if they are being guaranteed data is not shared beyond them. Like some sort of middle man construction…

I’m also not sure and agree with TF techs. Just sold some used R620’s with 4 TB of nvme SSD each (and DDR3). Since I used them myself to deploy, these machines are doing very well for many more years. It may not be the best gaming platform but would do fine for many other applications.

Also, I refurbished some old TF nodes for some customers whom support a circular economy. Would not like to count thos epeople out.

Maybe we could somehow rate nodes.

1 Like
#17

Thanks Scott for bringing all this important points together.

I agree on many things you wrote. Here are some addtions (mentioned similar also by others):

  1. GEP:
    I agree with @tackrack that we should split each concern into separate GEP as this makes it more easy to vote later on and more structured for realization (as some will be implemented early, some later).

  2. KYC:
    I think KYC would slow down the growth of the network (especially on the customer side). At some point we need it, but would postpone that decision.

  3. Slashing:
    What I miss is more about slashing. We are slashing the node after 2nd time 30 mins violation. That’s ok and I think fair.
    But what about node operators that turn of their machines when it hits load and just create new nodes?
    One good point is to reward them more, so the costs for electricity can be covered and maybe we see this behavior less.
    But still the risk for customers is high that the operator just shuts down, changes something, etc.
    I agree with the others that we should introduce a collateral for each node and slash on misbehavior.

I’m curious to see what happens next and keep up the good work!

#18

It’s been a week. Can we expect any revisions and or a vote soon?

#19

Yes, you can expect the next steps within the next 24 hours.

#20

Hi everybody,

Thanks for your comments–I’ll address them below. We will be bringing the vote live without any revisions asap. That should be tomorrow or Monday at the latest.

Responses to comments

The idea here is really to increase rewards for farmers when their nodes are in use. Decreasing base rewards for all nodes has been proposed elsewhere too, but of course that’s going to be a hot topic.

I personally like the idea of a system where KYC is opt in as you describe. There could be some important use cases related to journalism and whistleblowing, for example. But our top priority right now is making the system safe in general, and adding some general KYC is the simplest way to do that.

We’d certainly like to avoid doing big GEPs that aren’t well focused–point taken.

The originally proposed locking mechanism in v3 is a way to balance the fact that there was no economic incentive (for reasons, by design) for farmers to run workloads. It would also have an effect of keeping some TFT off the market that was being minted to nodes without a corresponding demand for their capacity.

To me that second aspect is more about asking farmers to make a commitment towards the network before being rewarded for running idle capacity than it is about trying to manipulate the market.

Personally I’m a bit split on the topic of locking tokens. A big reason for me to oppose it is that is just makes the situation with TFT that much more complicated–it’s another form of the token out there that we have to track and support and explain.

Uptime for the first minting cycle is based on the portion of the cycle that the node has existed for. So for example a node joining halfway through a month will have about 18 hours of downtime allowed for the first month.

This is interesting. Actually it could be implemented simply as an optional feature of the farmerbot. The main challenge here is that assessing violations is a function of minting that requires parsing all the blocks of TF Chain to be sure about (this also represents a challenge for the Node Status Bot). Maybe some change could be made to accommodate this, but presently it’s not straightforward.

There are a couple reasons here. One is simply so that we have a nice round supply figure that never changes. Another is that it allows us to provide the utilization revenue to farmers while also keeping a nice flow coming into the foundation. Since the foundation also earned as the default solution provider, these changes otherwise represent a loss of revenue.

As for how many TFT have been burned already, that would be about 1.75M by my estimate. Let’s say that’s not an official figure though :slight_smile: Those TFT won’t contribute to the total supply, so in a sense they will be “minted again”.

Minting will stop entirely. Farming rewards will continue to be distributed on Stellar until further notice.

The way revenues will be distributed is described in the post.

To an extent, yes, but tech moves fast and old gear quickly becomes far less efficient. Paying older and newer hardware at different rates makes sense purely from the perspective that they contain different amounts of capacity. If a newer CPU can do twice as much work per core per unit of time, then it feels natural to me for it to be rewarded as a greater unit of capacity.

I’m not crazy about “pay to play”. I think if that were required when I discovered the project I might not have started farming. The form of this that does make sense to me is having the first one or more periods of rewards feed into the collateral with some requirements before it can be unstaked later if the farmer wants to take the node offline. I also prefer to avoid adding complexity to the system, and this becomes fairly complex especially with slashing events, but we can discuss this further for a potential future GEP.

50% of whatever is spend on deployments on the node. So the node operator starts earning from the first deployment they host, no matter how small.

I think this would become a function of the cooperative/farming pool and additional entities that don’t fall under the TF umbrella can fill that role eventually.

A big part of the idea here is that we already have lots of hardware from this generation sitting idle on the network. If that were to one day be filled, we could reconsider, but until then using the newly minted tokens as a way to provide incentive for more modern hardware to join the network seems sane to me.

Another part of the idea that’s not included since we’re not pursuing this now is to allow the older hardware to join and earn only the 50% from utilization. Thus if there’s a market for using this hardware (potentially at a discount), farmers can earn but we avoid inflating the minting with more old gear.

KYC might not be popular, but it provides a clear and very simple solution to this issue. I hope though that the positive aspect of incentives is enough to altogether eliminate this behavior.

That’s a wrap

I did my best here to respond to as many of the concerns as possible, but I did not cover every single comment of course. Some items seem less urgent and worthy of follow up discussions in their own threads. Feel free to tag me if you’re still looking for an answer on something here.

3 Likes