However, no details on a direction for these changes were provided, yet feedback was requested. Alright… I guess shooting in the dark it is then (for now).
I want to address a few things:
- Storj currently runs at a loss, subsidizing both storage and egress
- Demand for Storj DCS is growing rapidly
- What does “sustainable” mean in this context
First off, lets look at the current situation.
Storj currently charges the following for their services
$4 per TB of storage per month
$7 per TB of egress per month
Storj currently pays node operators the following
$1.50 per TB of storage per month
$20 per TB of egress per month
$10 per TB of audit/repair egress per month
Going by the median healthy pieces count (mean is unfortunately, not provided in stats, we can calculate an expansion rate of 66/29=2.28x. This leads to a cost per TB of customer data of $1.50*2.28=$3.41.
Additionally, about 5% of data needs to be repaired per month. Adding 5%*$10=$0.50 of extra costs for repair of static storage. Plus additional costs of egress by repair workers.
So, that leads to a profit for Storj labs of
Per TB storage: $4 - $3.41 - $0.50 = $0.09 (without taking account egress costs for repair workers hosted in the cloud)
Per TB egress: $7 - $20 = $-13
In short, Storj runs at a significant loss currently for both egress and storage (if you take repair egress costs of repair workers into account). And this doesn’t take into account compute costs or pesky things like having to pay salaries pay for buildings and other costs of running a business. Nor does it take into account payouts for partner programs.
Alright, let’s move on to the second point. Demand for Storj DCS is growing. That’s great news, but it also means at the current pricing model Storj Labs gets the lovely reward of running even bigger losses! Yaay!
Furthermore the wording during the town hall presentation suggested demand is growing faster that storage availability (my interpretation, this wasn’t specifically mentioned, but hinted at).
If that’s the case, Storj Labs is in a bit of a pickle here. They can’t exactly do nothing or the losses will grow and they will burn through token reserves faster and faster. But they also can’t really start paying node operators less and risk losing supply (and triggering large amounts of repair).
They also can’t start raising prices for customers as that is one of the main reasons Storj DCS is starting to see so much traction.
And for further context since last quarter 3 out of 8 tranches of long term token supply owned by Storj Labs have been unlocked. The token value has dropped and this means Storj Labs is burning through those reserves faster as well.
So what does this “sustainable” future mean then?
In my opinion there is no way this new model isn’t going to suck for node operators. We all knew this was coming ever since the massive price drops for customers were announced. But growing demand for the service and lower STORJ value have moved that inevitable moment a lot closer. I think we as node operators should start discussing what we would find reasonable. Without a starting point from Storj Labs to discuss about, I’m just going to throw out numbers that may not even work for Storj Labs (the margins for this shot in the dark are much lower than they were before the customer price drop).
Possible future payouts:
$1 per TB stored
$5 per TB egress (including repair/audit)
This would drop payouts on my largest node by 55%. Without a starting point provided by Storj Labs themselves… let’s just discuss what this (optimistic) shot in the dark would mean for our setups. Can we still afford to run our nodes, would it still be worth it?
- Since more supply might be needed short term, surge payouts should be more frequently used to subsidize SNO’s in times of high demand compared to supply. Furthermore, surge payouts could be used to ease transition into the new payout scheme. Starting at 200% to almost match the previous payouts. Perhaps dropping by 5% each month. The surge feature would give Storj Labs a knob to turn play with to gather supply when needed, while the minimum normal payouts give node operators a guaranteed minimum payout level to scale their setups to.
- Incentives to prevent repair should be implemented: Eg. weighted selection of nodes for upload, preferring nodes that triggered less repair in the past. Payout penalties to nodes that triggered repair in the payout month. Not paying for storage during offline time for nodes. These changes should hopefully lower the amount of repair needed, which is also why I didn’t lower the repair egress as much in the wild guess for payouts above. Also, egress is egress, it doesn’t really make sense for node operators that some egress is paid more than other.
@john: Sorry if I’m pre-empting planned discussions. But as you can imagine, this is of great concern to us node operators. Many of us have invested in setups and we need to start figuring out whether the possible future still makes sense with our setups. Please feel free to correct any (of the many) assumptions I made here.