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.