JKL 2.0 Economics Discussion

Thank you for your input. Your equations are definitely interesting and are successfully adapting the storage space supply. Nevertheless, I would start earlier and first examine the current relationship with the storage space suppliers and consider which type of suppliers we want to have in the long term and what their needs are. then I would try to set up a suitable mechanism afterwards.

Why not just use your equations? there are several reasons. First, you take current inflation as a given and don’t consider that this framework is not ideal. Jackal didn’t spend much time on their economical model, therefore you are missing an opportunity here, if you don’t consider changing the inflation schedule.

As you can see on the chart above, they simply reduced the number of minted tokens per block by 1 every year (column on the right). It’s unlikely that this approach leads to an optimal outcome. Therefore, adjustments seem to be necessary.

Second, the inflation to storage providers remains at a maximum of 60%. Currently, there is no demand for storage space, but if demand exceeds supply, there will be no further adjustment of inflation and people will be unable to store data. Another reason is that in your model, the part of the inflation that no longer goes to the storage providers now goes to the stakers. So inflation remains the same, but goes to validators and delegators instead of storage providers. Not saying, that this is necessarily bad, but as the majority would like to reduce overall inflation, this might not be the way to go.

I want to emphasize that I think your post is great. Do you have time in the future to contribute more to the topic? If the Jackal team can provide some input (my questions can be found in my previous post), it would be great if we could continue to work together on a meaningful model for jackal

Btw. What is your background? Validator?

No worries. I was just trying to create a model from existing parameters as I really have not went in-depth with the tokenomics as of yet. The reason I had the remaining inflation go towards stakers is because node providers tend to sell their rewards to cover the costs of the service they provide, whereas most stakers will re-stake the rewards and cash out at a later date because of the lockup period. The model can definitely be adapted for more ranges of usedRatio, think (0,.10], (.10,.20], etc

With a tokenomics reform maybe the team can adjust our model similarly to meet the new parameters.

Anyhow, my background is in number theory at the graduate level. I earned my M.S. in Mathematics and left in the second year of my PhD as unforeseen circumstances occurred and I had to quit my studies (much to my dismay). Now, after several years searching for myself, we operate a dev team for Sentinel (dVPN on Cosmos), are a top 5 validator on Sentinel, and also validators on BitSong, and Decentr as well. We have developed an analytics suite for Sentinel and also a desktop DVPN application called Meile. I also dev for the Monero project and a few others.

Jackal sparked my interest a few months ago after I appeared on a podcast targeted toward Latam. The next week a spokesman from Jackal appeared and seeing as I am looking to use decentralized storage since Google is deleting my university GDrives on January 2nd, I would like to stay in the Cosmos ecosystem. Currently running a SIA node and have used Storj. Also, we have given some thought to running a validator on Jackal and I think the time is right. I expect to launch a validator on Jackal in the coming months.

We (Sentinel) have a network upgrade occurring in the next week or so, therefore I will be pretty busy rolling up a release of our desktop app for the network upgrade, alongside updating our validator. I hope to contribute more to Jackal afterwards and look forward to spinning up a validator here.

Hey there!

The amount of storage space available is self-reported by the storage providers. It is easy to ask them to prove they have data, asking them to prove they have an amount of nothing is much much harder. We do not do anything to detect bad actors as this doesn’t currently affect the system in any way. It can make the UX for a user slightly worse if they attempt to upload a file to full provider that is incorrectly reporting but the request will simply fail and the client will roll over to a new provider. Incentives are not based on self-reported space, they are only based on how much space you store each challenge window.

As for how well we know the storage providers, our aim from the beginning is to have a permissionless decentralized storage platform where anyone in the world could spin up a provider without needing to pass any sort of KYC. Thus, for the sake of the platforms original intention, we, in theory, know none of our providers. We can ask current providers what their costs currently are, which is something we had done both while writing the econ paper and followed up to adjust where needed.

Jackal Labs does not act as a storage provider directly but we have good personal relationships with some of the larger providers on the platform that advise us directly on the inner workings of their systems.

