Feedback on our TFGrid 3.14

#2

“agree on 1 billion TFT cap (farming will stop)”

Farming will stop or minting will stop?

#3

Thank you, no minting will stop, will go over it
farming ofcourse should not stop

anyone who wants to make changes please do a pull request on https://git.threefold.info/tfgrid/info_tfgrid

or let us know

#4

We are probably going to have a large list of things, largely tokenomics, for everyone to look at today or tomorrow, so keep an eye out for that.

2 Likes
#5

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/

2 Likes
#6

I see there are 2 threads on more or less the same topic. Maybe keep this one for general / KYC / SLA etc and the other one just on farming/token rewards etc.

I have several questions:

  1. What is the reason behind the addition of KYC? Is it because of some regulator that requires it, or is it just preventive?
  2. Will it be optional or mandatory? I think you might lose half of the farmers if you make it mandatory. I mean, i wouldn’t do it if i just had 1 device running earning about 10-20usd a month. It would defnititely mean less people would want to become a farmer.
  3. Is the SLA for bigger farmers optional? When is a farmer considered big enough for this? What would be the benefit for farmers, is it just the increased chance of getting utilization combined with the newly proposed rewards for that? Because they would have to commit to guarantee a certain level of service and get possible punishments if they fail to deliver, where regular farmers would not.
  4. Why the farmers? It would make more sense to me if grid users had to do a KYC. In case of hosting questionable content, it shouldn’t be relevant whose hardware it’s on but who is actually deploying it.
  5. I read this sentence ‘& link to their contract with TF DMCC or TF COOP’. I’m not sure what this means exactly. I would be willing to do a KYC with TF and have some kind of ‘verified’ indicator to me as a farmer, but i would never agree on having my personal details publicly displayed. I wonder whether that’s the case or not
1 Like
#7

Propositions and Ideas for 3.14 Taken from Community Discussions (TG, Forum)

Uptime Score on Dashboard

  • Add an uptime score on the Dashboard so users can see which nodes are the most online.

Farming Entry Price

  • If the TFT market price goes above 8 cents for more than 30 days, we increase the farming entry price. The price would be decided by the DAO through a new GEP vote.

Distribute further the TFT farming rewards distribution

  • Have more than 1 event per month where we distribute the farming rewards.
  • Reason: To avoid a monthly big dump of TFT on the market.
  • Propositions: There seems to be many ways to proceed all with pros and cons. (2) seems the best proposition so far, feedback welcome!
    • (1) Based on note registration: Distribute nodes based on when the nodes were registred on chain, e.g. if you registered on the 5th of the month, you receive tokens on the 5th of the month for this node.
      • not ideal for many reasons, hard to implement, lots of minting operations, and farmers will be tempted to wipe their node and registrer on the first of the month!
    • (2) Earliest registered nodes paid the earliest, in batches: E.g. we have 4 minting distribution per month, and nodes are categorized in the 4 batches based on the moment they registered on chain, nodes registered the earliest (not in the minting cycle, but in absolute time), are in the first batch, etc.
      • Pros: prevent farmers to want to wipe their disk
      • Notes: If possible, we have this automated, say the grid has 900 nodes, we mint to 30 nodes per day for each day of the 30 day minting period, based on node registration status (earliest registration gets minted first). For now we can go with only 4 minting events, done manually.

Revise Grid Deployment Cost Parameters

  • We see that cores are being used in bigger proportion than other parameters (see here)
    • Can we adjust the cost, e.g. lower RAM requirements.
  • See telegram discussion

Extent Discount Concept to Deployment Quantity/Load

  • The idea of getting discounts for having 18mo of deployment cost tokens in your account is one way encouraging that. Expanding on that, how about a discount for the quantity rented. If you have say 1000 deployments you can save 10% or something. That could further attract mass utilization by resellers. Reference

POU: part to TF foundation

Currently TF doesn’t benefit any on the additional fee. 100% goes to the farmer. A certain % could be diverted.

