With the launch of the MVP close, I like to focus on some numbers and fundamentals which I think are important to watch. This topic is not in the first place about Farming/Safecoin. More like deciding how many Vault a user can run, how many Chunks will go in and out, up- an download speeds and more.
All Vaults are equal
This is the idea, of course they’ll store different Chunks, but when we have 1000 users on SAFE and each user runs 1 Vault started at the same time we should see an equal distribution of data. But of course this won’t be the case. We’ll see different users running a different number of Vaults all started at different times. So there goes the equality 
. But what fundamentals are important when running a Vault??
The Average Vault size (AVS)
This one is quite important. We could look at it from the perspective that a Vault is online and filling up for say 48H. In that case a lot of the Chunks (that the Vault/Managers is close to) should be distributed to the Vault. The Vault should be filled up to the network average. So we’re left with a number in Megabytes which we can use (and agree on) as the Average Vault size. When 1 user starts a Vault in the US and runs it for 48H. it should fill up to the same amount as a Vault in Europe over that same period.
The Average Cache size (ACS)
All Vaults will take part in the network as they deliver Chunks as requested by the network. I don’t know if the cache is the direct responsibility of the Vault but for all calculations we should include the size (per Vault!) of it and take in account how many data is delivered from cache. We might be able to store 2 Terabyte of data for the network, but if our upload speed is way to low to deliver all requested Chunks we might be in trouble as our ranking goes down. And cache is part of this.
Chunks delivered out of cache (CDC).
How many Chunks per day per Vault are requested out of cache?
Chunks requested per day (CPD)
How many Chunks do we deliver out of 1 Vault over 24H. This is one of the most important numbers IMO. It allows users to make a rough calculation on how many Megabytes will be uploaded out of the Vault directly.
Average Chunk size (ACS)
We will store over 1000 Chunks per Gigabyte. But what’s the average size? Not all Chunks are exactly 1 Megabyte.
Stored and delivered Chunks Ratio (SDCR)
This one could be calculated using the (Chunks delivered from cache + Chunks requested per day) / Average Vault size. We could see a number that’s > 1 if we deliver more Chunks than we have in our Vault due to cache. Remember we take the average Vault size (even if our Vault just started and only stores a few Chunks) because when we run a Vault for 48H. we probably will end up with the Average Vault size.
Daily growth of Average Vault size (DGV)
How many Vault should we run? Well, before we can answer that question we need to know if Vaults are growing or declining over the last few days/weeks. We don’t want to start 4 Vaults if we know that the average growth per day is 2% and we’re already at the limits of our dataplan with our ISP.
Optimal number of Vaults (ONV)
How many Vaults should we run? To know this we need to know all details of our dataplan with our ISP. Downloading Chunks probably won’t be the problem. Same for storage. It’s so cheap that we can afford Terabytes of storage for years at a very low cost. It’s upload limits where the pain will be for most users. So when we calculate the optimal number of Vaults we need to take in account both the Chunks delivered out of cache and the Chunks requested per day. These will be the main limiters for the average user.
One might suggest to limit the upload speed (to say 25% of max) to make sure that Chunks can be delivered and more Vaults could be run. But is this the best solution? It will slow down the delivery of Chunks and therefore the network. So it might be better to not limit the upload speed at all and run less Vault. Instead of running 4 Vaults at 25% upload speed the network (and probably the user) will be better of running just 1 Vault and get less requests over he day.