This has been a frustration for me aswell, say I wanted to get the “staking” discount, everytime the coin price falls I need more and more tft to do that,
Perhaps a middle ground would be to allow someone to “prepay” or their deployment,
If I had the ability to reserve a vm for (x days, weeks, month) and actually pay up front, that could alleviate the situation caused by a drop in coin price without making major changes to the structure and economics
That is well said right there.
Please everyone, keep on giving your thoughts on this.
It’s good to have the community feedback on such an important additional feature.
Perhaps instead of reserving a vm for x months, you add an amount cores, ram, ssd, hdd or a dedicated node to your twin for a set amount of time,
You are able to pay for those resources at deployment and receive the same staking discount you would by holding tokens.
Basically once you create your long term resource reservations any amount of resources deployed below the reserved amount doesn’t bill, if you want to deploy more those resources bill normally, or you can increase your long term reservation size.
i asked thousand time why you don’t put collateral to run a node but i didn’t get any answers 
I think those are two different things.
Requiring collateral to run a 3node is related to farmers.
While locking TFT value during deployment is related to users.
yes , I’m talking to farmers that dump the price every month
OK I understand. That is indeed a different discussion. But I understand your concern.
I think collaterals haven’t been chosen for different reasons and that they do not fit the philosophy of Threefold.
The community is well aware of the price of the Token and many projects are in the making to solve or partly solve this situation.
Kristof wrote some documents to clarify the ongoing situation. You can have a look here.
You are welcome to share your thoughts on this in the Telegram channel.
Thanks for your feedback @rblode
Hey Mik, thanks for writing up this proposal. Since we also spoke about this I’ve been thinking about how to proceed. A locking or prepayment type solution has some disadvantage:
Those aren’t show stoppers in my mind, but a change like this should be carefully considered and it will take some time to implement once an agreement is reached. There is a much simpler solution that can be effected much more quickly, which is to set the TFT price on chain to a static value rather than take it from market data.
It would be something like how the entry price for farmers is currently set. We could do something like $.04 or even $.08 to start. This also becomes an effective discount for anyone buying off the market to create deployments. It doesn’t totally solve the problem, because there could be spikes above the set price in the future and anyone buying at the spiked price would still miss out on the full value they paid. However, it could be a way to buy some time to figure out the best long term plan.
Thanks Scott for sharing this.
I think you have a lot of great points.
That’s exactly what we need: to discuss this proposition and see what would work best for Threefold.
Let’s see what others think about this!
Exploring the proposition you shared @scott
This means that users can be confronted to changing resource costs on the TF Grid.
Say TFT is at .1 on the TF playground, but at .11 on market, then next month it’s at 0.9 market.
This means that from one month to another, if the user buys at market before deploying, the deployment cost will vary, for the same resources.
This too creates difficulties in planning the finance and operational costs of a business using the grid.
I think to get the “fiat” businesses out there, we need to have something constant in terms of USD price for a given resource.
For example, let’s say that 2vcores, 8gb of ram and 15 gb of ssd is 15$ per month, then the person can deploy their workloads, do their businesses, and then at each beginning of the month, they can decide to buy TFT market for a total of 15$, and fill the deployment wallet. Each month, it will be 15$ for the given deployment.
Another way to say this is, we could propose period of deployment renting.
So you say: I want to deploy XYZ resource and I want to pay upfront for a given period (say one month), and that after each new period, TF Grid takes the TFT required based on the market price for the next period.
So the user can buy TFT just before each period and they know they pay the same USD price.
They can also just buy lots of TFT and have it in their wallet. Each beginning of the period, TF Chain takes the TFT needed for the deployment during the new period.
Hello. I’ve read this post before, and today I regret I was too lazy to comment on it when I first saw it. Yes, @Mik. I agree with the problem you identify. Any user who takes this project as something more that a hobby, sooner or later will come to the problem you identify.
Above are my suggestions on this matter. I will take the example of a VM here for simplicity:
1.You should have the ability to pre-pay your VM’s for:
a) 0-14 days 0% discount.
b) Period 15-30 days - 5 % discount.
c) 1 month - 10% discount
d) a maximum of 3 months - 25% discount.
This proposal has 3 clear objectives: a) Stabilize cost for the buyer(main topic). b) Promote TFT buying. c) Promote the grid with a more attractive pricing without changing the baseline pricing for now.
And yes, in my opinion, until there is a clear solution for Tiering (which depends in a lot of other stuff, like benchmarking, etc) the pricing of the grid will still suffer of “injustice built in” for farmers and users. if you are still wondering - yes - I consider the grid expensive compared to other providers. Take the example of a minimum VM with one Ipv4 address and compare it to other providers and you would get the same/or better machine for less that the cost of the IPv4 address without bandwidth extra costs!!!)
Even thought this will not fix this problem (only CPU, internet speed and Uptime SLA - Tiers will do!!) this could also be considered a band aid for a more competitive grid and bring up utilization and TFT buying.
Everything on the grid seems deeply interconnected, and if you do not implement something like benchmarking, you could never implement CPU Tiers or you can never aspire to have uptime SLA if you don’t have a more robust mechanism than certification. You have to have a well tested benchmarking system and probably collateral to push farmers to the SLA responsability.
Anyway, the main subject of this post is prepaying and stabilizing costs per users. I would be happy if this could be a reality, but even happier (as a user) if this could help to bring down pricing of the grid and bring more users to it. I don’t have the problem to assume here that i deploy on some nodes and not on others… I think most people who take utilization seriously have come already, or will come to the same conclusion, as I did sooner or later…
Utilization is the only organic to make Threefold thrive… pricing policies have a direct impact in the utilization of the grid. and should deserve more of our attention… but maybe this discussion deserve it’s own post…
ps the only things I am not sure to how solve is what happens, if someone prepays a machine and for some reason the machine goes down for a period of time or permanently. This could lead to some problems implementing a way to refund user… not sure how to solve it in a simple way.
Thanks for this great reply @nooba
For the last part:
“ps the only things I am not sure to how solve is what happens, if someone prepays a machine and for some reason the machine goes down for a period of time or permanently. This could lead to some problems implementing a way to refund user… not sure how to solve it in a simple way.”
I would propose this: users then get a “coupon” where they can redeploy on another 3node with the same “deal” they had on the first 3node.
There could be a maximum period of time to use the coupon. Say, after a few days, it’s not longer valid.
Hello Everyone.
The main subject of this topic is more important now that never after the major climb of 80% in about one day of TFT token price (probably not exact number)…
I think everyone that have some funds in they deployments would be very happy… but let’s see things in the opposite perspective. What if the price dumps in the same figures? Would that user be happy? Probably that user, would never come back, because he took his lesson that when you are deploying on TF grid you are also taking the risk of crypto volatility. In my opinion, you should let users/clients choose if they want to take that path or not.
While farmers have no choice about token price swings, that is in the nature of they investment on the grid when they chose to begin farming, users, on the other hand, should be able to look at the project and choose if they want to use the grid - making their deployments ( after all, isn’t that the reason why the price is dollar stable?) , or “invest” on it buying tokens. The actual mechanism of discounts on dedicated nodes, promotes, the user as an investor, but why should it be that way? Why shouldn’t you reward the loyalty to the grid, promoting discount levels on longer contracts?
Wouldn’t that benefit the usage that and sustained growth of the grid?
I find myself in the situation that I have 7 VPS’s on other providers that are locked to contract - 2 of them I payed upfront 12months at racknerd, and 5 of them I have a contract that is billed monthly. This is just an example that this is a common strategy on providers and TF should consider.
I really hope that people could get on board to this post and share their opinions.
Hi everyone,
Having a lock on the TFT price at deployment start should not be that hard to implement, although we should indeed first think about what impact it has.
Personally I think it’s a good feature since a user will not be bound to fluctuations in the TFT price anymore, but we cannot enforce that a user cannot cancel his deployment at any time. This is because when a node goes down, he cannot cancel the deployment, thus the user will keep paying for a deployment that is not reachable anymore. Since the chain does not know that a node is up or down we cannot have safeguards in place.
I think we should keep it simple and make a choice between:
Feel free to add some thoughts on this 
Hello @dylanv thanks for your reply:
Not sure if I understand your solution well.
" Having an optional locking mechanism that locks the price of TFT at time of deployment."
Do you mean that if this is the chosen solution, there’s no uptime data available on chain and in consequence no possibility to “refund/unlock” the user? If that is correct, how does the system works right now, in case the node goes down for a period? does the user still pays for it, while there is no service available?
Is this data only available later, after the minting period finishes?
I would like to have your reply first before making more questions…
Hi @nooba
We don’t “save” uptime on chain, there is no notion of a node being online or offline. Rather there are client tools that track when nodes send uptime to the chain and can calculate if that node is up or down.
So to answer your question: if a user has a contract running on a node and that node goes down, the contract will not be canceled by the system. It’s up to the user to track the “liveliness” of his contracts (read deployments) and cancel the contract if needed.
The minting currently happens “off chain”, this means we scan the blockchain every month to gather all uptime events for all nodes and calculate accordingly how much each farmer is due.
In Grid V2 we had a concept called “Capacity pools”, where the user specified upfront how much compute / storage seconds he wanted to buy. Then whenever deploying something, the user could link the capacity pool. At any given time it was also possible to “refill” the capacity pool, giving the user the possibility to extend the duration of his contracts.
This concept could be introduced again but it also has some downsides in regards to user experience, since capacity pools were mandatory for deploying anything.
Thanks for your quick reply.
Although, I am not expecting that a normal/tradicional cloud provider, would not charge me for downtime, I am not expecting downtime happens in a substancial way in this kinds of environments. And if they happen, there is a team behind to look and quickly solve this kind of incidents.
Realistically, TF grid with his distributed nature, like we all know, in not managed by profissionals, so in the case of a downtime I would expect that in some (or most) situations this could lead to some prolongued downtime. By your explanation, in this scenarios, the user is beeing charged and still has to track if their deployments are running and manually have to delete the contracts. That seems to me not an ideal…
Are there any plans to change this behavior in the near future? Is this considered by the dev team has something to improve?
Thanks
Due to the nature of the current tokenomics we “punish” farmers for going offline, which is some countermeasure against workloads going offline but not enough.
We don’t really have a plan to change this behaviour in the near future to be honest. I could see a community member implementing a notification system that can notify a user running a workload on a node and that node going down. This might be even the best approach to the issue at hand.
It could even become part of an extension of the bot that @scott wrote
I see it more like users are “punished” if they don’t keep an eye in their deployments… and IMO it shouldn’t be this way… A ready to market product should have this “little big” issues as priorities.
In case of a deployment failure: