Let's address the /24 subnet limitation ipothetic removal

For anyone new to the forum, the /24 subnet limitation is set to consider all nodes in a /24 subnet like one node for the ingress traffic, with no limit on engress traffic. This means that all nodes in that subnet will split the ingress dedicated to a sigle node. Storj team have chosen this to achieve descentralisation of the nodes, but many big players found ways to circumvent this limitation.
In the last Twitter space, Storj team let open the discussion about a possible /24 subnet limitation removal, stating that they look into different solutions.
So, we should come up with solutions if we want to accelerate this removal and if it is better or worse for the network.
It has been sugested that for the second node, the SNO should make a deposit/ a collateral.
Also it has been sugested that in the future, if you want to make a node, you can make a deposit that will eliminate the need for the held amount.
What’s your opinion? What sugestions do you have? What amount are you willing to deposit?
Personaly I don’t realy care for the /24 limitation, just for /32 limitation. I’m willing to deposit 50-100$/node to be able to make more nodes with the same IP, with full ingress, and get rid of held amount.

1 Like

Dear team, tell me, when are you going to start reducing payments already? In principle, this topic is already quite large, everyone who had something to say - everyone spoke out, they threw ideas at you, expressed their attitude. Hardly anyone will say something new.
Let’s already decide something, do it - we also need to adjust our strategies: either completely leave your project, or think about something, optimize, etc.

1 Like

Well, the question is, if Storj would like to stick to the evergreen saying of “use your unused hardware only” or would like to run the network 95% by professionals.
I have 6 nodes behind my single IP, residental internet connection. It would make me happy, but as Storj management is not capable to say anything about their future plan for months already, I would not invest a single USD into this.


I won’t support this proposal until partial graceful exit will get implemented. Many small nodes is the workaround to the lack of partial graceful exit for those SNOs who actually want to realize the unused space ideal and wish they could scale down a node when they need space for other activities.

I don’t really see how a deposit is better than the held amount.

The way I see it, /32 vs. /24 doesn’t help home SNOs (who’d have a single IP address anyway), but it would tremendously help large SNOs (for whom getting a set of consecutive IP addresses would be easy). So why bother changing it?

If you really wanted to force more decentralization to increase the number of independent fault domains, there were proposals to base the traffic allocation on autonomous systems or geolocation based on latency measurements, both in this thread. So far /24 is still not that bad though.

1 Like

What is the incentive not to lease an IP then, which would be a fraction of this cost? Routing the traffic though somewhere else adds latency. Are you proposing here I will pay more to lower the latency of the network?
Don’t get me wrong, but there were attempts to do something like this - SIA is one, where you had to deposit to join the network I believe, SCP comes to mind as a second, where as I understand it you are buying some kind of a license, Helium a third where you had to buy overpriced LoRA equipment to be able to join the network. And we all see how that goes.
I would say remove the limitation for the nodes that are vetted. The decentralisation will come naturally.
In my case I had to move some of the equipment to a different location as upgrading the connection here, to be able to a) keep up with the demand and b) not to jeopardise other services, would cost far too much. By doing this I lost redundancy in many aspects (power, network, data), A/C, so the expected drive lifespan is reduced, site presence to be able to do repairs in a timely manner and I’m paying more for the electricity.
Paying for some kind of a licenses, to be able to provide service, insults me.
I have been funding this operation for the last two years expecting returns somewhere in the future and I think instead of buying licenses I will be better off buying drives, chassis, cables and spare parts, all to be able to expand in the future.


If the STORJ network was mine to run I would continue to work against a “earned responsibility” model

I would:

  • Set a node storage limit - it’s “Safer” to run multiple smaller nodes for operators and customers. I host 10TB and almost added another 10TB drive via LVM - in this configuration a single database file could have resulted in 20TB and years of work being lost. If I had ten 2TB instances I could lose a node and not take a significant hit on my earnings while also impacting a smaller portion of the community.
  • Node operators that cross a year and have maintained a certain level of uptime (QoS) would be eligible to run a second node.
  • Once a second node is spun-up, anytime the sum of all nodes hits 80% full a node operator could spin up a new node (If the operators uptime QoS still qualifies them)
  • QoS and nodes would roll-up to the node operator account, with nodes being registered to their accounts, including hardware fingerprints / MAC info to make it more difficult to host multiple fake accounts.
  • All nodes should be treated equal, even when hosting multiple nodes on the same hardware. If they have the resources to serve the request, let them.


Running smaller nodes on different HDDs would not be very rewarding with the new payout cuts, because of the energy costs. Running smaller nodes on the same HDD is against TOS. My opinion is that now you should start nodes only on 20TB+ HDDs, without RAID.

The history of a SNO is not a good indicator of how he or his nodes will perform in the future. I myself ran 2 nodes in the first year very chaotic, with many restarts and wrong setups, untill I learned more and baught more hardware. Now all my 8 nodes are pretty well made, with good components, UPS, good paramenters, etc. So I’m more reliable now than 2 years ago. Why my past should affect the future deployment of nodes? And the vice versa is true also… You can deploy the best setups in the begining and than you get bored, don’t want to invest more and deploy crappy nodes.

You could start the nodes with 1TB allocated, fill them, start new ones, and than change that to 14TB, the real free space. So this wouldn’t work.

Fingerprinting and other info like KYC would add an undesired and unnecesary level of complexity, and dosen’t solve anything. Nodes can be moves on other hardware, because of upgrades or failures.

The deposit for creating a node would be just a collateral, not a license. You will get it back when you graceful exit or after 1 year.

1 Like

