Realistic earnings estimator

understood, thank you @BrightSilence

At the end of 30 days, the internet bill must be paid. 1000 mbps internet in Turkey is 1200 dollars. Since 75% is kept indoors, even if a 1000 tb system is installed, it does not even pay monthly expenses, so no one invests in large heels in the first month.

You should not include the running costs, because we always asks to use what you already have, preferably on hardware which will be online anyway. In this case all costs already paid and any earnings is a pure profit.
If you decided to invest, you should calculate your ROI yourself.

Yes, that’s the current mission. however, when the project is adopted tomorrow, let’s assume that 50 zettabytes of data in the virtual world are in 1% storage in 2022. won’t there be a need for a stronger data field for those times? If we are to be visionaries, we need to think like this.

I think the economics will work better. If it would be profitable - this will always attract participants.


That exactly what this guy was saying too Storj Mining in 2020 - How much you can earn being a Storj Node Operator - YouTube

to be honest, guy dont realy even understand what the storj is, it not raning on blockchain and dont use only docker or linux.

1 Like

That official estimator is long gone in part because of the feedback in this topic. It was made prior to the network going live so they didn’t have much actual data to base it on at the time. They now point to this topic from the knowledge base and on the forum when people ask about earnings. Since this earnings estimator is independently built and maintained it works in two ways. It shows storage node operators a much more realistic earnings expectation as well as serving to keep Storj in check. When earnings start to drop, that will be reflected ones I update the estimator. If that starts to not become profitable for most users, they’ll have a bad time attracting new node operators which is a good incentive to make changes to ensure profitability.

The nature of this estimator is such that if I stop maintaining it for any reason, someone else can just pick that up. I encourage making copies of it on your own Google account. Storj is all about decentralization, so let’s keep that philosophy for community tools as well!

As for feedback for this estimator, it is always welcome, but I will only make changes if data is provided that shows things are off balance. In some cases that would require multiple sources as a single node could have issues. Please let me know if things seem wrong to you though.

I expect to update the numbers again soon. Unfortunately it looks like it will be another slight downward adjustment.


why do you need 1000mbps? I was under the impression that 50mbps is more than enough

1 Like

I’ve updated the network performance stats on the estimator. Unfortunately it was again a downward adjustment. Egress has dropped quite a bit and repair has dropped a little as well.

All downward adjustments taken together, egress has basically been cut in half from where it was sitting quite stably a while ago. Now I’m hopeful that this is mostly because Storj Labs is cutting back on testing/incentive egress, but we haven’t had an update on testing traffic in a while now, so we can only guess.

@john: You gave us an update in the past regarding test data here. Any chance we can get a similar update about what test data and traffic looks like right now and what’s to be expected in the future? Earnings drops impact node incentive and the total number of nodes seems to be slowly dropping now. This estimator is one of the first things many prospective node operators will see. I think it would be beneficial if it looked a little more lucrative again. Are there any plans on changing this? Or expectations of customer growth?


A post was split to a new topic: I have done some test here but it’s really disappointing

@BrightSilence Thank you for all the work you put into this and for making it publicly available! It is really nice to be able to play around and get an idea of what the revenue could be for your node.

Don’t take what I am about to say as an argument against this estimator. I know we are all dependant on the network activity and outcomes can be quite different. Id like to share the differences between my node and the estimator so far. Even though my node is still very young and lots of things can change.

Copy of Estimator with my node numbers: Copy of Storj earnings estimator - Google Drive

Actual numbers: (Still messing around with the max ingress, delete rate and bandwith to get as close to my actual numbers as possible)

After monitoring my node for the first two weeks of its existence I do see results that are wildy different so far. I have a node with 16.2 TB available running on a R Pi 4. Fiber 940 mbps down, 880 mbps up. If the current load remains more or less the same I will end up with around 0.03 Terra bytes stored in the first month instead of 0.09 estimated. So it will likely be lower by a factor of 3.

The percentage of deletes is also a lot higher with roughly 25% of the data in Trash at this point in time. If that percentage of deletes holds overtime I will never fill the drive. In fact I will be lucky to reach 3TB of stored data at this rate :stuck_out_tongue:

