Why we’re doing this
The Storj network is currently sitting at roughly 50% utilization, with about 66 PB of free space available after deduplication. At the same time, many nodes that are operating correctly — following the rules, offering reliable uptime and bandwidth — are hitting a ceiling on how much data they can actually fill, because there simply isn’t enough demand relative to the amount of storage capacity currently on the network.
That’s not a healthy equilibrium. A network with too much idle capacity means individual operators earn less than they could, even though the network as a whole is paying out the same total amount. Our goal is to bring supply and demand back into balance so that the storage capacity being provided matches what the network actually needs — which should mean better fill rates and more predictable earnings for nodes that stick around.
A quick note on leaving, if it comes to that
If this change means it’s time for your node to exit the network, we ask one thing: please leave via graceful exit (GE), not an abrupt shutdown. It protects customer data during the transition and keeps things stable for the SNOs who stay. We also offer a faster shutdown option for operators who want out immediately — but choosing it means forfeiting your held-back payout. Details further down, and sign-up is here: Fast Exit via Graceful Exit — Sign Up Here
What’s changing
Effective September 1st, we’re adjusting payout rates as a first step:
| Rate | Current | New | Change |
|---|---|---|---|
| Used space (storage) | $1.50/TB/month | $1.35/TB/month | -10% |
| Egress (bandwidth) | $2.00/TB | $1.00/TB | -50% |
Combined, this represents an estimated 18% reduction in total payout at current average traffic patterns. That’s an average across the network, not a guarantee for any individual node — actual impact will depend on your node’s specific mix of storage vs. egress traffic.
What we expect to happen
We expect this change to prompt some node operators — particularly those running at the margin — to leave the network. That’s an intended part of the process, not a side effect to avoid. As total network capacity decreases, remaining nodes should see higher utilization and better fill rates, which helps offset the lower per-TB rate.
This is the first step, not the only one. We’ll continue monitoring network-wide utilization and adjust rates incrementally until we reach a healthier target range. This is explicitly a two-way lever going forward:
- If utilization stays too low, we’ll continue reducing payout rates in steps to right-size capacity.
- If utilization gets too high (nodes full, network struggling to onboard new data, or churn overshooting), we’ll increase payout rates again to attract more storage back to the network.
The intent is to actively manage network capacity to match demand over time, rather than leave rates static regardless of network health.
What this means for you
- If your node economics work at a 15-20% lower payout rate, no action is needed — you should see improved utilization over time as the network adjusts.
- If your node can barely survive this reduction but still has significant free space, it’s worth staying and re-running the numbers next month. The percentage rate is only half the story — what matters is total payout, and that depends on both rate and volume. As utilization rises, nodes with room to grow should see more data offered to them, which can offset a lower per-TB rate. We can’t promise a specific outcome, since it depends on how the network rebalances, but a node with spare capacity is in a much better position to benefit from this than a full one.
- If your node is already full and can’t absorb further payout reductions, it’s a reasonable time to exit. A full node with no more room to grow can’t benefit from the utilization gains this change is meant to produce, so if the new rate doesn’t work for you today, it likely won’t work better later.
- We’ll continue to publish utilization data and rate updates so operators can make informed decisions about capacity planning.
If you decide to exit: please use graceful exit
If you do decide to leave the network, please use graceful exit (GE) rather than simply shutting your node down. This matters for customer data durability — an ungraceful exit forces the network to rebuild redundancy from remaining nodes under worse conditions, which is a risk we’d rather not create for customers, and which ultimately makes staying on the network less stable for everyone else’s nodes too.
We know the full 30-day graceful exit process feels like a long time to wait when you’ve already decided to leave. So we’re offering a second option:
- Standard GE (30 days): Run the full graceful exit process and receive your held-back payout as usual.
- Fast exit: Start GE, and a few days in we’ll check the network’s segment health report. Once it confirms it’s safe, we’ll tell you it’s fine to shut the node down right away — well before the 30-day mark. In exchange, you forfeit your held-back payout.
This fast option is for operators who want to be fully off the network as quickly as possible and are willing to trade the held-back amount for that speed, while still guaranteeing there’s no durability risk to customer data or disruption to the remaining SNOs. If you’d rather collect your held-back payout, stick with the standard 30-day GE.
To sign up for the fast exit option, post in this thread: Fast Exit via Graceful Exit — Sign Up Here
Subnet filter change: /24 → /32
Alongside the payout adjustment, we’re changing how node diversity is calculated: the network will now treat each individual IP (/32) as its own subnet for selection purposes, instead of grouping an entire /24 block together.
Why: The /24 grouping was meant to prevent concentration risk — making sure customer data doesn’t end up overly reliant on nodes that share infrastructure, since a single outage or failure could take out many “diverse” pieces at once. In practice, it hasn’t been doing that job well. Operators running nodes behind proxies or multiple IPs can and do get around a /24-level restriction, while it simultaneously penalizes honest operators who run multiple nodes — one per HDD, as we recommend — out of a single location or data center that happens to share a /24 block. Those operators were being capped for something that wasn’t actually stopping the behavior the rule was designed to prevent.
There’s also a network-size factor. The /24 restriction mattered much more in the network’s early days, when the total pool of nodes was small and any grouping rule had an outsized effect on how diverse a segment’s node selection actually was. With a much larger and more geographically distributed pool of nodes today, ordinary node selection already spreads pieces across a wide range of independent networks on its own — the /24 rule is doing less work than it used to, on top of not doing that work particularly well to begin with.
We’re not going to pretend this closes every loophole — it doesn’t fully solve concentration risk, and it does mean operators with efficient multi-node setups (including larger operators) will find it easier to run more nodes without being throttled by the old grouping. But keeping a rule that penalizes honest operators while barely inconveniencing the operators it was meant to stop isn’t a good trade either. We’d rather be straightforward about that than defend a restriction that isn’t doing what it was designed to do.
We’ll keep monitoring actual concentration risk on the network and may revisit this if it becomes a real durability concern rather than a theoretical one.
We know payout changes are never welcome news for operators, and we don’t take adjusting them lightly. But sustained 50% utilization with unfillable nodes isn’t sustainable for the network either. This adjustment process is how we get back to a state where committed capacity is actually being used — which is a better outcome for everyone still running a node when the dust settles.
Questions and feedback are welcome in the usual SNO community channels.