Prevent Farmers to Shut Down Nodes During utilization

  • how do we prevent node owners to just turn of their nodes for whatever reason
  • Proposition: For each deployment there should be a smart contract in place with something like collateral in TFT that will be lost in case you don’t meet a specific uptime.
  • Note: The 50% revenues from utilization might help in that direction as farmers will want to get the revenue from utilization, they would not want to stop their node during utilization

Two-Way Contact Info

  • Farmers should have users info (e.g. email) to be able to send maintenance notifications, etc.
  • Farmers are asked to provide email and telephone for KYC (see GEP side notes).
3 Likes
#8

It speaks of a current team in TFCOOP. TFCOOP already exists? Registered where?
What roles (specific tasks) are they looking for and what is the application method?How is time time involved compensated if people give up their valuable (and maybe paid) time? only the 40% of utilized capacity?

Section about chapters needs more clarification. What exactly are these, who are these people?

Section about directors. Cooperative Directors are renumerated for their contributions.? What does that mean?

Guardian. Section : They will host a validator. Link doesn’t work?

Guardian; I do not think (I/we) are qualified for becoming Guardian, nore am I not sure we can free up the time, certainly not without 100% clear how its compensated. However, the manual made us believe for some time all it took was to run a copy of the dashboard/playground as already tested with Mik and Scott. To run a massive VM like that costs approx 350 usd a month. I was lead to believe that somehow there was a way for an xx% of the TFT spend by visitors to ’ our’ dashboard would be able to flow back to us, justifying;

  1. the 350USD (+electricity)
  2. making advertisements for it to the many visitors of our presentations.
    Only ’ then’ we are motivated to promote and to point people to a place where they can deploy themselves. To my surprise currently there are no options for the TFT being paid for applications/solutions to flow to a party like us, apart from adding a contract ‘on top’ of the current one, becoming more expensive than the TF dashboard, creating unequal competition.
    In short; if the community wants us to use our media ppower to promote and advertise usage, there needs to be an earning model justifying that effort.

I’m not a big farmer but run a gold farm. I’m about to upgrade to a better router and change some doubtful ssd disks. Expecting downtime. But all to improve quality and service. How do I prevent being punished for this in both TFT and penalties (in ranking) for not reaching the uptime that month? Is there a way to announce or ask for a maintenance slot?
Same; how if I want to change all those big HP servers/nodes with newer versions in the future?

I’m already to the section of mycelium now. Are we supposed to comment on the whole document? OK. Well, I think mycellium is hugely exciting! Next to ourphone I personally believe these are the real promoters and money makers. And although itś being ‘tested’ I still don’t know any of the details. Why not dedicate a whole online webinar/presentation to this? Whats is working already? How is the shortest route option working? etc. Status!

Quantum safe storage should be made simple. There’s other projects that claim they store data encrypted across multiple devices. Since we now know data isn’t stored encrypted on a node, it generates a huge security issue that puts of many of our customers. We need a way to make it easy for data storage.

Edit: I forgot something important; the partners/vendors of threefold, like us, make a lot of promotion and can currently only setup a business selling nodes and helping people deploy stuff. THAT should be stimulated. Any measure taken regarding tokonomics, should have a positive answer to the question: How do I convince this 75 year old to purchase a node? Most of that audience is tired of censorship, big tech and the continuing limitations of our freedom and privacy and look for a way out.
So, to tell them they need to register themselves (KYC) and actively search for peope deploying on their nodes in version 3.14 or version 4 whatever, when utilization is rewarded more than having a node available, is going to kill business. No business, no promotions. Think about it :slight_smile:

3 Likes
#9

I like the slashing idea. better yet the deployer gets to keep some of the slash. bounty hunting for bad nodes. Also should slash for finding nodes that can’t accept a deployment or have a public ip when listed that they do etc

2 Likes
#10

Community Brainstorming for 3.14 Grid

