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!
TFT Locked Value During Deployment
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 
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.
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:
- The user still pays for the deployment until he finds out about it and cancels the contract(s). - Unfair for the user that used the grid and has to constantly monitor it to prevent this scenarios.
- The farmer won’t receive his farming tokens. - I see this as as a “soft” but I admit is a fair measure but would appreciate more something like collateral loss - but that is another topic (way more complicated!!)
1 Like
I appreciate your honesty. What would make this a priority in your opinion?
Hello everyone.
Topics on billing are growing everyday all over the forum. I don’t think this is sustainable anymore. If for some good reason the grid gets a large amount of user, it will be catastrophic for the project. I ask everyone to take some minutes of their time to read this post and to participate, including the dev team…please let’s push things forward!!
Appreciate the inputs on this from @dylanv and @nooba.
I’ve been mulling on this one for a while and felt stuck on the following points:
- Allowing a user to prepay for a specific deployment on a specific node or farm is somewhat rigid, or requires introducing more complexity to cover moving or expanding the deployment
- Simply locking the TFT price for an individual contract at the time of deployment means that the user would want to destroy and recreate the deployment when the token price goes up, so they can lock in a better exchange rate
- Prepaying individually for CUs, SUs, and NUs, a la the capacity pool model of Grid v2, means that the user must always anticipate what ratio of compute/storage/network they will consume and it ends up being both complex and rigid
- Setting the TFT exchange rate via DAO vote is the simplest solution and is what I intitially favored when considering the problem we’re trying to address here, but it feels high maintenance in case of price volatility and will always confuse new users like the DAO price for farming does
With all that in mind, here’s my latest proposal for a mechanism that can make billing predictable, while minimizing changes, rigidity, and complexity.
Dollar Value Deployment Credits
At any time, a user of TF Chain can exchange TFT for an equivalent amount of dollar valued deployment credits, based on the current TFT/USD exchange rate. These credits are associated with their account, are non transferable, and can be spent on any deployment on any node on the Grid. The TFT are then held by TF Chain until the user spends their deployment credits, at which time the TFT are distributed and burned according to the typical proof of utilization flow.
Some further details:
- When TF Chain bills a user that has both deployment credits and TFT in their account, the deployment credits are always used first
- Staking discount levels are determined based on the sum of both credits and TFT in the account at the current exchange rate
Redemption (optional)
An optional redemption mechanism can be added, to allow users to redeem their dollar valued credits back to TFT. It works as follows:
- If the TFT/USD exchange rate is equal to when the TFT were exchanged for credits, redemption is again 1:1
- If the TFT price in USD is lower than when the credits were issued, the user can redeem at 1:1 with respect to the original issuance price (burn all credits to receive all remaining TFT)
- If the price of TFT is higher, then the user can redeem for an equivalent USD value of their credit. In this case, they would receive less TFT than they deposited per dollar redeemed and the remaining TFT would be burned
Redemption gives users an option to either take their value out of the system or regain exposure to TFT price at any time. While not required to get the core benefits we’re looking for here, this would help with any hesitations around a one way conversion into an illiquid account credit.
Issues
The biggest issue I see with this proposal is one it has in common with the others—that is, proof of utilization beneficiaries (solution proviers/sales channels) could receive less TFT than the value of the deployments they are benefiting from. When the price of TFT is lower than when a user converted their TFT into credits, the recipient (also the foundation) effectively receives TFT at a lower than market rate versus the dollar pricing of the deployment. Overall, I think this actually isn’t a huge issue, because the opposite is true when the price of TFT is going up.
Any others I missed?
Just want to wrap up this post by acknowledging this comment. Indeed, it doesn’t feel right that users are billed while a node is down, but as Dylan noted this is substantially more complicated for us to implement on the Grid than it is for a traditional cloud business. I’m happy to continue the discussion around how we can make this happen—let’s do so in another thread to keep this one focused on solving TFT price volatility for deployers.
1 Like
Locking value of TFT is technically hard, because every TFT could be locked against a different value. This means the lock price becomes part of these new tokens, thus turning them into NFT’s, something which is very hard to scale.
I’ve been pondering about making deployment payments more accessible, in a slightly different way, but it is also applicable here. The idea is as follows:
We start by introducing “assets” on chain. An asset is a token anyone can create, with some metadata (e.g. digits for one token), which can be minted and burned by the issuer. This is not unlike how TFT is currently a token on the stellar blockchain. In a similar fashion, operations on these “assets” are transactions on TFChain, and thus require a minimal amount of TFT to pay for the transaction fee.
Then, we introduce the liquidity pool concept. A research project already exists from a separate organization to add the uniswap V1 protocol directly on substrate based chains, working with these “assets”, so this is something which seems doable (the impact of transaction volume on the chain size should be investigated first of course).
We also generalize the current bridge module, to not only support TFT coming from stellar, but rather make it generic over the token (which would then require an asset to be created on TFChain). Similar to how tokens exist on different chains.
Lastly, we add an optional field on contracts specifying which asset to use to pay for the contract. If this is not set, the user pays in TFT, like it currently is.
Putting it all together:
The DAO creates an asset for “some currency”. In the current case this would be some kind of USD stable coin. A bridge is set up from this stable coin to TFChain and in reverse. DAO is used to create the asset to gain improved governance on the asset (i.e. no funny business where someone just destroys the asset or freezes it for certain people).
The DAO then sets up a liquidity pool for this asset to TFT. Again the DAO sets it up so there is governance in the parameters of the pool. The pool is funded with some initial amount of asset and TFT.
The DAO approves this asset to be used in contract payments.
Now when a user creates a contract, he can specify to be billed in the “USD” asset. At payment time, calculations are done as normal to get the amount of TFT the user pays. If no alternative payment currency is set on the contract, the payment happens as normal (TFT is taken from the account of the user and distributed to the receivers). If Asset is set, an additional step is done where the exact amount of TFT is purchased from the pool, which is then transferred to the receivers. The amount of Asset required will depend on the price of the pool at that time.
There might be marginal differences on the charged price in USD based on the price in the pool (as opposed to being actually fixed since we calculate cost in USD). However this seems like a worthwhile tradeoff for a truly generic solution. For instance, it is very easy to also use the same flow to allow payment in ETH’s, DOT’s, XLM’s, … All that is needed is a bridge implementation and the DAO doing some calls for the required setups.
Notes:
Exchange price of the Asset is governed by the liquidity pool on TFChain in this scenario. This price can and will be different from the “official” price. Specifically, multiple swaps in the same block might also increase the price. This should not pose a problem however:
- Arbitrage can (and will) happen, so price of the liquidity pool will be maintained very close the the official price
- Swaps for contracts will be for small amounts (since payments are regular). Even if a large amount of swaps for contracts happen in the same block, a sufficiently large liquidity pool (which again is actually not that large) will be an effective buffer here.
4 Likes
Well I must say, this discussion is getting pretty interesting!
Thanks everyone for your time and energy.
The last two replies, from @scott and @smetl really push the initial concept to a next level!
@scott would you say that your idea fits 100% with smetl’s idea?
I would say yes.
For communication sake, let’s call this idea Assets on TFChain, and specifically for this use case USD Asset on TFChain. (If there’s a name for this, let me know!)
It seems it’s a very good solution that expands well long term. Amazing idea Lee!
So, meanwhile, we could implement the simple solution from @dylanv, that was used before:
- 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.
What do you guys think?
As many discussed here, the following initial idea isn’t optimal for the whole TF ecosystem:
- Having an optional locking mechanism that locks the price of TFT at time of deployment.
For the Assets on TFChain project, we could have a meeting soon or distribute some tasks to make it happen.
Of course, we would vote with the DAO on decisions to be made.
@Mik I don’t think we have to set a static price for now, the price is pretty stable at this point (1.3 - 1.5 cents)
But indeed, the idea from Lee sounds pretty good!
We also have to think about incentivizing liquidity pool providers, because you need a good amount of liquidity in order for the price to be stable (other wise it will shoot up very fast and arbitrage traders will take advantage). Currently, 5% of contracts rewards are send to a staking pool address, but since we have no staking pools on tfchain this rewards could be sent to liqudity pool providers.
“Currently, 5% of contracts rewards are send to a staking pool address, but since we have no staking pools on tfchain this rewards could be sent to liqudity pool providers.”
Sounds like a very good idea.
Also, we could offer some TFT workload discount to users providing liquidity in the pools.
Since their TFT are in the liquidity pool, they won’t get the discount.
So by smart contract, their address could be eligible for the discount deployment.
Thus users of the Grid have an incentive to add to the liquidity pools.
About the price being stable, this is only true when looking within a short timeframe, as of course the coin over months has been moving quite a lot.
That being said, this feature becomes of second importance it seems, if we can implement @smetl’s idea.
Having different assets on TFChain, but always paying everything in TFT is such a nice concept.
This coupled with bridges of sorts linked to different blockchain projects, the use case would be the most accessible yet.
1 Like