For my personal situation, I would like a limit of 2 nodes per IP with full ingress, because I have only NASes with 2 bays, and one bay is still empty, waiting for the first drive to fill. All my nodes are in different subnets.
I’m willing to lock a fixed amount upfront, instead of locking an unknown amount in 10 months or whatever is the period now. That way the earnings are more predictible. The held amount could also surpass the deposit, so you will loose more in case of node fail… but also less.
So my proposal is:

  • 2 nodes with full ingress for one IP or one /24 subnet.
  • optional upfront deposit for runing both nodes, or just the second one.
  • held amount should still be the other option.

please dont project your setups to all other people. I ran lot of 4tb nodes, and they work very perfect and profitable. some of them are 7-10 years old, and 3+ years on nodes i receved from them 1000+$ from storj on this time. from almost each hdd.
Situations are very different on every setup.

so if setup profitable, handle all operations and work stable this is the best setup.

1 Like

I think you missunderstood me, but nervermind… Everyone can do as he pleases.

I like the option to pay a deposit upfront to unlock a node from the /24 limitation. But the amount has to be reasonable. And I do view using my own money as collateral as a big downside. It suddenly isn’t a great idea to run that node on a single disk, because even if it’s new, it can fail and I’m out my own money. So this would incentivise people to run less economical RAID setups. I’m not sure that’s the best outcome.


i like the deposit concept as it would save expenses for IP’s and thus make it more economical to run more nodes :smiley:

besides ip’s often end up being shared with other nodes which further degrades the advantage of running multiple ip setups.

the IP/24 subnet war was never a good thing, its highly inefficient…

i would suggest the deposit working something like held amount… but being in relation to how much data is stored, increasing until it hits a limit and then maybe that unlocks the ability to use the deposit for more nodes or having it paid out.

ofc there are a lot of considerations with making a change such as this…
if the deposit is to low everyone will just add to many nodes, if its to high it isn’t worthwhile… so it would need to have some sort of variable or dynamic model to it, so that its works for everyone.

I’d say it should also be a switch. If my node is full, why should I keep around that deposit? At that point it has no benefit anymore to me. I should be able to get back at least part of it at some point.


I tend to think if we got rid of the /24 filter, that the majority of nodes would get less data, not more. Even if you are splitting data with multiple nodes, the fact is that data centers have large pools of static IP’s that they could assign to each node. They would blanket the network with far more IP’s than the home users would have. That’s the entire reason for having the /24 rule in the first place, to prevent this. They would end up with the majority of the data, and thus it would centralize.

Yes, some people use VPS/VPN’s to skirt the rule, but they often end up sharing with a neighbor anyway because they aren’t the only ones doing it. And it has limitations on utility since it does add some latency, cost, overhead, and time to configure. Not to mention it has to be reliable. I think the perceived problem with the 24 rule is overblown. The reason you aren’t getting that much data, is because there are tens of thousands of nodes out there splitting the available data, and less because you have a neighbor in your IP block. If that neighbor node was on another block, they’d still be getting a portion of the data. Maybe your node would get more, but the pool of IP’s that the Sat picks from is gigantic. I wonder how often the /24 rule even matters with such a wide number of nodes to choose from.


I think the hard part is to find a balance between requiring enough money deposited upfront to prevent people from spinning up thousands of nodes in a datacenter, while at the same time having the amount low enough so home node operators could have an advantage. I kind of fear there is no good value as those with access to a datacenter might be willing to put up more money and build nodes on redundant infra so they don’t risk it, than what home node operators would be willing to put in. So yeah, I share your fear of centralization.


I don’t like this. Let’s say I want to add another node, but first I have to pay $50 deposit. How long until my brand-new node earns the $50 back? Even with current rates it would probably be longer than a year. And if I use an old hard drive that breaks in a few months I actually lose money. In this case I could only use new drives and use RAID. Well, so much for “don’t use RAID” and “use what you have”.

I don’t really see the /24 limit as a problem though. Actually, it helps me, as I can run a single big node and not lose out on traffic (well, at least until someone else on my /24 starts a node). If the limit was removed (especially if there was no limt at all and nodes sharing the same IP were not combined), I would have to run multiple nodes (as many as possible) to compete for traffic. I remember this from v2 time and don’t like it. Now I would only need to run multiple nodes if someone else on my /24 started a node or if I wanted to use my other internet connection.

Yes, some people figure out a way to get multiple IPs from different subnets and route them to a single server. There are not many of them though as those extra IPs usually cost at least a few Euros/month and most of them have traffic limits (or some people can get access to those IPs for free). I don’t this this is such a big problem though.

I probably could set up one or more additional nodes, but I don’t think it would be worth the effort. Or maybe it would.


I am not getting how deposit will help /24?

1 Like

One variant could be that for each extra node, you will have to deposit double the amount of the previous one.
But yeah, the competition with others skipped my vision. If we are allowed to have 2 nodes instead of one, than everybody will make 2 nodes and the amount of data you’re getting remains the same or goes down because some deep pockets cand put more money upfront.
This is what I wanted to prove with this thread, because more brains are better than one: is it better or not to remove the /24 limitation?
Is seems that the answear is no, there whould be no beneffit.


are you even aware of how exponentials works, and how would you ever assure its the same person… that idea is most likely even worse than the ip/24 solution…

lets set
starting at say 25$
2.nd is 50
3rd is 100
4th is 200
5th 400
6th 800
7th 1600
8th 3200
9th 6400
10 13200
and only thing one needs to zero that is a fake identity.

Deposit will put a barrier only for small sno that all.