TFT Locked Value During Deployment

Hi guys,

I hope you are doing great in this very 2023 year.
Here’s a long post. I didn’t have time to make it shorter, as a famous writer once said.

TFT Locked Value During Deployment

The Proposition

I want to propose a change in the way the value of TFT is handled during deployment.
I will first explain how it is currently happening, and then offer an alternative.

The Current Situation

As of now, the value of TFT on the playground ( is based on the current TFT market price.

Say, a Threefolder user wants to deploy something on a 3node, they will buy at market price then move their TFTs to their playground wallet. On the playground, they deploy their workload by renting a 3node with specified 3node resources.

The value of TFT is based on the current market price, and the cost of the 3node workload is based on the “dollar-normalized” TFT value. This means, in short, that the price of a given 3node resource is always the same in terms of USD. The Threefold documentation says:

TFT pricing pegged to USD (pricing changes in line with TFT/USD rate)

Source: here

For example, if you want to buy XYZ resources on the TF Grid for a given period of time, say 1 month here for the example, and it costs 10 USD, with the TFT price being 0.1$, you will need 100 TFT for the deployment.

0.1 USD/TFT * 100 TFT = 10 USD

If a month later, the TFT price is 0.2 USD/TFT, the user would still pay the same 10 USD worth of TFT, but then they would only need 50 TFT. That is what it means to have “dollar-normalized” TFT for deployment. In short, you always pay the same USD price for a given resource on the Grid. Of course, this takes into account that the user buys market just before deploying.

So far, so good.

Going back to our example, the user has 100 TFT in their TFChain wallet, and they deploy the 3node. They know that it will cost them 100 TFT for the given period, here we said 1 month.

But will this deployment really cost 100 TFT for the month? Yes, if the TFT market price stays the same. But no, if the TFT market price changes.

Indeed, the deployments on the TF Grid is dollar-normalized at the moment of deployment. This means the TFT purchasing power is based on the USD/TFT market price.
But once the deployment is running, the deployment cost continually tracks the USD/TFT market price.

In short, if the TFT price goes to 0.2$ and stays that way for the whole month, the user now has twice the TFT purchasing power. It’s simple, since, in this example, the deployment cost for XYZ during 1 month is 10 USD, the user now needs only 50 TFT:

0.2 USD/TFT * 50 TFT = 10 USD

In this case, the user is happy. But then, what is the TFT price goes down, say by half of its value? We’d get a TFT price of 0.05 USD/TFT.

Then the user would need 200 TFT for the same workload.

0.05 USD/TFT * 200 TFT = 10 USD

So in short, with the current TFT value during deployment, users are basically throwing dice: will I pay the amount calculated at deployment? Only if the TFT market price has an average of the same TFT value when I deployed. But if the TFT price goes up or down, then the quantity of TFT needed to deploy will change.

The Alternative

Now I will share my proposition. And please try and find holes in my thinking, so we can perfect it and have the best alternative possible.

The proposition: we should offer users the possibility to lock the TFT value during deployment.

In short, if my deployment costs 10 USD for the whole month, and that I buy market just before deploying, still with the last example, I would rest assured that I would only need 100 TFT for the whole deployment, nothing less and nothing more.

This has great benefits for businesses. In general, it’s easier on the finance side for a business to know in advance the cost of running projects. With the current situation, the fluctuating value of TFT during deployment leads to hazardous outcomes.

The cost of deploying workloads on the TF Grid is always competitive and attractive for businesses if you buy market just before deploying, since the TFT is dollar-normalized. But this isn’t necessarily true for the whole deployment period, as stated above: if the TFT market price fluctuates, it affects the purchasing power. But I think many businesses wouldn’t enjoy having to pay more for their deployment compared to what they planned when they deployed their workload.

But then, in this case, users could try and rig the system. For example, they deploy and lock their TFT value, but then TFT price goes up. The user could then stop their workload, and re-deploy. Having bought the TFT before the price went up, the user would have more purchasing power. The solution to this is simple: when you want to lock your TFT value during deployment, you also lock your TFT for the whole deployment.

This has many advantages. In short, in those terms and conditions, the TF Grid would offer deals that are as close as possible to real-world cloud services.

Indeed, if you want to buy, say, a domain name for 3 years. You pay upfront for the 3 whole years. If the USD price changes during the 3 years, it doesn’t matter, you already paid for the 3-year service.

TFT Cost Deployment: Locked or Unlocked

With this in mind, users could choose between locking their TFT value for deployment (and then also their TFT would be locked for the whole deployment), or they can decide to have the standard deployment. In the latter case, if the TFT market price changes, this affects their TFT purchasing power.

How it could go:

  • When deploying a workload on the TF Grid, the user:
    • can decide to have a deployment with the standard TFT value during deployment
      • if TFT price changes, it affects the TFT cost deployment
        • TFT cost deployment (cost of TFT per compute and storage units) is pegged to TFT/USD market price, so if TFT goes down, it costs more TFT per hour. But if TFT goes up, it costs less TFT per hour, since TFT is worth more USDs and the deployment is pegged to the USD value.
    • can decide to lock the TFT value during deployment
      • the deployment TFT cost is constant for the whole locked period
      • can decide how long the locked period is
        • e.g. for 1 hour up to 36 months
      • when you lock the TFT value during deployment
        • the TFT per hour cost stays the same no matter the TFT market price variation
        • if you stop the deployment, you don’t get the remaining TFT back
          • just like you can’t decide to get your money back after buying a 3-year domain name
        • if the 3node stops the deployment, the load is redistributed on another 3node
          • this should be discussed in more details
            • would this be a manual or automatic re-deployment?
        • when the period is over, you can make another contract with the TF Grid
          • in this case, the TFT cost will be based on the changed TFT market price

Some of the Possibilities

Someone can decide to lock a deployment for 1 month, and at each month, they would refund the deployment and the price would be based on the new market TFT price.

For a business, it can be very good. You can buy the TFT at market price, then deploy on the TF Grid with a (e.g.) 1 month locked cost deployment. You would then pay the same price every month, in USD terms.
They can still have lots of TFT in their wallet and get a discount.
They can, for example, have enough TFT for the 36 months, 60% discount, and decide to lock the deployment for 1 month.
They can also decide to lock for the whole 36 months.

Scenarios Considering TFT Price Movement

TFT price can be the same, can go up or can go down.

In all three (3) cases, when locked, the user paid the same USD amount of dollar for the whole locked period.

This is good for business, as people can predict costs with precision.

TFT Price Movements: Up, Down or Constant

(1) If TFT prices stays the same, locking the TFT value doesn’t change anything.

(2) If TFT price goes up, without locking the TFT value, it would cost less for the user.

(3) If TFT price goes down, without locking the TFT value, it would cost more for the user.

Only (2) has a negative outcome in terms of TFT value, BUT the price paid for the service is still competitive and predictable as it is pegged to USD.

Price Stability for Users, Better Financial Predictions

Locking the TFT value during deployment gives a stability for the users.

Without locking the TFT value during deployment, the user gambles on the TFT price in the future.
When we lock the TFT value during deployment, the user has a fixed price for their workload for the given locked period. If the TF Grid says it’s 10 USD for XYZ resources for 1 month, and the user buys at market just before deploying, the user will pay 10 USD, nothing more, nothing less.

The Discussion

What do you think?
Let us know by sharing your thoughts and speaking your mind!

Threefold grows as the community expands the TF Grid.
If you have a different vision, or would like to offer some modifications, feel free to reply below.

1 Like

@kristof @weynandkuijpers @gosam @Sacha @victoriaobee
I’d be curious to know what you think of this!

Of course, everyone is welcome to join the discussion.
1000 minds are better than 1.

Note: I talked about this proposition with @scott before publishing this post.

A big part of the inspiration for this proposition is rooted in a comment made by @FLnelson in the Telegram chat. In short, Nelson said that it’s hard to track the TFT price for a given deployment with market fluctuations.

Thanks for posting this. Paying for TFT and then having how long you can pay for hosting change on you is a big issue.

1 Like

Very interesting proposition! It’s super clear and sounds like good idea to me, but I must admit my technical knowledge is limited so I might lack deeper critical insight. Curious to see what everyone else thinks!

1 Like

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

1 Like

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 :frowning:

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

1 Like

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:

  1. Adds complexity, thus hard to understand all the systemic consequences
  2. Must be implemented by engineers and deployed in release of TF Chain (also adds data to the chain while bloat is currently a concern)
  3. Can bring long term commitments into the system that reduce flexibility for future design changes

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.

1 Like

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.

1 Like

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:

  • Having a static price on chain, for example now: $0.02. This static price can be lowered / increased by doing a Voting round in the DAO.
  • Having an optional locking mechanism that locks the price of TFT at time of deployment.

Feel free to add some thoughts on this :slight_smile:

1 Like

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.