Table of Contents

Introduction

This proposition takes inputs from different members of the TF Community. It’s a brainstorming exercise in a way. It’s not a TF official position, just a thought experiment.

Without thinking about technical difficulties, I try to envision an overall resilient TF ecosystem that answers the demands and needs of the community.

Proposition Overview

In brief, the TF overview would be as follows:

  1. A maximum supply of 1 billion TFT
  2. Evenly distributed farming rewards throughout the minting period
  3. Users discounts for mass deployments
  4. Farming staking vault and farming collateral
  5. Public staking vault (user staking)
  6. DAO revenues (staking vault revenues) distributed to DAO voters
  7. Slashing events for nodes (with bounty programs for users)
  8. Collateral info displayed on dashboard with alerts when nodes’ collateral are being unstaked
  9. Communication channels for TF, the users and the farmers
  10. System for farmers to announce maintenance window without loss of reputation or the like
  11. Increase in the farming difficulty level for new nodes
  12. 50% utilization revenues to farmers
  13. Node uptime score and hardware information on Dashboard
  14. Adjust grid deployment costs to fit with resources
  15. Part of node additional fees goes to the TF Foundation for grant, R&D, etc.
  16. Ensure a proper utilization/capacity ratio (perhaps per region/country? TBD)
  17. Farmers should be able to use their tokens at all times for deployments, without having to wait any grace periods.
  18. Develop a system for someone to make revenues out of developing/coding/promoting on the grid. This can be done in many ways and should be discussed.
  19. Adjust 30-min wakeup rule: slashing until day of violation

Proposition Details

