Incentive for farmers to attract workloads

Hi everyone.

There have been good improvements to attract users to the Grid like a default discount on deployments, and extra discounts if you have a certain amount of tokens. Which is very positive since an attractive price can bring lots of utilization. Also the boosters are good to bring attractive nodes online for dedicated renting.

There is still a pressing issue I believe regarding the tokenomics for rewarding farmers to host workloads. Providing grid resources is one, no Grid to deploy on otherwise. Then next would be running workloads on them to actually utilize this already big network.
Currently there is little incentive for a farmer to attract any kind of workload to his/her node(s). Only if you can provide some public IP’s (most can’t) or get lucky to have a workload that uses a lot of bandwidth. The extra you can get does not seem to be enough to try to get your nodes filled with workloads.
If you don’t have public IP’s or a workload that uses a lot of bandwidth, getting for example a miner workload could decrease your profit since your node would start to use more electricity.

Of course we can’t just keep on increasing rewards for farmers every time we want to resolve something. Tokenomics are very complex to design, also very sensitive to personal opinion. But rewards can come in many different flavors forms and even combinations of things.

The following are not suggestions, just ideas as to how we could resolve the issue. To get you guys going with ideas! :wink:

  • A farmer could get some more rewards over time, if they can hold workloads for a minimum amount of time. For example first month they get 1% extra for each workload they had for min of 3 weeks. Next month 2% if the same workload is still there for a total of 2 months, … with a max of 5%.
  • A farmer could build some reputation count based on workload age that gives him bigger advantages when using the gird.
  • Soon there will be the introduction of Solution Providers, which is awesome! A farmer and a solution provider could sign some % agreement in a smart contract. Then if the farmer received a workload with this solution provider ID in it, the farmer receives the agreed % from the solution provider. For example a workload costs 10TFT/h, the solution provider receives 4TFT/h and the farmer 1TFT/h. This way the solution provider can provide known reliable nodes from a known farmer for the workloads of his users.
  • We could introduce some node benchmark, which is used to rewards an extra specific amount based on the performance of the node vs workload age

Do you think something like this is lacking? What would work the best for you? Maybe we create a whole lot of other problems trying to implement something like this?

The idea is to not just hunt for profits as a farmer (no offence to anyone here) but provide valuable hardware that user want to use, and get rewarded fairly for your effort.
Now, the hardest problem with this suggestion I think is the current nodes that are online on the Grid. A lot of them have been build to generate the most amount of tokens (following conversations on the farmers chat :wink: ). Meaning an old cpu with lots of cores would create more tokens then a brand new one with less cores (simply put). While any user would prefer the newer cpu, especially at the same price.
It made more sense in the past to build a big machine, regardless of the age of the hardware. So if we want to reward farmers with something extra for workloads, we have to be careful to not create a disadvantage towards the already running nodes. So early adopters do not feel left out.

Difficult question, for sure, but I think very necessary to build a reliable grid with a working ecosystem for the benefit of all participants.

p.s.: Not a farmer myself

5 Likes

That’s a novel idea, I like that one.

Doesn’t the original proposal to lock up the rewards unless you get 30% utilization for 3 months kinda solve this issue? However, I do fear that if this project catches on heavy, that would get voted down in a DOA fast.

I’m one of the people who has helped create that environment of slightly older servers. I’m personally ok with being left behind in some regard if it means the grid is more appealing (as long as the plug isn’t pulled on me, and at some point it honestly should be when bandwidth monitoring comes into play).

Don’t worry Nelson, if you run out of bandwidth I have lots of room!

As I understand it, your rewards are unlocked at 30% utilization, your not rewarded extra for the utilization which is what this issue is about. You get the same amount of rewards, only more early if you have the utilization.

I’m not in favor of creating any kind of disadvantage of being an early adopter, you guys made it possible for the Grid to start in the first place.
Also think that older hardware has it’s place, and if it could be cheaper to rent it can even be more attractive for a lot of use cases (all sorts of testing, light unimportant workloads, an old cpu works fine for storage, …)

Yep, it runs my websites just fine. I don’t need much for some wordpress sites.

