These tiers are available only for TrueNAS customers and only on projects, created after November 1, 2025 but before July 1, 2026.
I think @Roxor is more close, it’s done via choiceofn rule, just the customer doesn’t select between plans:
Haha, ok so make it a feature then… this does not compute.
2 cents,
Julio
How to verify the claim, that this particular node has SSD, as advertised?
Or do you mean just use choiceofn with higher number for the “fast plan”?
Leadership has signaled that they want to get court approval on paying the July payout first before making any adjustments.
One more month for us to argue about rates! 
I would say it should just be based on the actual observed performance of the node. Not necessarily strict SSD vs HDD - a node with an old Atom CPU and a SATA-1 SSD might still be slower than a node with a good CPU, RAIDed hard drives, and a lot of RAM for caching.
We do not measure it, we have only a success rate - how often the node wins the race. And choiceofn rule selects the best from n with better success rate.
when will be information about price reduction decisions and Jully payouts, approximately?
I can only guess. I belive we haven’t generated the payout list yet. After that I would guess 2 more days to get the court approval.
I’d love to be at the court when the judge asks “You want to send what to who?” “Tokens?” “Russians and Germans?” “Mostly? You don’t even know?”
On US court almost everything is public. So I assume you can join the zoom conference tomorrow.
Which zoom conference tomorrow? Do you have the details?
Large-scale operator datapoint and an alternative to cutting SNO payouts
I operate a large-scale setup.
Based on my average payouts over the last 12 months, my recurring electricity, server, network and IP-related costs alone amount to approximately 58–60% of my current payout.
These are not optional IP addresses or servers that can simply be cancelled after a payout reduction. Many of the underlying contracts have remaining terms of at least another year.
The servers also fulfil different customer-related, operational and redundancy purposes. However, much of this distributed infrastructure would not continue to exist in its current form without Storj. It is operated in this particular configuration because Storj makes the additional locations economically viable and because the architecture was designed around the existing /24 subnet restriction.
Without Storj, some of these systems would eventually be consolidated or decommissioned. The contractual costs would nevertheless continue for a substantial period after any immediate payout reduction.
The 58–60% figure does not include replacement hardware, taxes, maintenance, labour, capital recovery or existing financial obligations. A theoretical electricity-and-infrastructure break-even point must therefore not be confused with a sustainable operating level.
My practical thresholds are:
-
A permanent reduction of approximately 10% might be survivable, but it would remove most of the remaining safety margin.
-
A permanent reduction of 15–20% would not be sustainable.
-
A temporary reduction of 15–20% might be absorbed for one or two months, but only with a binding end date and a reliable payment schedule.
-
A reduction of 25–30%, or repeated payment delays, would force me to begin reducing capacity.
-
A missed payment is substantially more damaging than a modest and predictable reduction because all contractual costs continue regardless.
The currently discussed 20% placeholder would therefore not be viable as a permanent reduction.
However, I also fundamentally disagree with treating SNO payouts as the first or primary restructuring lever.
Storage Node Operators provide the physical infrastructure on which the product depends. SNO payouts are not an optional community programme. They are a direct cost of delivering the service that Storj sells to its customers. Weakening the infrastructure layer risks capacity loss, lower geographic diversity, increased repair requirements and reduced confidence among both operators and customers.
Historical Storj token-flow reports appeared to show that payments to node operators were only a relatively small part of broader token outflows and operating expenditure. Those reports were not a complete audited profit-and-loss statement, but they raise an obvious question: how much could be saved in payroll, management, external service providers, administration and other internal expenses before cutting the infrastructure providers?
Before reducing SNO payouts by even one cent, I believe Storj should pursue the following measures:
- Secure sufficient financing immediately
Storj should seek sufficient multi-million-dollar DIP, bridge or acquisition financing to provide a real restructuring runway. A few weeks of emergency liquidity will not solve a structural problem. The company needs enough time to complete the restructuring, maintain reliable payments and build customer revenue without destabilising the network.
- Reduce internal costs first
Every internal department, management position, contractor agreement and external service-provider expense should be reviewed.
Roles that are not directly contributing to network reliability, restructuring, compliance, customer retention or new revenue should be consolidated or eliminated. Repetitive work in administration, reporting, first-level support, documentation, internal analysis and routine software maintenance should be automated with modern AI tools wherever this can be done safely.
The objective should be a smaller and highly focused organisation centred on engineering, operations, sales and customer acquisition. It makes little sense to preserve the full internal cost structure by transferring the financial distress to the operators providing the actual storage infrastructure.
- Increase customer-side prices where necessary
Where existing customer contracts do not cover the full cost of storage, bandwidth, support and operations, customer pricing should be increased.
This could include higher base prices, appropriate minimum monthly charges, paid support tiers, managed-service pricing and premium charges for workloads requiring additional performance or operational assistance.
A product cannot become sustainable by continuously reducing payments to its suppliers while keeping economically insufficient customer pricing unchanged.
- Create a community integration programme
Storj should ask the community to help build simple, standardised integrations that make the service accessible to ordinary customers rather than only to people already familiar with S3-compatible object storage.
Storj could publish integration specifications, reference implementations, documentation and funded bounties for integrations such as:
-
WordPress and WooCommerce backup
-
cPanel and Plesk backup
-
Synology and QNAP
-
Plex/Plexamp integration
-
Nextcloud
-
TrueNAS and Proxmox
-
common desktop and server backup applications
-
straightforward integrations for hosting providers and managed-service companies
These integrations should be designed so that a normal customer can select Storj as a storage or backup destination without manually configuring gateways, command-line tools or complex S3 parameters.
Community developers could receive fixed bounties, ongoing maintenance payments or a revenue share for customers acquired through their integrations. This would convert the existing technical community into an additional product-development and sales channel.
- Reward reliability instead of reducing the base payout
Rather than lowering every operator’s payout, Storj should consider stronger incentives for long-term reliability, useful geographic distribution, demonstrated performance and predictable committed capacity.
For large or commercially relevant operators, Storj could offer individual agreements that provide planning security in exchange for uptime, capacity and transition commitments.
Changing or removing the /24 restriction could improve operating efficiency over the longer term. It would not create immediate savings for operators whose contracts continue for another year. Any policy change would therefore require a transition period and could not justify an immediate payout reduction.
My position is clear: I would not cut a single cent from the current base SNO payout before exhausting financing, internal cost reductions, automation, customer price adjustments and community-led customer acquisition.
If the business can be stabilised, payouts should eventually be increased or supplemented with reliability incentives—not repeatedly reduced.
My setup holds a material amount of customer data. A forced capacity reduction would therefore not be insignificant for the network. I am willing to provide additional normalised financial and operational information privately through a genuinely confidential process.
You don’t need Chapter 11 to nudge payouts down. So I think what you’re asking for is happening (reducing internal costs, layoffs, bridge financing, and renegotiation legacy debts). That’s the big stuff.
And, even though it’s small, people have been discussing payout changes here.
In the end: SNOs are providing way more unused space than needed, and have been for years. The network can afford to lose some of it.
I may not have expressed this clearly enough, but I was not arguing that Storj needs Chapter 11 in order to reduce payouts.
I mentioned DIP, bridge or acquisition financing as possible ways of securing sufficient restructuring liquidity. DIP financing would obviously be relevant only in a Chapter 11 scenario. Bridge or acquisition financing would not require Chapter 11.
The broader point is that Storj needs enough financing runway to restructure without destabilising the network through missed payments, repeated delays or rushed permanent payout reductions.
If internal costs are already being reduced, layoffs are taking place, bridge financing is being pursued and legacy obligations are being renegotiated, that is positive and largely consistent with what I proposed. But before permanently transferring part of the remaining financial burden to SNOs, it would still be useful to understand how much those measures are expected to save and whether a structural deficit remains after they have been implemented.
I also agree that the network currently has more unused capacity than it needs. However, that does not mean a broad payout reduction would only remove a few harmless petabytes of empty space.
There are two separate risks.
Large operators can also shut down or reduce capacity because they have much larger absolute expenses, contractual obligations, hardware costs and financing commitments. Like in my case. Economies of scale do not make a permanent 20% revenue reduction irrelevant. For a large operator, that reduction can amount to hundreds or even thousands of dollars per month.
If several large operators reduce capacity at the same time, Storj may lose multiple petabytes very quickly. This could include substantial amounts of used storage, not merely empty capacity, creating serious migration, repair and operational risks.
The actual concentration of storage among large operators is not publicly known. It is therefore possible that a relatively small number of large-scale operators collectively provide a very substantial share of the network—potentially even 70–80%. Without transparent data on operator concentration, Storj cannot safely assume that capacity reductions would occur gradually or remain isolated. A simultaneous reaction by only a handful of major operators could affect a significant portion of the entire network.
Smaller operators face a different problem. Their absolute costs are lower, but they often have less ability to absorb losses and less reason to continue maintaining a node when the payout no longer justifies the cost and effort.
If many smaller operators leave, the network may retain sufficient headline capacity while losing geographic distribution, independent locations, operator diversity and resilience.
So both effects can happen simultaneously:
Large operators leaving can cause a major capacity and migration problem.
Small operators leaving can weaken geographic distribution, decentralisation and network resilience.
A general payout reduction cannot control which operators leave. It does not selectively remove unused capacity from oversupplied regions. It removes whichever operators can no longer economically justify remaining, regardless of whether their nodes are full, reliable, geographically valuable or operationally important.
That is why “the network can afford to lose some unused space” is not, by itself, a sufficient argument for a broad permanent payout reduction.
A broad payout cut is not targeted capacity management. It risks losing both significant amounts of useful capacity and the smaller operators that provide geographic diversity and resilience.
All of what you said is true: and it’s encouraging to see the arguments are consistent. Because it was the same concerns raised when the minimum-payout-of-$5 was removed.
And again when egress dropped from $20 to $10.
And repeated when egress lowered from $10 to $2.
And now… here we are… talking through the impact of a fourth payout drop. And each time we also have consistently heard that some SNOs would leave if the change happens, because the economics no longer work for them. That’s OK. It’s not unexpected.
I understand if Storj makes a large amount of small changes in effort to stabilize the company: in hopes those small changes add up. Shaving payouts a bit could be one of those changes…
The restructuring itself adds another layer of risk.
Even without an announced payout reduction, the perceived possibility of delayed payments, partial payments or a complete payment failure gives operators a rational reason to reduce their exposure now rather than wait until a payment is actually missed.
That concern is particularly relevant today. On August 4, the bankruptcy court is scheduled to hear Storj’s “First Day Pleadings,” including a motion to authorise post-petition financing and the use of cash collateral.
The financing motion requests interim authorisation to obtain new financing and use cash collateral while a later final hearing is scheduled. This does not mean that a payment failure is certain. However, it confirms that Storj’s immediate access to operating liquidity and its ability to fund ongoing obligations are material issues currently subject to financing arrangements, a court-approved budget and judicial approval.
Large operators have substantial recurring electricity, connectivity, server and contractual costs. They cannot simply continue operating indefinitely on the assumption that financing will be approved and that payment will eventually arrive.
Until the outcome of the hearing, the available operating runway and the treatment of SNO payouts are made clear, operators cannot reasonably treat future payments as guaranteed.
The longer Storj leaves payment continuity and future payout levels uncertain, the greater the risk that operators begin consolidating infrastructure, rejecting additional costs, selling hardware or shutting down nodes as a precaution.
When that uncertainty is combined with reduced payout rates, exiting is no longer an emotional reaction. It becomes a rational economic decision.
Operators cannot reasonably continue consuming electricity, bandwidth and hardware lifetime for one or several months while accepting both a lower expected return and the possibility that payment may be delayed, reduced further or not arrive at all.
Continuing under those conditions would mean financing Storj’s operations from the operators’ own balance sheets while carrying nearly all of the downside risk.
For that reason, today’s hearing and its outcome are critically important.
A clear approval of sufficient post-petition financing, together with transparent confirmation that ongoing SNO obligations are included in the operating budget, could restore at least some confidence.
An unclear, insufficient or unsuccessful financing outcome would have the opposite effect and could make immediate capacity reductions the economically responsible choice for many operators.
Storj is therefore no longer dealing only with the potential reaction to a future payout reduction. The Chapter 11 filing, the pending financing decision and the uncertainty surrounding future payments may already be increasing operator attrition.
A payout cut introduced on top of that uncertainty could accelerate several independent operators towards the same decision at approximately the same time.
The fact that the network survived previous changes does not establish that another reduction is safe.
These changes are cumulative. The economic margin removed during one round does not magically return before the next one.
Removing the $5 minimum payout primarily changed payment timing and transaction economics. Reducing egress from $20 to $10 and then from $10 to $2 removed a substantial source of variable revenue.
A further reduction now would affect operators whose margins have already absorbed all of those previous changes.
Each previous reduction may also have created a selection effect. Operators with the weakest economics may already have left, while those who remained consumed part of their remaining safety margin.
That does not mean the remaining operators can absorb reductions indefinitely. It may mean that a larger share of them is now much closer to its economic limit.
More importantly, the present situation is fundamentally different.
This is no longer merely a discussion about accepting less profit from an otherwise stable counterparty. Storj is now operating under Chapter 11, with its immediate access to operating liquidity subject to a financing agreement, an approved budget and court authorisation.
Large-scale operators do not merely contribute unused space on machines that would remain online anyway.
Some operate dedicated infrastructure with substantial recurring electricity, connectivity, server, maintenance and contractual costs. Those expenses continue whether Storj pays on time, pays late, reduces the amount or ultimately fails to pay.
When a payout reduction is combined with uncertainty over payment continuity, an operator is being asked to accept all of the following simultaneously:
-
lower expected revenue;
-
continuing fixed operating costs;
-
the possibility of delayed payment;
-
the possibility of partial payment;
-
and the possibility that no payment will arrive at all.
Under those conditions, leaving is not simply a reaction to reduced profitability.
It can become the only economically responsible way to avoid financing Storj’s operations from the operator’s own balance sheet and then being left with one or several months of electricity, connectivity and infrastructure costs.
That distinction is essential.
An operator using equipment that would remain online regardless of Storj may be able to tolerate a lower return for some time.
An operation with dedicated infrastructure, recurring contractual obligations and material electricity costs cannot indefinitely operate with negative or highly uncertain cash flow.
Once the expected return from continuing no longer justifies the unavoidable operating exposure, reducing capacity or shutting down becomes rational risk management rather than an emotional response to lower profitability.
It is also not necessarily “OK” from the network’s perspective.
A general payout reduction cannot control which operators leave. It does not selectively remove unused capacity from oversupplied regions. It removes whichever operators can no longer economically justify remaining, regardless of whether their nodes are full, reliable, geographically valuable or operationally important.
If several large operators reach that conclusion at approximately the same time, Storj may lose multiple petabytes very quickly.
That could include substantial amounts of used storage, not merely empty capacity, creating migration, repair and operational risks.
The actual concentration of used data among large operators is not publicly known. Storj should therefore not assume that operator departures would be gradual, evenly distributed or operationally insignificant.
A relatively small number of large-scale operators may collectively hold a substantial share of the network’s used storage.
Without anonymised concentration data showing how much stored data is controlled by the largest 10, 25 or 50 independent operators, neither Storj nor the community can reliably assess the consequences of several large operators leaving simultaneously.
Public node counts are not sufficient for this purpose because one operator may control many nodes and substantial amounts of used data.
Storj should publish the relevant concentration ranges before treating the departure of additional operators as an acceptable and predictable consequence.
This is also why the outcome of today’s court hearing matters so much.
According to the public bankruptcy docket, Storj filed Docket 14 on August 2: a motion seeking authorisation for post-petition financing and the use of cash collateral, together with an attached declaration, financing agreement and operating budget.
The existence of that motion does not, by itself, demonstrate that Storj has sufficient funding.
The freely accessible docket listing identifies an attached financing agreement and budget but does not disclose their substantive terms.
It does not publicly show the total facility amount, the identity of the proposed lender, the interest rate, maturity date, security package, funding conditions or the amount allocated to SNO payouts.
Storj Labs Inc. is identified as the debtor requesting the authority, but the financing counterparty cannot be confirmed from the freely accessible docket listing alone.
Court approval would allow Storj to obtain financing and use cash collateral under the conditions of the agreement and approved budget.
It would not automatically prove that the financing is large enough to fund several months of operation, complete the restructuring or guarantee all current and future SNO payments.
Operators therefore need prompt disclosure after the hearing of:
-
the total financing amount;
-
the identity of the lender and its relationship to Storj or Inveniam;
-
the available operating runway;
-
the interest rate, fees, maturity and security granted;
-
the approved weekly or monthly operating budget;
-
the permitted variance from that budget;
-
and explicit confirmation of whether the complete July payout and future SNO payouts are funded.
A clear approval of adequate financing, with SNO obligations expressly included in the operating budget, could restore some confidence.
A small, conditional or short-term facility—or continued uncertainty about whether node payments are covered—would not solve the economic risk described above.
In that case, precautionary capacity reductions would remain a rational response even before the first payment is actually missed.
It is one of the last costs that is now getting looked at.
Already done and still ongoing.
Done and everything that is not needed to keep the network running has been canceled.
Team is down to a handful of developers mostly. Just the bare minimum to keep the service running and also preserve the knowledge that would allow further development if we are lucky enough to get there.
Done: Important Update: Upcoming Storj Customer Pricing Adjustments and SNO Impact
I don’t know the entire list out of my head but I believe most of that is already available. At least TrueNas and Nextcloud to name 2.
That is not possible. Most of these tools are using S3 for a lot of other services and its easy for them to just put down storj S3 credentials. We can’t force them to use our native integration instead. Well technically we could maybe force them but the most likely outcome is that they just drop storj support because implementing the native integration would be a lot more time consuming than reusing and maintaining the already existing S3 support.
Already in place. There are special contracts in place for example with TrueNAS. In the early days it was some kind of bounty. But it was missing some transparency. The new way to handle it is a special RCS pricing. We give out partner a discount and they can go and sell it to their customers and make some profit out of it. So it works like a revenue share. We can even setup whitelabel satellites including a whitelabel admin UI that give the partner a lot more visibilty into their customer usage.
Long story short. Since most of your list is already in place its now time to talk about the SNO payout rate. It is one of the last cost reductions that is on the list. There are a few other cost reductions that are also getting hunt down but I hope you get the message. Low hanging fruites are all done. Time to get to the more painful topics…
You can send them over to me or put your numbers down into the calculator I provided. The calculator will run the math in your browser so what ever you type in doesn’t leave your system. There is a output box for the final result that should take care of your privacy.
Again you can also send me a personal message if you don’t like the calculator.
That is… quite the update. So…
- Would reducing payouts reduce SNOs/capacity? Yes.
- Does anyone know how many nodes would leave? No.
- Are SNOs interested in Chapter 11 details: to have some idea of what will happen over the next 6 months? Yes.
Is that a fair summary?
I’m worried that Storj doesn’t reorganize successfully. I’m not worried about the network, or about node loss: if the company emerges from Chapter 11 in 6-12 months the network will be fine.
Sorry I can’t keep up with this. You are either an incredible fast writer. Maybe english is your native language. Or you are using some AI assitance that generates text for you. If so could you please ask that AI to shorten it?
Anyway I will try my very best to still answer the important part and if you believe I overlooked something just follow up with a question.
What is the alternative? Your argument is that we are sailing through rough water and therefor shouln’t make it worse. That is correct but there is a wrong assumption beneeth that. It is not garanteed that the service will continue without a payout reduction. We are talking about ways to improve the chances that the service will continue even if it means that some storagenodes will have to leave the network.
I can say that the storagenode payouts are included in operating budget. A payout reduction is already factored in. There are also other options like reducing the storage expansion factor that can lower the payout without having to lower the rate. So we might end up combining a few things to get there. Short term impact on your payout would still be the same. It only changes the math for the nodes long term.