Here are the details of this proposition:

  1. 1 billion TFT maximum supply
  2. Farming rewards (POC) distribution update:
    1. Earliest registered nodes paid the earliest, in batches: E.g. we have 4 minting distribution per month, and nodes are categorized in the 4 batches based on the moment they registered on chain, nodes registered the earliest (not in the minting cycle, but in absolute time), are in the first batch, etc. Can be done manually first, and automated in mid/long-term.
  3. Users discounts on mass deployment
    1. If you have say 1000 deployments you can have a 10% discount. Real numbers TBD. This could further attract mass utilization by resellers.
  4. Farming TFT Staking Vault & Farming Collateral
    1. The equivalent of X months (TBD, propositions so far: between 2 and 6 months) of farming per node is kept as collateral in a farmed TFT staking vault.
    2. Any TFT more than X-month worth of farming per node is available to unstake given a 5 days cooldown period
    3. TFT in farmed TFT staking vault with the min X-months of farming collateral are eligible to vote for the DAO
    4. TFT farmed in TFT staking vault have 1.2 DAO voting power per TFT
    5. A farmer can unstake all TFT (with the 2-month collateral) given a cooldown period of 10 days.
      1. Once they removed all collateral
        1. They do not farm any more POC rewards. They can still farm POU rewards.
        2. They cannot vote on the DAO, i.e. TFT is removed from the farming TFT staking vault.
    6. If a farmer unstake TFT in a farmed TFT staking vault, the only way to stake it is to put the TFT in a public TFT vault (see below)
      1. This means that farmed TFT staking vault contains TFT that has been minted and then used for TF DAO process only!
  5. Public TFT Staking Vault
    1. Anyone can stake TFT in a public TFT staking vault
      1. TFT staked in this vault for more than 20 days before a new GEP can vote for this GEP
      2. TFT staked in a public vault have 1.0 DAO voting power per TFT.
      3. Unstaking has a 10 days cooldown period.
  6. DAO Revenues: Farming + Public Staking Vault Revenues
    1. A % of POU revenues go to the vault wallet (e.g. 10%)
    2. Vault revenues are distributed to the DAO voters after each complete quarter (e.g. 4 times per year)
  7. Slashing
    1. The farming collateral can be slashed if a workload is destroyed during utilization.
      1. This has an added bonus of ensuring new nodes are serious about providing capacity and creating another utility for token.
    2. Bounty Hunting program for Slashing Events (bad nodes):
      1. There is a slash event and a bounty reward to the user when a user finds a node that
        1. can’t accept a deployment
        2. doesn’t have a public ip when listed that they do
        3. destroys the deployment during utilization
        4. Etc. (Todo: build list of slashable events)
  8. The Dashboard should show which nodes have their min collateral quantity. And alerts should be sent to users when the nodes they are using get the collateral unstaked (e.g. for slashing events or simply the farmers removing the collateral amount)
  9. Communication Channel: Farmers and Users Contact Info
    1. There must be efficient communication channels between farmers and users for maintenance and service reasons.
      1. Farmers should have users info (e.g. email) to be able to send maintenance notifications, etc.
      2. Users/TFGrid should be able to contact farmers (email and telephone)
  10. System for farmers to announce maintenance window without loss of reputation or the like
    1. A mechanism where farmers could go through an announcement procedure, that downtime is expected on a node/farm due to maintenance or upgrade, without loosing any reputation or rewards
  11. Farming difficulty and Proof-of-capacity: farmers get POC rewards based on 0.08 farming registration price (farming difficulty level)
    1. We increase the farming difficulty for newly registered nodes when demanded by the DAO
    2. As a first step, we increase difficulty level to 0.10 USD (25% increase in farming difficulty)
    3. As TFT utilization grows, its price should increase and the DAO should naturally vote to increase the farming difficulty level.
  12. Proof-of-utilization: farmers get 50% of POU rewards
  13. Node uptime score and hardware information on Dashboard
    1. Add an uptime score on the Dashboard so users can see which nodes are the most online
      1. High-availability nodes would come first in the search.
    2. Add the maximum info on the node hardware for users to choose as they see fit
  14. Revised grid deployment costs parameters in accordance with the market and best practice for TF and high access for users
  15. Part of Farming additional fees to TF Foundation
    1. Currently, 100% goes to the farmer. A certain % (e.g. 10%) could be diverted to the TF Foundation for R&D, grant programs, etc.
  16. Ensure a proper utilization/capacity ratio (perhaps per region/country? TBD)
    1. Regulate the creation of new nodes when there is a lot of empty capacity
    2. This could be per country or region to avoid a scenario where overall capacity outgrows utilization, but in one country capacity is needed (e.g. there’s a lot of demand locally)
    3. This needs to be further discussed
    4. Example: New nodes under 33% of utilization per country can only farm POU, but not POC.
  17. Farmers should be able to use their tokens at all times for deployments, without having to wait any grace periods.
    1. E.g. a farmer purchase an IKON XL that generates approx. 650 TFT, from which they could use 400 TFT to setup a nice cloud environmont. This should always remain the option. No waiting, no locking, no grace period.
  18. Develop a system for someone to make TFT revenues out of developing/coding/promoting on the grid (providing solutions, dashboard, etc.)
    1. E.g. find a way to have something along the lines of the previous solution provider system work.
    2. E.g. the person hosting a grid stack could get a % of that dashboard instance’s revenues to their wallet
    3. Note: the current option to add an additional contract on top of the current one means unequal competition. So not ideal.
  19. Adjust 30-min wakeup rule slashing: adjust slashing up until the day of violation instead of for the whole minting period

Note: This is based on community feedback over many discussions. Ideally, we can integrate those points here with the ongoing 3.14 plan as shared by Kristof at the top of this page. Link to 3.14 ebook

2 Likes
#11

This is much more complete than the summary I was working on for my own records.

This staking/lockup plan is a more well thought out alternative to the plain locking mechanism that was originally proposed, and I was prepared to reignite the fight for. Previously the lockup was for 24 months or at 30% utilization. This new plan better accounts for how to take a node offline and provides a more fleshed out plan for how the staking would work. I would add that when a node is unstaked, any workloads should be alerted. People with deployments may seek out nodes with TFT staked. Allowing unstaked nodes to collect POU TFT would hopefully keep those nodes online. Staked nodes would still be considered more attractive as it would be considered safer. Most importantly I don’t think 2 months is quite long enough. I’m leaning towards 6 months.