It could be hard for smal farmers to sign a contract with a solution provider. For big farmers this could be something. But the dao could also decide to arange this for every farmer. Now 50% of the utilization tokens is going to the solution provider, it may could be splitted in 40% to solution provider and 10% to the farmer. In this case every farmer provits from utilization

2 Likes

Wouldn’t it make a lot of sense for larger (or small, but may not be worth all the effort) farmers to become their own solution providers? We’re planning to build a farm that is powered on 100% renewable energy from our own production and I have already been speaking with some potential customers that would be interested in booking our green capacity. If we market our capacity ourselves, I think benefiting from additional utilization rewards can be a great incentive (Thanks to @Dany for pointing this out to me).

3 Likes

I think you could have the 2 roles at the same time: solution provider and farmer. In practical terms you (as a solution provider) could establish an agreement with yourself (as a farmer). This solution should be accepted as good and I am sure it would create new possibilities for those who want to start a provider business. If in the future they need more capacity they could invest on their own farms to scale or go with an hybrid model.

3 Likes

Good idea indeed. True, most farmers will not spend the time and effort to look for a solution provider and try to get a deal with them (% wise).
But if we would do it by default, this could have a lot of impact on token distribution. Which would be good and possibly bad, but would need to be thought true very well. There would be less, by default, for a solution provider to earn for example. Or what would be a good % for the farmer to create enough incentive to attract workloads?

That is currently perfectly possible I believe. If your approval for solution provider is approved, regardless if your a farmer.
But there is a difference between a farmer and a solution provider.

  • Farmer: providers capacity
  • Solution provider: provides workloads on that capacity

So just being a farmer will not get you approved as a solution provider. You will need to be able to show how you are actively adding workloads to the grid, with a solution you created like a UI to deploy on the grid, a custom created flist, maybe trough education of how to use the grid, … etc

1 Like

Yes that should be perfectly possible. This way you can earn quite some extra on your farms. You would get the monthly minting payout of your nodes, and 50% of each deployment on your nodes.

Hmmmm, I like the sound of that

This conversation has some overlap with our boosters discussion, but with the additional possibility of routing some portion of the solution provider rewards to farmers. I personally like the latter idea and seem to remember discussing it before. I think it would be very cool to see some kind of “farmer’s grid capacity marketing collective” which onboards users and generates extra revenue through the solution provider fee.

While I think that this was already an important imbalance in the rewards model to address, it’s getting perhaps even more important when nodes are able to be fully powered off while idle. The cost benefit ratio is stacked even higher against having workloads on your nodes, if they would otherwise be mostly powered off instead of just idle.

Indeed, this is the originally conceived way for v3 tokenomics to solve this issue. I’d be curious to see how the vote falls in our existing farmer community, since at least many of our more vocal members seem to be hodlers. I’ll leave details of that discussion to this other thread, but just say here that I don’t think it’s the solution to pursue right now.

Boosters provide a simple way to at minimum keep things fair for farmers who pay more for power because their nodes are utilized. Of course this calculation depends heavily on how much a farmer pays for electricity, but we can try some math…

Let’s say we have a rack style server with 64 CU that draws 150w idle and 300w full loaded (based on some example figures I found for Dell R620s–let me know if this doesn’t look right). It earns 2080 TFT per month. With an electricity cost of $.1/kWh or $.3/kWh:

kWh/month Monthly cost ($.1) Monthly cost ($.3)
Idle 108 $10.80 $32.4
Loaded 216 $21.60 $64.8

Meanwhile, the value of TFT farmed every month is $62.4. So our farmer paying $.1/kWh needs to be boosted ~17% to break even, while our farmer paying $.3/kWh needs a ~52% boost.

I only checked after choosing these example numbers, but the world’s average electricity price was $.13/kWh and the highest was $.412/kWh as of June 2022 (the reality is currently changing fast, however, especially in Europe).

Again, that’s comparing loaded to idle. Comparing to nodes that are using negligible electricity simply proving that they still exist by powering up on a daily basis is a bit different. At least one node needs to be powered on at all times to be able to wake up the others. This means that there’s a significant jump in power consumption whenever a new node needs to wake up and start running workloads. I won’t try to full model this case until I have more details on the implementation.

1 Like