Earnings calculator (Update 2023-12-05: v13.1.0 - Now with support for different payouts per satellite - Detailed earnings info and health status of your node, including vetting progress)

Perfect, you’ve solved it, now run it correctly.

If I delete the copied files, I’ll have the same problem again when I run it, right? Thanks for your help.

If you want to keep running on copies, you have to stop the node every time you make the copy. I’m not sure if that answers your question as I didn’t entirely understand what you were asking. Are you running a GUI node?

Yes, I’m running the node in GUI.

What I was saying is that if every time I run the program, the node needs to be stopped.

In that case, no. You can skip the copying altogether and run the script with:

earnings.py F:\STORJ\

Copying is only needed for docker nodes on windows and macos. If you don’t copy, but use the original location, the script will be aware of what’s in the .db-wal and .db-shm files as well and display real time up to date information. This can be done with the node running.

Thank you. It was mostly for security, in case the database was corrupted by reading the original files directly.

I understand, but yes, if you want to make the copy, you have to stop the node or you would be looking at outdated data. Usually that won’t cause errors, but you’d see some data that wasn’t updated since the last restart of the node.

1 Like

I have tried searching for this answer, but to no avail. I love that suspension % is indicated, as you can see running this script on my new two week old node shows 0.1%, 3.3% and 2.4% Susp.

My question is do these scores go down to 0% over time if there are no audit problems? Any idea what the time range is such as over a 30 day period?

Yes, the way this score works is similar to the audit score that disqualifies your node. It will go down with successful audits. But it’s really hard to give you a specific time frame for that because it depends on the number of audits the node gets. Especially on a new node that number could be very low, so it might take a while. Luckily these numbers are very low and nowhere near suspension yet. So as long as they’re not going up, I wouldn’t worry about them. Your node likely ran into the locked used serials db prior to the update. But if the numbers do go up, I advise you to look for failed audits in the log. That should give you an idea of why the scores aren’t a perfect 0.

1 Like

FYI - in the last 16 hours my current suspension rates are: 0.1%, 2.4% and 1.5% Susp.

So the numbers are trending in the right direction.

1 Like

Earnings calculator is really nice. Is it possible to include information of disk space used by each satellite.

I would like to ask to make it consistent with dashboard. At the moment script shows 0.0% and dashboard 100%, it’s confusing.

The problem with making it consistent with the dashboard is that the dashboard measures successful audits where 100% is best, while the suspension and DQ percentages are tracking how close you are to being suspended or DQ’d on a satellite. At least that’s how I see it. They’re two separate metrics so there’s not really a way to reliably make them consistent other than breaking the whole purpose for the numbers to exist in the first place. That’s just my opinion though.


@vedalken254 mostly explained it. These scores don’t require SNOs to know specific threshold and also make the distinction of names much more clear. Audit score and unknown audit score are pretty meaningless to SNOs. But getting DQ’ed or suspended at 100% is instantly clear. I’d love to stick with the same numbers but couldn’t really make it clear in the limited amount of space I had. So I went in a different direction to make it as easy as possible to understand.


Why not change the dashboard? :smiley: DQ at 60% makes everything below irrelevant anyway. And there’s no suspension metric.

Ultimately they are just different metrics, dashboard shows audit value, earnings.py shows DQ and suspension “progress”.
For me that’s not confusing. It’s like having a uptime metric and a downtime metric. As long as it’s labeled clearly, it should be fine imho and not too confusing.

(guess I just repeated what vedalken256 explained lol, should go to bed…)

Can you suggest a labeling for dashboard?
By the way, it shows an audit score, not the audit checks, but still in percents

Honestly, I could imagine just changing it to “Node health” with 3 categories: uptime, audit score, suspension score. Uptime is easy to understand and 0-100% makes sense. For Audit score the number is basically irrelevant, it could still stay a number in the API but on the dashboard it could just be replaced by an arrow to indicate if the audit score is rising or falling. Same for the suspension score (although the name might be misleading because a high suspension score sounds like a bad thing…).

That was just a quick idea, I’m still not sure what I think would be best because there’s already lots of confusion about suspension and dq and both those modes get triggered from audits but from different kinds of audit errors, making the “audit score” pretty strange and confusing anyway, additionally the threshold of 60% audit score is just a number that doesn’t mean anything to any SNO so could just be ommitted or changed to a range from 0-100% so it has a real meaning to the average SNO but it would still not say much because it’s actually just a DQ score while the suspension score is not shown.

This is just a very quick mock up, but perhaps something like this?


I’m sure your designers could do a better job. Since suspension and disqualification also apply to the future uptime measurement system, these bars could represent how close you are to either in a similar panel for uptime as well. They could also be represented as a timeline there.


Thanks @BrightSilence, I was thinking about something like that. Those bars are a nice visualization.

1 Like

@BrightSilence, quick question, more just out of curiosity.

For the “Estimated total by end of month” calculation, I assume this part of the script is simply calculating the average per a time (I think hour based on what I understand in the script) and then extrapolating out for the entire month? So simple example would be if you ran the script at the exact moment of halfway through the month, then your total value would be “X” and your estimated total by end of month would be “2X”?

There’s not any special predictive or assumptions built in, right?

Correct. Predictive modeling wouldn’t really make sense in this case anyway as previous traffic patterns can’t predict future traffic patterns. So it just uses average values over the course of the month so far and shows what the entire month would be worth if that average remains the same.