Update on Storage node payouts

Announcements
1

Hello storage node operators!

Thank you so much for the lively and exciting conversation over in the other post. We’ve read your comments and really appreciate all of the insight. There has been a lot of thoughtful discussion, and while there are no easy answers, we really appreciate the collaboration.

Based on the input you have given we have adjusted our thinking a bit on the best path forward and we wanted to lay out an updated proposal for you all to get your thoughts. We have outlined where we are at and what we are proposing in an FAQ below. Please look this over and let us know your thoughts.

The Storj Team

Q: What is the current situation regarding Storj’s storage node operator (SNO) payments?
A: Storj is stuck between a couple of facts, namely: (a) we pay SNOs more for egress than we charge, (b) we want to be a sustainable company that can continue to fund the development of this network, and, (c) we have hard-earned evidence that the market does not currently support raising prices.

Fundamentally, as we have said a number of times, SNO payments right now are being subsidized by us to grow the network, and we are currently in a position where the network is larger than it needs to be for the demand we have, and it is continuing to grow faster than we need it. We have been transparent that the time would come when we would need to decrease SNO payment rates, and we feel that that time is now. We realize that dropping payment rates will slow the growth of and maybe even shrink the network, and that is precisely what we have decided we need to do. Not a ton, but some.

Q: What other things have we considered to improve this situation beyond just lowering SNO payments

A: There are a number of things we can do to improve our unit economics beyond just lowering SNO payments, such as adjust RS parameters, charge more for add ons (such as edge services), restructure the free plan (see this post for an update), etc. We are planning to make some of these changes, and are taking them into account as we determine where we need SNO payments to be in order for Storj to be sustainable long term. Please stay tuned for more information about these things.

Q: What is the proposed path forward with SNO payments?
A: Right now we have decided based on the feedback from the forum and considering some of the points mentioned above that we can avoid changing the payout for data stored, so we are planning to hold that at $1.50 per TB Mo of storage for the foreseeable future. We are, however, proposing to adjust the payouts for egress and repair. At the moment, we plan to only change payouts on non-production satellites (we are still finalizing what these changes will be and when they will happen). And then, based on how that goes, we may consider adjusting payouts on production satellites. After this change, we will evaluate the impact on the network and use that information to determine what, if any, future changes should be made.

Throughout this process we are committed to maintaining relatively stable aggregate SNO payouts through the addition of data and egress to the network. We plan to do this through our regular customer growth and also through the use of synthetic load (test data and egress) if necessary. In doing this we are targeting greater utilization of the network, hopefully getting closer to the network being 80% full so that SNOs’ drives will fill faster and produce higher returns over time. As our customer growth increases we will slowly remove this synthetic load until the network is operating completely without subsidy from Storj.

While adding synthetic load to the network does add cost It is important to note that right now our main concern is our unit costs. We need to get to the point where every TB of data that we sell earns us money instead of losing us money like it does now. This is why we need to make changes to the SNO payments (as well as to R/S numbers etc…) Once we are unit profitable then as we scale we become more profitable overall instead of less. Also, we plan to increase the synthetic load in step with any payout decreases such that the total amount we pay SNOs remains relatively constant. This means that overall the addition won’t increase our costs. It will just keep them flat until customer growth catches up.

We do not yet know exactly where we will land in the long term on the payout amounts but we trust that the conversations we have, the economic signals we receive, and the corresponding network statistics will inform this process for us.

Q: How will Storj evaluate the impact of these changes?
A: We will monitor network capacity, sustainability, node churn, stability, and health at each step of the process, using this information to determine what, if any, further actions are needed.

Q: What options do SNOs have if the new payout structure doesn’t work for them?
A: If at some point in this process the payouts do not work for you, you can of course gracefully exit the given Satellite.

Q: What is the ultimate goal of these changes?
A: Ultimately, we believe we can achieve the dual goals of Storj’s long-term sustainability and that running a storage node can remain profitable in many locations.

35 Likes
2

I pretty much agree with all these points. Thanks for listening to us! Keeping the 1.5$/TB stored is the greatest news… for me, at least.

10 Likes
3

What about Held amount on test satellites, if you delete all test data, will you return held amount, because there is nothing to protect then?

5 Likes
4

Thanks for the update @john . It’s really good to see so much of the feedback from the previous topic being addressed in this update. I guess you really showed the people who said you guys don’t read the posts! :joy:

With payouts for storage remaining the same, I think there is room to move on egress pay to get that to profitability. And tuning RS could get storage to profitability as well. I’m a lot less worried about possibly having to shut down my smaller nodes now.

Please don’t overdo it on synthetic data. We may lose some nodes which would already cause others to fill faster. And as far as compensation for lower payouts goes, this step would only compensate nodes with free space. While it may help prevent some node churn, it’s also costly. Even if it doesn’t directly impact the main concern of unit economics.

tl;dr: thanks for listening!

5 Likes
5

Hiya @john, thank you for this detailed update. I appreciate you reading through all the comments and feedback in the other posts, and it shows in this one :slight_smile:

One follow up question: When are these changes proposed to take effect?

Kind regards - and once againg thank you for maintaining and supporting a great community.

6

I would suggest to close previous thread, that lot of people dont read new one and write on base of old info.

5 Likes
7

This is very generous, thanks!

1 Like
8

Thanks for the update, pleased some of the comments might of provided some change.

There is still concern, that tinkering with SNO payments is an unknown, and very risky - it’s interesting to see the change being rolled out on TEST Satellites first, to try and gauge SNO reactions and give you the opportunity to adjust… however you have to acknowledge that you will not see the true impact until you make the change to production where I would expect SNO to hang in until the last $$ before making change - would be great to see what rate you are proposing, you have to tell us at some point :stuck_out_tongue:

To hit 80% capacity, we are looking at loosing 3-8k nodes ! The concern is that this will hit smaller, newer nodes harder - however these are the nodes that are more likely to be running in homes and being truly decentralized. As the primary service provider to the customers, you should really be the one deciding the criteria for nodes to exit the network, its a red flag to see it being left to “luck” and “we can monitor the situation”, that’s not really good enough to give enterprise customers a good feeling. Something more stats based, like killing unreliable nodes, nodes that are slow to respond, nodes in areas where you have too many (Germany / France) - You could happy loose 1k nodes from France and Germany each , but loosing 1k nodes from Finland would be bad - I guess you need to pick a strategy, you already know there’s an issue with node placement, and the payments are going to bias this even more to favour West Europe, maybe that’s what you want but it’s not decentralization in the pure understanding.

There must be much hard work in the Storj teams, the transition is hard on all and causes uncertain times - Don’t let your decion making be controlled by the community, or the customers too much, you will be running in circles - listening is good, but sticking to the business plan and vision is more important for investment, and future stability.

CP :heart:

2 Likes
9

In the past, we decommissioned one satellite, and the held amount was returned to SNOs. I don’t see a reason to do it differently when we decommission other satellites in the future.

6 Likes
10

As i understand that you delete test data now from satellite, when it will be deleted, then no held amount needed. but i think it will stay working yet. but no data then no held amount needed.

11

This sounds good for my nodes with 0,4031€/kWh in Germany.

For income prediction, storage per TB is better than egress, and I like your suggestion.

My minimum would be:
$1.5/TB storage
$2/TB repair (can be even lower or close to 0)
$2-3/TB egress

Test data:
I would prefer that you start deleting test data now (slowly) rather than when the customers come in. If I need 10PB and see that only 8PB is available. I don’t want to have the conversation that you can start uploading and we’ll delete something else in the meantime.

2 Likes
12

I suggest to put a GE button next to the test satellites’ names on the payout information screen of the dashboard. As soon as it is pressed, it would show the GE progress % and confirmation when GE finished.
This would be node operator friendly for the smaller nodes. Pro operators are not affraid to do some CLI magic.
I have 6 nodes and found that 2 of them (one Linux and one Windows based) are getting half of the payments from the test satellites. So if I would like to help you and follow your plan, I need to do some CLI magic, which I’m a bit scared of…

3 Likes
13

I can understand the growth through regular customer data - but what about the ‘user of synthetic load’? Since synthetic load causes uncessary bandwidth and overall costs the storj funds, wouldn’t it make more sense to reduce that? Or do you mean, that reducing the synthetic load too much would have the psychological effect on the SNOs of storj not being ‘worth it’ (due to lower activity) and hence they leave?

I’m not sure, but I have to say that I actually prefer the focus on real customer data and accept the fluctuating demand in exchange. After all other networks such as filecoin are not based on actual demand but primarily on provided storage.

14

I think this part addressed that.

It probably makes more sense to try and retain nodes during the transition to new payouts as much as possible. Hitting them with both payout cuts and test data removal at the same time could cause more node losses than the payout cuts alone would. And using synthetic load to ease the transition might get more nodes to stick around if additional data compensates for the loss in pay.

2 Likes
15

The idea is to have a smooth transition. In my case 2/3 of my payout is for egress. That is going to get cut down. At the same time, I do have a lot of free storage. So the expectation here is that all the remaining nodes just store more data and hopefully that is enough to keep them in the network.

This will not work for everyone ofc. Some node operators will be forced to give up. We just want to make sure they don’t do it because of low utilization. We want to create a situation in which only the nodes give up that can’t deal with the new payout rate even with higher utilization.

But let’s be real here. It is easy to plan a higher utilization. Executing that plan is a totally different story. So for now I just stay in the network to wait and see but my expectation is that the necessary uploads and downloads will get way to expensive.

2 Likes
16

This seems to penalise SNO’s with older nodes on smaller drives. Because many of these older smaller nodes are full. Which then means if the SNO is to get greater economies of scale adding extra, larger drives. Which is kinda contrary to the “only use what you have” mantra Storj pushed for so long. The SNO’s that survive will be those with larger capacities with lower energy costs.

2 Likes
17

as storj removing old data, so soon old nodes will be not full, also they remove it slowly so may be you just not see that data changed to new one.

18

The node income is still going to go down and it is stated payment rates for egress will also go down so even if there is greater utilisation the net income for a formerly full node isn’t going to be what it once was even when it gets full again.

1 Like
19

Yeah, but there is no way around that. Payouts need to drop in order to get unit profitability. Only thing Storj Labs can do is compensate with extra load for nodes that still have free space. If those full nodes aren’t profitable with the new payouts, they would never survive to begin with. Nodes with free space may remain profitable with synthetic load compensation, showing they would also be profitable if they are full of customer data.

1 Like
20

That are basically ideal conditions. I don’t see a problem with nodes that are full. They can decide every month if the new over time reduced payout is still worth it.

The problem we see are nodes that are not full yet. A decision is hard for these nodes. For my own node the new payout rate is simply not worth it. I need to accumulate more used space to cover my energy costs. That means for my node there are 2 variables. So the idea is that we reduce that down to 1 variable like it is for full nodes. (As explained above I still expect it to be 2 variables and I am just staying to see how fast I can accumulate more space vs how slow the payout rate gets reduced)

1 Like