I have also become increasingly concerned about the capacity outgrowing utilization. We can have enormous amount of utilization, but if the capacity grows even more, the tokenomics become completely broken. Even now we need much more capacity than the tokenomics really allow for. Something needs to be done to regulate the ctreation of new nodes when there is a lot of empty capacity. This exact scenario kills projects every day of the week. I don’t know what the solution is, but it could be a fee for a new node id (didn’t work for arbius, but then again there emissions were too high)), no new nodes unless capacity outstrips utilization for 25%, or some undetermined idea.

2 Likes
#12

OK thanks Nelson for this feedback. Highly appreciated.

I added points 8 and 15 and added a note that the collateral number of months should be discussed. 6 months seems fair to me. Let’s see what others think.

@FLnelson proposition for now: new nodes in a country with less than 33% utilization can only make POU rewards not POC. Let me know what you think.

#13

Roberts gonna find and kill me, but yeah, I like that.

#14

No, i won’t kill anyone. But the mixed messages are killing. Just 3 weeks ago i was asked by Kristoff to be ready for huge demand in nodes, because capacity would be needed quickly due to new developments. Now, 3 weeks later we kill it with the suggestions above.

Then we claim we need utilisation. Again, i stick out my neck and invest time and money to setup a business to help farmers deploy flists on their newly purchased nodes. We kill this business too, because TF developed flists themselves and no tokens are flowing to the marketeers. On top of that i see that new nodes are discouraged when not utilised. That doesn’t add up. At the same time we are going to reward farmers 50% with deployments on their nodes.
So, the ‘valuable’ vendors/partners of TF are now asked to stop selling nodes, but when they do, utilise them with a flist they won’t get any return for, OR, tell customers to purchase a node, but offer them a flist/deployment on OUR nodes so at least we get 50% rewards?

I hope you all see the flaws in the above. At least have the decency to say you don’t give a rats ass about your biggest promoters. (Well, usually they ‘say’ they do, but just pretend cause they don’t act accordingly) I feel I’m waisting time trying to setup a business on a foundation that continuously changes course.

I keep on hearing from the TF crew they’re waiting for people to step up and actively pick up the ideas to develop then. But current events show you better not pick up that glove, cause you won’t know what tomorrow looks like.

Start making suggestions that benefit your promoters and partners to move forward, and give them the tools (and rewards) for achieving what needs to be achieved.

I would hate to think what would happen to this project if the biggest supporters en mass turn against it. Let’s not go there.

Now, as a response to some of the above listed points; i may have misread but I’ll say it again, from the very first second TFT is rewarded to a farmer, he should be able to use it for deployments. Period.
And; there needs to be a mechanism where farmers could go through an announcement procedure, that downtime is expected on a node/farm due to maintenance or upgrade, without loosing any reputation or rewards.

#15

Hey Robert! Just a quick reminder to keep the language smooth here. I had to review because of language.

"from the very first second TFT is rewarded to a farmer, he should be able to use it for deployments. "

What do you mean here? Once it’s clear on my end I can add it in the 3.14 suggestion list.

“there needs to be a mechanism where farmers could go through an announcement procedure, that downtime is expected on a node/farm due to maintenance or upgrade, without loosing any reputation or rewards.”

Good point. Adding this in the list of 3.14 suggestions.

So, please tell us exactly what TF should do in your mind so it would be fair for farmers and the vision you had in mind. It’s the perfect time to share your feedback. We genuinely want the best outcome.

Nothing is set in stone here. It will all have to be approved with GEPs.

#16

Hi Mik,

