It’s definately a fuzzy number. Multiple-nodes-on-the-same-storage will overreport free space, and SNOs adding caps to their nodes (when they could easily add more space) will underreport it. Historically we’ve always reported way WAY more than could be filled.
But yeah like zip said if they have a huge number of nodes saying “I have room for more”… that’s probably all the signal they need. Payouts can always be dialed back up if too many nodes start showing as full.
active_nodes":32789,"active_wallets":3862,"disqualified_nodes":81000,"exited_nodes":7742,"full_nodes":5201,"offline_nodes":2169,"suspended_nodes":1253,"total_nodes":123700,"vetted_nodes":40329}}
active nodes - 32789
full nodes- 5201
suspended - 1253
so in selection 32789-5201-1253 = 26335 nodes today can be used in selection for today.
someone know what is next algorithm to select node for data upload so we can run some propability math for /24, /32, no ip filter
“fastest nodes”
Whatever that means, because there’s no way to find out
they get stars from clients, upload send them 54 fastest nodes every uploaded segments, so storj have stats what nodes are fastest. Storj send 80 nodes to start file upload and get back 54 successfully uploaded, this 54 are fastest.
i think @littleskunk can better describe this algorithm, or send us post with description that is valid today
From the upload log, it is now 75 nodes are selected to start, 54 fastest finish, the other 21 are canceled, and 29 pieces are required to reconstruct a piece.
Current rs settings are 29/46/54/75
Lets start with step 2: Satellite sends the uplink an order limit with 75 nodes in it. The order limit is signed by the satellite.
Step 3: Uplink uploads pieces to all 75 nodes. The moment 54 piece uploads are finished it will cancel the rest.
Step 4: Uplink commits the segment back to the satellite. The uplink has to hand in the original order limit with all the 75 nodes on it and at least 54 signed piece hashes. These are signed by the nodes.
Step 5: Satellite keeps a success score for all nodes. Substract the 54 nodes from the original 75 nodes and you get the bad nodes that have been too slow.
And step 1 we skipped at the beginning is selecting 150 nodes from the database and compare the success score in pairs. So node 1 and 2 will get compared. 3 vs 4, 5 vs 6 and so on. That part is the choiceofn node selection. Like a battle each node has to fight vs one other node. You don’t need to have the best score. You just need to have a slighly better score than your 1 oponent you get lined up with.
how you chose 150 nodes from db?
are they some round robin from all nodes or any other?
and when is /24 rule aplied?
Step 6. Should these nodes be placed right at the end, before the next choice? or?
Will there be an updated docker image storjlabs/storagenode with the new payouts per TB?
That way the payout numbers on my dashboard will be correct
Storagenode updates independently from the container image.
I was away on holiday for two weeks and have only just returned. I saw this announcement for the first time yesterday, which is why I am responding only now.
Having now read both the announcement and the subsequent discussion, I find not only the decision itself deeply troubling, but also the way it has been presented to SNOs.
A few weeks ago, I submitted a detailed 36-month restructuring and business proposal:
“The current SNO payout schedule is the floor. There must be no reduction — direct, indirect, temporary, technical or disguised.”
— My restructuring proposal, post #1
This was not merely a demand to “protect my payout.” The proposal was based on the filed cash budget and included customer repricing, fixed-cost limits, debt restructuring, exit financing, concrete products, development deadlines, churn scenarios and mandatory failure triggers. I also offered to contribute development work worth a five-figure amount.
Nobody was obliged to accept that proposal. But its central financial argument deserved a substantive response before implementing exactly the measure it warned against.
My calculation showed that a 10% storage-rate reduction would save approximately $11,400 per month, or $137,000 per year. A 20% storage reduction would save approximately $22,800 per month. Those amounts are not literally zero, but they are relatively small compared with the filed cash gap and total company expenditure.
I later clarified this explicitly:
“Without that analysis, it is a gross saving—not a demonstrated net benefit.”
Storj has still not published the expected monthly gross saving from this new reduction, much less the net result after operator departures, repair traffic, data migration, lost diversity and the potential future cost of rebuilding capacity.
As @jammerdan correctly summarized:
“The SNO payout is not what is killing the company. It is the lack of revenue.”
That remains the fundamental problem. Cutting the infrastructure supplier does not create customers, repair the product strategy, restructure the debt or resolve the central cost structure.
Storj pays SNOs for occupied storage, not for their empty capacity.
If an operator removes 500 TB of empty capacity, Storj’s reported utilization percentage rises because the denominator becomes smaller. But no remaining SNO receives one additional byte of paid storage as a result.
Reducing the storage rate therefore does not reduce the cost of the 66 PB of free capacity. That capacity already costs Storj $0 in storage payouts. The reduction lowers compensation for occupied disks containing customer data.
At the announced average reduction of 18%, remaining operators would need approximately 21.95% more paid volume merely to return to the previous total payout at the same traffic mix:
1 / 0.82 = 1.2195
No such increase is guaranteed. The announcement openly admits this:
“We can’t promise a specific outcome, since it depends on how the network rebalances.”
— Rightsizing announcement, post #1
The saving for Storj is immediate and certain. The possible compensation for SNOs is delayed, uncertain and entirely at their risk.
In my own operation, electricity, servers, networking and IP costs already consume approximately 58–60% of average payout. That excludes replacement hardware, capital recovery, maintenance, labour, taxes and operational risk.
At the announced average impact, an 18% payout reduction consumes roughly 44% of the already incomplete margin remaining after those basic expenses. Further reductions would consume even more.
Telling an operator who can “barely survive” to remain online for another month and hope for additional data is not financial guidance. It asks that operator to continue funding Storj’s infrastructure while Storj tests how much compensation can be removed.
The announcement says:
“We expect this change to prompt some node operators […] to leave the network. That’s an intended part of the process.”
— Rightsizing announcement, post #1
It then states that payouts will continue to be reduced in steps if utilization remains too low.
That is not a stable supplier relationship. It is price discovery through operator attrition: reduce compensation until enough suppliers give up, and possibly increase it again if the network eventually goes too far.
There is no published:
target utilization range;
minimum payout floor;
observation period;
elasticity model;
operator-concentration model;
formula for future adjustments;
required notice period;
or binding mechanism for restoring rates.
The reductions are concrete, dated and immediate. Any later increase is conditional and discretionary.
Storj previously encouraged operators to make long-term infrastructure decisions. Now the message is that no rate can be relied upon because compensation may repeatedly be adjusted until an unknown number of operators leave. That destroys the possibility of responsible capacity planning.
What makes the communication particularly objectionable is that the perception management was subsequently described openly.
“I noticed that I can shape the payout reduction in a way that it feels like 10% even if the payout gets reduce by almost 20%.”
The same post calls this an “exploit” revealed by the discussions and explains that SNOs focus on the storage rate rather than total payout.
That is precisely why prominently presenting a 10% storage reduction while the expected total reduction is almost 20% is manipulative framing.
Those are not my words being imposed on an innocent communication strategy. “Exploit” is the word used by the author of the announcement.
Perhaps this was intended humorously. But when someone who helped shape and communicate the decision describes using operators’ focus on one rate to make the total reduction feel smaller, the reasonable response is not amusement. It is a further loss of trust.
The same applies to the /24 change:
“At this point the /24 rule feels more like a smoke screen and way to effective to not add it to the announcement…”
Again, “smoke screen” is not my characterization. It was stated openly.
The /24 controversy consumed enormous attention while the actual objective remained cost reduction. Including a controversial network-selection change because it effectively distracts people from the payout reduction is the opposite of transparent communication.
/24 to /32 contradicts the stated objectiveStorj says there is too much capacity and wants operators to leave. At the same time, it makes it easier for operators to run many independently selected nodes using IP addresses from the same /24.
That does not necessarily create new disks, independent internet connections or independent failure domains. It can simply create more node identities competing for the same ingress on existing infrastructure.
It also retrospectively devalues investments made by operators who sourced genuine subnet diversity under the previous selection rules. I explicitly proposed a grandfathering and approval path for existing disclosed professional deployments. Instead, the competitive rules are being changed immediately, without an impact analysis or transition.
The announcement even acknowledges that larger operators will find it easier to run more nodes. That can increase effective competition at exactly the moment Storj claims competition for ingress is already excessive.
Another operator summarized the underlying relationship bluntly:
“SNOs, by design, are disposable.”
I would prefer to reject that description. Unfortunately, this announcement makes it difficult.
Full and mature nodes are told that it may be a reasonable time to exit because they cannot grow enough to compensate for future reductions. Operators with free space are told to stay, absorb the cut and hope.
If too few leave, payments will be reduced again. If too many leave, Storj may later offer more to attract replacement capacity.
That treats the operator base as an interchangeable buffer, not as the people who financed, built and maintained the physical infrastructure on which Storj’s product depends.
Operators are asked to help protect customer data through a fast graceful exit while forfeiting their held amount.
As @Pentium100 correctly explained:
“Option 3 is worse for the network, but the only reason to choose option 2 is because Storj said ‘please’.”
Storj wants the operational benefit of a coordinated exit but offers the departing supplier no financial incentive for providing it. Once again, the benefit belongs to Storj and its customers, while the cost is assigned to the SNO.
My position has been consistent throughout this discussion: reducing SNO compensation is not a sustainable or acceptable solution to Storj’s financial problems.
The fact that the first reduction has now already taken effect does not make it economically sound, fair or harmless. Nor does it turn the reduced rates into an acceptable starting point for another sequence of cuts.
I continue to believe that this reduction should not have happened. At the absolute minimum, the announced process of repeatedly reducing payouts until enough operators leave must stop here.
My objection is to:
selecting a relatively low-leverage and poorly targeted saving;
failing to publish its projected net financial and operational impact;
transferring the consequences of insufficient revenue and previous business decisions to the infrastructure suppliers;
deliberately forcing operators out by reducing their compensation;
removing any dependable basis for long-term SNO investment planning;
presenting operator departures as a benefit to the operators who remain;
and openly describing the communication in terms of an “exploit” and a “smoke screen.”
That is why I consider this communication manipulative and, frankly, shameful.
If the actual policy is to squeeze SNO compensation until enough capacity disappears, then say exactly that. Do not package it as improved utilization, better earnings or greaterngpredictability for “nodes that stick around.”
Predictability is precisely what this policy removes.
Storj receives the financial benefit of every reduction immediately. SNOs are expected to carry the loss immediately while continuing to pay for electricity, networking, IP addresses, maintenance and hardware. The suggested compensation—possibly receiving more data after enough other operators have been forced out—is neither immediate nor guaranteed.
This is not a balanced “two-way lever.” The reductions are concrete and already implemented. The possible reversal remains undefined, discretionary and dependent on Storj deciding that it has finally pushed too far.
I offered an alternative based on increasing sustainable revenue, reducing central costs, fixing onboarding and integrations, restructuring liabilities and contributing actual development work. That proposal could have been criticized, modified or rejected on its merits.
Instead, the easiest group to squeeze was selected again.
The message received by SNOs is now very clear:
Your previous investment is sunk. Your future compensation is not reliable. We will continue reducing it until enough of you leave, and if we overshoot, we may later offer more to attract replacement capacity.
That cannot be accepted as the new normal.
The first cut having already taken effect is not an argument for accepting the next one. On the contrary, Storj must now provide a binding payout floor, a meaningful stability period and a clear commitment that SNO compensation will no longer be used as the balancing item for failures elsewhere in the business.
A decentralized infrastructure business cannot indefinitely demand reliability from its operators while offering them no reliability in return.
This is exactly what they said. Seems like AI bot did not get it… 
Its too much LLM usage. This is not going to work. Tell your LLM to make it short and simple.
I understood it. That is exactly what I am criticizing.
I already addressed my use of an LLM in the other thread. Repeating that point here does not address a single argument it’s just a kind of mimimi.
So, short and simple:
Storj intends to reduce SNO compensation until enough operators and capacity leave. I consider that policy exploitative and unsustainable.
I submitted a concrete 36-month alternative intended to avoid further SNO compensation cuts. It has not received a substantive response.
If the proposal cannot work, identify the specific flaws. If the announced policy is better, explain why. Commenting on how the criticism was formulated instead of addressing its substance is not a rebuttal.
I used an AI to poke around Github for this. The bulk of the selection code is at:
It’s written in a very general way, with a node selection YAML configuration file containing the details of how a particular satellite wants to do node selection. So looking at the code gives an idea of what data can be used for node selection, but doesn’t explain what a specific satellite is actually doing for node selection. For that you need the satellite’s node selection yaml file, and the AI couldn’t find anything in the storj repo that generates it.
Wonderful. Thank you so much for that. Much better now.
There is too much free space in the network. We don’t need that for the time beeing but we do need cost reduction to increase the chance for a positive chapter 11 outcome. Right now the target is to keep the network allive and keep paying the nodes in the long run even if it might be at a lower payout rate.
There have been mistakes in that proposal but I don’t have the time to argue against an LLM. If you keep it nice and simple like now it is a lot easier to read and respond to it.
So:
Did I miss anything? I didn’t even use any tokens 
You want no LLM? Here it is in German:
Ihr habt nicht genügend zahlende Kundennachfrage, um die von den SNOs bereitgestellte Kapazität auszulasten. Das Netzwerk ist deshalb nur ungefähr zur Hälfte ausgelastet und hat laut eurer eigenen Aussage rund 66 PB freien Speicher. Dieses Nachfrageproblem haben nicht die SNOs verursacht. Trotzdem sollen jetzt ausgerechnet sie dafür bezahlen. Die Vergütung war schon vorher gemessen an Hardwarekosten, Strom, Internetanschlüssen, IP-Adressen, Wartung, Ausfallrisiko und jahrelanger Arbeit sehr niedrig. Trotzdem habt ihr zum 1. September die Vergütung für belegten Speicher von 1,50 auf 1,35 Dollar pro TB und Monat und die Egress-Vergütung von 2 auf 1 Dollar pro TB gekürzt. Das Perverse ist, dass die 66PB freier Speicher als Zeichen gesehen wird, dass es den SNO’s zu gut geht, statt froh darüber zu sein, dass man Puffer hat, der euch aktuell nichts kostet.
Das hier ist kein Fakt! Das ist einfach nur dahergeredet. Es gibt keinerlei Beleg dafür.
Ihr selbst beziffert die durchschnittliche Gesamtkürzung auf ungefähr 18 Prozent. Gleichzeitig sagt ihr ganz offen, dass diese Kürzung Betreiber zum Aufgeben bringen soll und dass ihr die Vergütung weiter reduzieren werdet, falls danach noch immer zu viel freier Speicher vorhanden ist. Sollten zu viele Betreiber abspringen, wollt ihr die Vergütung eben wieder erhöhen und hoffen, dass neue Kapazität zurückkommt. Damit behandelt ihr SNOs und ihre Investitionen wie einen beliebig ein- und ausschaltbaren Regler. Festplatten, Server, Internetverträge, IP-Adressen, Finanzierungskosten und jahrelang aufgebaute Infrastruktur lassen sich aber nicht einfach abschalten und später wieder kostenlos zurückholen. Für Betreiber gibt es unter diesem Modell keinerlei verlässliche Kalkulationsgrundlage mehr, weil die Vergütung so lange gesenkt werden kann, bis genügend andere Betreiber aufgeben. Volle Nodes können die Kürzungen überhaupt nicht durch bessere Auslastung ausgleichen. Betreiber mit freiem Speicher können lediglich darauf hoffen, irgendwann mehr Daten zu bekommen, ohne jede Garantie, dass dieser Effekt die Kürzungen tatsächlich ausgleicht. Trotzdem verkauft ihr diesen gezielten wirtschaftlichen Druck mit Formulierungen wie „healthier equilibrium“, „better fill rates“, „more predictable earnings“ und ausgerechnet „rightsizing“. Ein beschönigender Name ändert nichts daran, dass Betreiber so lange schlechter bezahlt werden sollen, bis genug von ihnen wirtschaftlich verdrängt wurden. Wer deshalb aussteigen möchte, soll anschließend noch 30 Tage lang einen Graceful Exit durchführen, um eure Kundendaten zu schützen. Wer schneller gehen möchte, soll auf seinen einbehaltenen Payout verzichten, obwohl auch dieser Fast Exit in erster Linie Storj und dessen Kunden schützt. Parallel schafft ihr die bisherige /24-Begrenzung praktisch ab und wechselt auf /32. Dadurch wird es für große Betreiber leichter, sehr viele Nodes innerhalb derselben Infrastruktur und derselben Netze zu betreiben, während bestehende Betreiber teilweise erhebliche Kosten auf sich genommen haben, um Nodes über viele unterschiedliche /24-Subnetze zu verteilen. Diese Investitionen werden nachträglich entwertet und der Konkurrenzdruck kann noch weiter steigen, während ihr gleichzeitig behauptet, geringere Konkurrenz werde die Kürzungen ausgleichen. Ich habe vor dieser Entscheidung einen detaillierten 36-Monats-Plan vorgelegt, der eine Restrukturierung ohne weitere Kürzungen der SNO-Vergütung ermöglichen sollte: How to Survive - without reducing SNO compensation. Darauf habe ich bis heute keine sachliche Antwort erhalten. Statt zu erklären, welche konkreten Annahmen oder Berechnungen meines Vorschlags falsch sein sollen, wird wiederholt über meine Nutzung eines LLM diskutiert. Ob ich mir bei der Formulierung eines englischen Textes helfen lasse, ändert weder die Zahlen noch eure angekündigte Politik noch meine tatsächlichen Kosten und Erfahrungen als SNO. Wenn mein Vorschlag nicht funktionieren kann, dann nennt die konkreten sachlichen Gründe. Wenn meine Kritik falsch ist, dann widerlegt sie inhaltlich. Immer wieder nur „LLM“ zu schreiben, beantwortet kein einziges Argument.
LLMs are fine. It’s just too many sentences for too few thoughts. Are you being paid by word?
Of course increasing customer sales should be part of any recovery plan. But.. that’s not something SNOs can help with. SNOs are an expense: to be trimmed.
They are.
There’s an enormous amount of unused space out there. As we’ve seen from running the network for years: people jump at the chance to offset their costs.
Why? You, like I… are a random dude on the Internet. Storj has months to restructure: a 36-month plan is 30-months too long. I’m sure they appreciate your ideas. As do I. But it’s not something they need to respond to - their battles are behind-the-scenes with creditors and the court.
I hope they survive. 
At least this is a substantive disagreement.
SNO payouts are the direct supplier cost of Storj’s product, not optional overhead. Capacity may look like a switch on a chart; hardware, contracts, reliability and trust are not.
And 36 months is the operating horizon, not the restructuring deadline. The plan contains actions for days 0–7, 8–30 and 31–90, with failure triggers at days 60 and 90 and month 6.
Storj is not obligated to respond. But dismissing a plan without reading it is not a substantive rebuttal.
Those 66 PB of free capacity represent operator-funded capital that costs Storj no storage payout until it is used. This policy is now deliberately destroying that valuable growth reserve.