Feedback on farming logic as suggested for TFGrid 3.14

#1

https://threefold.info/tfgrid3/tfgrid3/farming_update_3_14.html

Please realize not all stakeholders are on forums or on chat, we will try to represent the interests of those stakeholders as well.

FYI: Today there are some meetings planned between TFTech and ThreeFold DMCC to go over suggested changes and see what other information we need to integrate from the forum, the content above might change, please give us any relevant input the sooner the better.

#2

Carrying over from the Farmer chat as requested for the broader stakeholder collective:

CEX is likely too expensive assuming TF doesn’t have much of a budget. Plus there is no guarantee that pays off. As an example, aleph is a similar project recently listed on Coinbase and their price action hasn’t shown much movement.

A bridge to a more popular and inexpensive chain(Solana) would open up the floodgate of traffic and trading. However, that will take time and resources to code.

We need liquidity first and foremost. We in the community are working on an idea to open up an easier way to trade TFT with a new pool given the lack of action by TF leadership.

Ultimately we will need a marketing initiative to take hold or this idea will be pointless. I call on TF leadership to take action with marketing or die after this cycle. There’s no better way to put it. This is not meant to put anyone down or cause conflict. It’s time to light a fire under some asses and for leadership to bring in a day to day ops manager that understands how, and is given the decisive freedom, to push this thing to the broader market. Respectfully.

image
image444×1156 44.8 KB

1 Like
#3

I have observed that the recent modifications primarily appear to be because of the recent movement in token value. In my opinion, it would be more beneficial to implement changes following significant breakthroughs in the project. Altering aspects for superficial reasons may not align with the project’s long-term objectives. It would be prudent to reconsider the current token model once the Threefold team secures a major partnership or witnesses substantial utilisation or if they undertake significant marketing efforts. Rather than solely focusing on boosting token value, the emphasis should be on marketing strategies and increasing utilization. We possess a remarkable product awaiting widespread adoption and recognition.

#4

I think this thread was meant to be on the details of the adjustments on the farming model.
I have a couple of points i want to make on this.

-for new nodes: we do no register nodes which are not DDR4…
This feels like a plot twist, given that some time ago threefold indicated they value the reusing of older hardware if it’s still good, and this statement is probably the result of dissatisfaction among some members in the community, because DDR3 nodes are cheaper, of less quality and earn the same amount of tokens. Things to keep in mind; newer hardware might not be accessible or affordable everywhere in the world, and for many purposes ddr3 would be totally fine. I have several ddr3 based servers with over 40% utilization.
I would like to propose the following:

  1. Give nodes using DDR3 a label ‘older hardware’ in the node finder section of the dashboard
  2. Use a percentage to determine the farming rewards of these nodes compared to the existing model
    80% for example would mean that older hardware earns 80% of the tokens they would currently get.
  3. Have a poll so all stakeholders can vote on this percentage. Give enough options, from 0% (implying a complete ban) to 90%, in increments of 10%. This should give a good impression of what everyone considers fair

Persnally I think there are 3 main categories that represent a certain quality as well as associated cost.

  1. All DDR3
  2. DDR4 of generations Xeon v3,v4,bronze,silver
  3. DDR4 of Xeon gold and above, all Ryzen & Epyc and equivalent
    Bonus: for each category, distinguish whether the ssd is NVME or not
    But maybe this is something for later, and we should start with the poll just on DDR3

-give 50% on utilization to farmers
I do agree with rewarding utilization, because farmers should actually benefit from have their nodes utilized rather than just paying extra electricity costs. I did not do calculations on the amounts/percentages so I won’t comment on that. What I do think, is that any percentage of utilization rewards given to the farmers will not outweigh the electricity costs for a full month, in case of small workloads. 50% of a small utilization fee is still too small for nodes that could have been on standby with farmerbot. I have personally deployed many contracts on the grid, and witnessed a case where someone deleted his node with my deployment on it, wiped it, and had it register again with a new node number, just so he could use the farmerbot. My adjusted proposition on this topic:

  1. Reward with a fixed amount, as well as a variable amount
    The fixed amount should be on the binary online/standby. As unused nodes can use the farmerbot, the value of this fixed amount should ideally represent the equivalent of costs of running a device of 100W for a full month. Ideally this should be tied to USD rather than TFT, but that might be harder to implement. Another way to do it is to have this fixed reward proportional to current payouts. This is probably less accurate to fulfill its intended goal but way easier to implement.
  2. 2 ways to do it compared to current situation, subtract the fixed amount from current rewards (serving as a fee for using farmerbot) or add it to current rewards (serving as a reward for being immediately available)
  3. Utilization rewards can be implemented as proposed, maybe toned down in percentage when the fixed reward is also added.

I’d like to hear your thoughts on these points

1 Like
#5

Repost since everyone seems to be using this thread.

Issue #1: Monthly supply increase creating token sell off.
Solution 1a: Greatly increase liquidity
OR
Solution 1b: stagger payouts throughout the month.

Issue #2: Network reliability and quality
Notes: There is only a shortage of high quality capacity, not of capacity in general. There are no incentives for providing high quality capacity or to stay online. Monthly base TFT pay for idle nodes exceeds possible income to TF from rented capacity, making current system highly flawed. There are solutions that solve these multiple issues together.
Solution 2a aka the Carrot: Reduce the base amount of TFT issued per month for idle nodes. Have the utilization TFT bonus + base pay exceed what was previously paid to idle nodes. Farmers will build best nodes possible to seek utilization.
AND
Solution 2B aka the Stick: Have a amount of TFT staked per node that is slashed if a workload is purposely destroyed. This has an added bonus of ensuring new nodes are serious about providing capacity and creating another utility for token. Unrestricted capacity growth can destroy network if it outpaces utilization demand. (I understand this may be too much to ask for next release)

Bonus:
Implement reliability score for nodes. See this for inspiration. https://docs.aleph.im/nodes/reliability/

#6

I don’t know if that s possible to implement on V3.14, maybe more appropriate as a target for v4.
I don’t support banning DDR3 machines, but there must be a bench score for for providing rewards. High end DDR3 cores are not so far off, of many DDR4 cores and deployers could prefer DDR3 core if the difference reflect to cost of deploying.
As for cost of farming vs rewards of utilisation there is a big problem with high core nodes. As it is, rewards for a single or double core deployments on these servers are not viable to cover the cost of running them so there must be a starting threshold on these nodes to allow deploying for example of 10% of the core or storage capacity of the node or banning all these machines all together no matter if it is DDR3/4/5 because otherwise there is always the risk of farmer decommissioning the node.
Also together with these, should be a benching score for rewards for bandwidth, we don’t need nodes running on very low bandwidth and farmers should be rewarded for having nodes on fast connections and also should be a limit of how many nodes are sharing this connection, maybe allow a different type of nodes only for sharing them. Eg a low core node easier to be utilised (counting that 10%-20% cap) a high core node for big deployments and a low core node with GFX for node renting for GFX utilisation, that for a specific bandwidth, and not allow for example 4,5 or infinite high core nodes on a 100-200-1000 Mbps connection, THERE MUST BE A LIMIT.
Caring only about specific type of nodes without adding all these parameters on the plan will not solve any problem but might create more.
Also, I should add, that any changes happening should be announced early enough for current farmers to plan accordingly for at least 4-6 months before the change happens.