Stake economics

[Menduist]

I'm trying to build some intuition on the stake amount.

I take it from the point of view of the hoster, since they will be choosing their price after all. I based my data on a 12 * 4TB sata server that costs 330€/month. And a 5% wanted APR (on staked money + cost of server)

Other assumption, the host sell contracts on a monthly basis (a shorter contract will have a lower stake, so this matters a bit <- i'm not sure about this anymore, need to check)

Note that this is very crude, and just to give us some order of magnitude.

The "raw storage" cost to the host 6.87€ / month / TB
I add the margin: 6.90€ / month / TB

So a one month, 1 tb contract would cost 6.90€ on storage only.

Lets say I stake 100% of the amount of the contract (so for a 6.90€ contract, a 6.90€ stake)

I add the monthly APR of my stake to the contract cost (0.05 / 12 * 6.90 = 0.03€)

The contracts now costs to the user 6.93€ (for 1tb for 1 month)

Now, what happens if the host loose a 4TB disk?
That would cost him 27€ in stake.

Here is some data with some different stake "factor":

Staked factor	Contract cost	Lost stake per disk failure
0x	6.90€	0€
1x	6.93€	27.61€
10x	7.19€	276.1458€
100x	9.78€	2,761.45€
500x	21.28€	13,807.29€
1000x	35.66€	27,614.58€

So the good thing is that we can really go mumbo jumbo with the stake factor without increase too much the contract cost, if we just count the APR.

Now, we'll look at redundancy rentability in the point of view of the host.
If we count a 1% disk failure per year, it means that on this server, with a 1000x staked factor, the host will loose on average 3.300€/year.
Which is approximately the cost of the server.
So with a 1000x stake factor, it's worth it for the host to rent a second server, and mirror the first one with it.

And to the user, that would cost 35.66€/TB/month. (S3 costs 24€/TB/month)

With 100x stake factor, he looses 331€/year. At this level, it's already worth to sacrifice some capacity by setting some RAIDs 5.

With 10x stake factor, he looses 33€/year. That's probably worth to loose this amount, and so not take any steps to avoid loosing data.

Note that with this system, the majority of the "cost" for the host is not actually renting the server, but his stake. This server which costs 330€ per month would require 33,000€ of stake at 100x stake factor.
That may be a big limit of the system, maybe we should think about delegating stake.

And all of this is for a single hoster. Of course, in practice, we would want multiple hosters.
If you want pay 35€/TB/month, you could either have one hoster with 1000x staked factor, or 5 with 10x staked factor. (or 1 500x, 1 100x and 1 1x, why not)

This is also not taking into account that if someone wants to store data on your server, it's often to retrieve them later. A hoster could sell contracts without margin, or at lost, and recoup on the BW

[dryajov]

I'm not sure I understand how your deriving the stake where, for example how did we got to 27.61? The cost of the storage to the hoster + an equivalent cost in stake would have a factor of 2 to the hoster, which comes at 6.93, what am I missing?

[Menduist]

27.61 = stake per TB * 4 (capacity in TB of one hard drive on this server) = 6.90€ * 4

Maybe the lost stake per disk failure is not relevant and I should just put the lost stake per contract.
I originally had everything in GB, so the stake per contract was like 0.0069€, that's why I put per disk instead of per contract

[Menduist]

Your also mentioning something that I didn't take into account: when someone looses data, they not only loose their stake, but also the money they would have won by finishing the contract..
Bit tricky to take into account, because for instance, if you loose the contract very close to the end it "costs you more", but anyway, this doesn't change the order of magnitude

[dryajov]

27.61 = stake per TB * 4 (capacity in TB of one hard drive on this server) = 6.90€ * 4

Oh, I see didn't make the connection 👍

[dryajov]

Your also mentioning something that I didn't take into account: when someone looses data, they not only loose their stake, but also the money they would have won by finishing the contract..

Yes, I think this is important and has some interesting implications, for example - do payouts happen gradually over the lifetime of the contract or does it happen at the end?

I would assume that in general, gradual payouts are more vulnerable as they loosen the assumptions built into the stake, but I'm not 100% sure on this yet.

[Menduist]

I would say it happens at the end, don't matter much, since at the end of the contract, 99% of the money going to the hoster wallet will actually be it's stake (if we talk about a 100x stake factor)

However, the stake burning should be gradual to allow some downtime. (probably exponential)?
Even amazon has a 90% SLA (on a single instance).

If we burn the stake too quickly, that would be bad: let's say we burn everything in 6 hours, my server looses internet for 10 hours. I still have the data, but at that point, I lost all my stake, so I might has well delete the data and find new contracts.

[dryajov]

In the general case, if one of the argument is that the stake might be prohibitively high, I need to clarify my general intuition behind it. The stake is a security guarantee that should reflect the hosters commitment to hold on to the data, i.e. skin in the game and risk exposure.

The idea is that, the stake serves as both a signal of this commitment and as a deterrent from deviating from the protocol.

[dryajov]

To expand on this, I think it would be wrong to make a direct connection between amount of storage provided vs signaling commitment, this are a bit different things, but not necessarily mutually exclusive.

The tricky part is reconciling this two notions - for example, does signaling "commitment" implies that the provider has enough storage to satisfy the contract needs?

[Menduist]

The goal of this write-up was mostly to build some intuition and explore the economics behind the stake. What I've learnt looking into it:

• The lower boundary of the stake is obviously the "Nothing at stake", and we now know that this happens below ~100x stake factor
• The upper boundary can be either the moment when the stake becomes too expensive for the host
• Or when paying the "interests" of the stake becomes too expensive for the user. (So for instance, in my table, at a 500x, you pay 14.38€ of interest for 6.90€ of actual storage)
• The wanted APR and contracts duration have a high impact on all numbers I sent. A higher APR means more "interest on the stake" for the user. A longer contract duration will be more expensive, and thus have a higher stake.

This wasn't meant to be a critic or an argument, just some "facts" to have in mind while designing the protocol :)

The reason why I used the staked factor, and thus made the stake linearly dependent on the contract cost, is precisely because the users have to pay the interests for the stake.
Too keep theses interests reasonable no matter how much data you want to store, I think it makes senses to count theses interests as a percentage of the total cost of the contract. And if you reverse that, you end up with a stake being a factor of the total contract cost

[dryajov]

This wasn't meant to be a critic or an argument, just some "facts" to have in mind while designing the protocol :)

Oh I didn't perceive it as such, I think these are great points and the intuitions seems correct to me. My comments where just thinking out loud/expanding on some of the intuitions :)