So according to the paper and your explanations, every time a block is created in year I, 10 new $JKL are created. Out of these 10 $JKL, 6 are used to incentivize the supply of storage providers and 4 are earmarked as staking rewards. So the projected cost to incentivize the storage providers is 31,536,00 $JKL in year one, while we spend 21,024,000 $JKL to incentivize staking and to pay the validators for running the software. All in all the projected inflation is 53% in year 1. But this is based on the genesis supply of 100,000,000 $JKL. Most of the minted genesis tokens do vest over several years. If I understand the token distribution table correctly, only 31,000,000 $JKL were circulating at genesis, while the residual 69 million were vesting. 21,830,000 will vest during the first year, which leads us to the following situation:

Circulating supply at genesis: 31 million token
vesting tokens in year I: 21,830,000 $JKL
Storage provider incentives in year I: 31,536,000 $JKL
Staking rewards in year I: 21,024,000 $JKL
Circulating Supply after 12 months: 105,390,000 $JKL

Real Inflation in Year I = 239.97%

But let’s come back to the storage provider incentives. According to the paper, roughly 32 million jackal will go to them in the first year and according to you, it won’t be distributed according to the self-reported storage space, but according to actual data stored. This leads to the question how the protocol decides where new data is stored? Let’s assume we have three storage providers. A has 3 TB of self-reported storage, B has 5 TB and C has 10 TB. Now I bought 2 TB of space and want to store 1 TB. Who is storing my data now? And follow-up question: How often do these challenge windows happen?

So what can you tell us about the storage providers? Does the majority of them run their own machines at home, or can they simply rent and provide storage space from other service providers (like amazon). The percentage of used storage has been below 20% during a longer period, which probably indicates, that the providers cannot easily use their storage to monetize it in a different way (otherwise they would remove storage space and this number would go up, as you said that incentives only go to people who actually store data).

And just to make sure: The total amount of JKL incentives to storage providers (6 JKL each block) is regularly distributed (after a challenge window?) according to your relative share of data stored?

why not cut the inflation going to storage providers entirely and distribute a % from the revenue directly between all storage providers?

You can change the % of revenue distributed based on supply/demand. you don’t want more storage than you need and when you do need more, just vote to change it

The revenue from users, who pay to store data will most likely never match the cost of the storage providers. And if you only take a cut from the revenue and redistribute it, providers will run at a loss and drop out of the network. End of Jackal.

We need to understand the dynamics and create a real working model. Quick fixes will only make everything worse.

Maybe I’m misunderstanding, but if revenue could never match cost of storage doesn’t that mean it’s fundamentally not a viable business?

If the cost of goods sold is higher than than potential revenue from those goods, that means the business won’t ever be profitable no matter how many token incentives are used to band-aid the issue over short term.

No, first of all it’s only a hunch I have. Second, there are plenty of ways to make $JKL a success anyway.

First: Our cost structure is significantly worse than the cost structure of our competitors. AWS etc. do not have a validator set which is costly and the storage they provide should be significantly cheaper per TB than ours. They do not have to pay a premium to suppliers and they do most likely do not have to make so many copies of the stored data. At the same time, customers are historically unwilling to pay a significant premium for improved privacy, so it’s unlikely the revenue from the storage will ever break even. Only my hunch for now.

Second: If you think this is our sole business, then you would be right, but maybe it helps you to think about this more as an infrastructure layer. In Germany we have a lot of costly highways and we run them at a loss (if you only look at a single highway). But for our economy as a whole they are of course very profitable as they allow companies to ship goods from A to B very fast and at low cost. At the same time it benefits the people who live here. If we can recreate these profitable businesses on jackal, which use the underlying infrastructure (blockchain and private storage) and at the same time drive value to the token (by paying gas fees and maybe even a revenue split if we funded them f.e. or if they are built by jackal labs), the jackal ecosystem may very well be a great success :fire:

1 Like

Hey brother, linking this here to make sure to get your feedback. I’ve really enjoyed your comments and thought into Jackal’s tokenomic situation and am keen to hear your thoughts on this direction?

1 Like