Thank you.

  1. I keep on seeing methods where we talk about locking or staking tokens, all in an attempt to discourage people selling tokens right away after minting. If I misunderstood, please let me know.
    But I have said from the beginning, we can lock and stake all we want, but farmers should be able to use their tokens at all times for deploymenets, without having to wait any grace periods. Example; we actively advertise that people can purchase an IKON XL that generates approx. 650 TFT, from which they could use 400 TFT to setup a nice cloud environmont. This should always remain the option. No waiting, no locking, no grace period.

  2. If I’m not mistaken we all agree that utilization is the most important thing we’re after. In my view that means we should give the community the proper tools to make it easy and attractive to do so. 90% of my audience has no clue how to deploy anythign on the grid. Even the word ‘tokens’ scares them. So, we decided to help ourselves, our customers and the TF project by developing a way we can sell nodes, and help those same customers setup their own cloud envirmonent on it. We are even worig on a country wide network of going to people’s home and deploy it for them, on their nodes, with their TFT.

Obviously by doing so we would need an income. This income should come from the one time sale of a node, the one time instalaliton costs and a repititive small monthly reward in TFT from whatever instalaltionw e perform at their homes. This is why the solution provider idea was so good.

So, now I’m looking for a way that we can use the Nextcloud flists from TF (we do not have the knowledge to develop flists ourselves…and were slightly dissappointed TF decided to develop Nextcloud themselves while this was our idea. TF was still on the hand of Owncloud that time…) and have some of the TFT flow back to us as installers/promoters. Which lnk can I have peopel click on during our presentations or on our website for them to install somehting on the grid, while we get a small %?

But in stead by design xx% flows back to treasury. Scott told me the only option is to add an additional contract on top of the current one, which would mean unequal competition. Soon folks would fine out the TF playground is cheaper, which is less than fair.

So; if TF is serious about utilization, give us the tools to help people install and inform how to do this, with a proper reward. ASAP. :slight_smile:

In general and little besides the point of this thread I’m noticing a shift in a large portion of this community where people that once claimed to be in this project because of was good for the people and planet are not shifting towards how much capital gain they can get. Everyone should make a healthy living…I just hope it doesn’t become the goal, and remains a result of our efforts.

#17

Just a quick adition;

As a solution I would propose the following;

  • As you (Mik) already know we can easily run a massive VM with Dashboard copy, we tested it. This would further decentralise the grid and stablise it. (guardian?) Don’t need a profit because of this, but somehow rewards should match the cost of running it;
  • The Applications in that dashboard should have xx% flow to the dashboard owner.

This way we promote utilisation, can point customers to our website (dashboard) en have a little extra income. win win?

#18

OK Good. I added two points to the brainstorm based on what you wrote. We can then discuss this with the community and see how to implement those ideas.

Some notes:

Flist

Guardians

Thanks for the feedback.

#19

I did think it would help you in your project to build a nextcloud app on the dashboard

It did, and I’m very grateful for working and testing together! :pray: But that was at a time where it was still planned that people working in such App would all get a share in benefits. (coders, promoters etc.) Now it only flows to the treasury which takes out any incentive to actually use it.

Guardians will have some revenues, check the docs (WIP)

Thanks, I was aware of the documentation.

I see the previous “guardians” section has been removed from the manual, at the time it stated all was needed was to run a copy of the dashboard. But the current requirements are too steep for me, so I left it.

#20

Guardians: yes I understand. We will make sure the guides are as clear as possible but indeed becoming an official guardian will require lots of technical skills. The manual indeed had used the term guardians too broadly before the whole guardian program was being worked on. Maybe the cooperative director role will be more in your skill set? We will introduce this soon.

Benefits for coders + promoters: will make sure that it is discussed for 3.14. I adjusted the brainstorm above to include coders/promoters along with developers.

#21

suggest we make small meeting where we can go over these points and see if the stories for 3.15 are in which take the remarks into consideration, we might have some engineering time left in 3.14 for items which are important to resolve now.

1 Like