These results are a bit disappointing so far but its not all doom and gloom. My Egress is also very different from the estimator. My Egress is already close to 4 times the estimate and almost at 0.01 TB.

As a result my earnings have already surpased the 0.03 dollar estimate revenue within two weeks. Even without any repair revenue.

If the estimate payout from the node Dashboard is close to accurate and the load remains the same I will end up with 3 times the revenue from the estimator sheet this month.

So my learnings so far are that if this network behaviour stays the same than I could have just used a 2TB drive, that would have been more than enough and would never be fully used because of the deletes. Because of the high Egress my 16TB node will likely still earn itself back in both hardware and power cost over the next 5 years but as of this point in time I don’t expect it will ever be fully filled. For my second node I will definately be using a much smaller drive.

Without this estimator sheet I probably would not have had these insights this soon so I am really happy it is available. I will be using it to track my progress and to determine the specs for my second node. Thanks again Bright!

1 Like

In all honesty, I dunno if you can draw conclusions after only 2 weeks ^^
Give it a few months, it may get closer to @BrightSilence’s estimator.
If it doesn’t, it will be worth investigating what could be struggling on your setup :slight_smile:


That’s some awesome and extensive feedback. I really appreciate that. But @Pac is essentially right that 2 weeks a too short to make definitive determinations. What I can do for now is add some explanation why you may see differences early on especially. It is a lot harder to predict ingress for nodes during the first months as they are still being vetted. During this time all nodes in vetting receive about 5% of the data. As a result, the amount of data you get is highly dependent on how many nodes are currently being vetted. So this nearly unpredictable thing gets stacked on top of the already unpredictable customer behavior, especially when looking at such a small timeframe. As for the egress, at the moment the estimator assume every piece of data has an equal chance of being downloaded. But we’ve seen that recently uploaded data is usually downloaded at a higher rate than older data. So for younger nodes, it may underestimate egress a little. The same goes for deletes, recently uploaded data had a higher chance to be deleted than older data. The older your node gets, the better it will fit the model.

Even though the estimator splits things per month, it’s not really meant to be a month by month exact path that your node will take. It’s more meant to give you an idea of what your node will earn in say the first year.

Either way, if you have some more details in a few months time, I would be very interested to compare and see where things can be improved.


I’d just add that repair egress isn’t when data leaves your node because you screwed up. It’s actually used to repair a piece because someone else screwed up and it’s paid 10$/TB so it’s quite a good thing.

Also I just spun up some new nodes that show the same behavior as yours, here’s the data for a couple of nodes I spun up just before christmas:

And vetting is painfully slow on half of the satellites because of the very low traffic but I guess they wouldn’t pay much anyways so that’s no big deal.


Thank you for explaining it further @BrightSilence. I suppose there are a lot of people starting with new nodes then and I don’t have the flexibility that @TheMightyGreek has to be able to spin up several small nodes at the same time and expand them gradually. Thank you for the correction on repair egress MightyGreek, I made a dumb assumption based on my current repair egress income.

About the egress in general, I have been wondering if we are getting subsidized by Storj currently or if I am missing something. The Storage costs for data make sense 4$ cost for the customer, 1.5$ in income for us and 2.5$ for Storj. 7$ cost for bandwith, 20$ in egress income for us seems like a bit much. I remember watching a townhall video in which the CEO stated they don’t plan on lowering the compensation at this time but that was a while back. I am wondering if I should take a possible cut in egress income into account when making long term estimates.

1 Like

I suddenly started getting a lot of requests again to be able to edit the estimator. For some reason the sharing settings were changed so nobody could fill in their own data. It’s been fixed now, so if you ran into this issue, please try again and let me know if this pops up again.


@Toyoo Thread from 8 months ago without a clear conclusion so I guess it would be wise to expect lower egress compensation if the amount of egress picks up in the future.

1 Like

Probably. But I think/hope that for the current utilization of the network, there is no way to cut rates.