# Helping the network become profitable — what can operators contribute while staying viable? (calculator inside) **URL:** \ **Category:** STORJLINGS\ **Created:** [July 30, 2026, 8:58am UTC](https://forum.storj.io/t/helping-the-network-become-profitable-what-can-operators-contribute-while-staying-viable-calculator-inside/32104 "2026-07-30T08:58:59Z")\ **Posts on this page:** 1\ **Showing post:** 404
**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\ **Post date:** [August 14, 2026, 5:06am UTC](https://forum.storj.io/t/helping-the-network-become-profitable-what-can-operators-contribute-while-staying-viable-calculator-inside/32104/404 "2026-08-14T05:06:15Z")
> [@Grimm](#): > > it is not recommend because it defeats the purpose of the /24 rule to make data more resilient to loss because of one ISP of several nodes being in the same location. This remains true. However, our protocol doesn’t prohibit its violation at your expense—bypassing restrictions isn’t free. We can’t block all VPN nodes, at least not yet, because this method could also be used by nodes behind CGNAT, which would otherwise simply render them offline. I would prefer to see the node selection adjusted so that piece distribution is more secure: no more than one piece per segment, at least not on the same disk, preferably not on the same hardware, and even better, not in the same location. For now, the choice-of-n rule slightly improves this situation, and it could be strengthened by increasing it from 2 to 4 or more. Then VPN nodes will inevitably end up at the end of the list due to their inherent latency. This doesn’t completely solve the problem, but it reduces the likelihood of data loss. --- _[View the full topic](https://forum.storj.io/t/helping-the-network-become-profitable-what-can-operators-contribute-while-staying-viable-calculator-inside/32104)._