# Rightsizing Storj Network Payout Rates

**URL:** <https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391>\
**Category:** Node Operators\
**Tags:** payouts\
**Created:** [August 20, 2026, 10:01pm UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391 "2026-08-20T22:01:13Z")\
**Posts on this page:** 20\
**Page:** 14

<div class="post-metadata">

**Author:** ![Roxor](https://storj.bcdn.literatehosting.com/letter_avatar/roxor/32/5_5575768a8748004e209b776fc1b2916d.png) [@Roxor](https://forum.storj.io/u/Roxor)\
**Post date:** [September 2, 2026, 11:31am UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/297 "2026-09-02T11:31:12Z")

</div>

> [@jammerdan](#):
>
> Nobody will put 30 nodes on a single 16TB disk if the disk would fill fast enough with 1 node.

Yeah, does this all go back to how big nodes can really get now? Would a fair guess be something like 10TB per /24, over maybe three years?

So long-term a 30TB HDD would comfortably handle three nodes?

I wish 😉

---

<div class="post-metadata">

**Author:** ![Vadim](https://storj.bcdn.literatehosting.com/letter_avatar/vadim/32/5_5575768a8748004e209b776fc1b2916d.png) [@Vadim](https://forum.storj.io/u/Vadim)\
**Post date:** [September 2, 2026, 11:38am UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/298 "2026-09-02T11:38:46Z")

</div>

> [@Roxor](#):
>
> So long-term a 30TB HDD would comfortably handle three nodes?

I dont think it will handle, as more data more bandwidth, deletes, compaction, and they all corelated in time. but IO stay same.

---

<div class="post-metadata">

**Author:** ![Roxor](https://storj.bcdn.literatehosting.com/letter_avatar/roxor/32/5_5575768a8748004e209b776fc1b2916d.png) [@Roxor](https://forum.storj.io/u/Roxor)\
**Post date:** [September 2, 2026, 11:42am UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/299 "2026-09-02T11:42:06Z")

</div>

My rule-of-thumb is six. Like one HDD has the IO to easily handle six “busy” nodes. I’m sure it can go higher… but six means the drive still has spare read+write IOPS: it’s not stuck 100%-busy.

---

<div class="post-metadata">

**Author:** ![Vadim](https://storj.bcdn.literatehosting.com/letter_avatar/vadim/32/5_5575768a8748004e209b776fc1b2916d.png) [@Vadim](https://forum.storj.io/u/Vadim)\
**Post date:** [September 2, 2026, 11:50am UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/300 "2026-09-02T11:50:11Z")

</div>

how much TB of data do you have there on HDD?

---

<div class="post-metadata">

**Author:** ![Roxor](https://storj.bcdn.literatehosting.com/letter_avatar/roxor/32/5_5575768a8748004e209b776fc1b2916d.png) [@Roxor](https://forum.storj.io/u/Roxor)\
**Post date:** [September 2, 2026, 11:58am UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/301 "2026-09-02T11:58:19Z")

</div>

It’s not really related to size: but you can assume 10TB/node. A “busy” node (lots of egress) seems to average ~15 read IOPS. Writes are async: which means they go to memory (and filesystems like ZFS will batch them into sequential updates about every 5 sec): so write IOPS can almost be ignored.

And modern drives seem comfortable with (6x15=) 90 sustained read IOPs and some extra writes, and still stay responsive.

Do you run more?

---

<div class="post-metadata">

**Author:** ![Vadim](https://storj.bcdn.literatehosting.com/letter_avatar/vadim/32/5_5575768a8748004e209b776fc1b2916d.png) [@Vadim](https://forum.storj.io/u/Vadim)\
**Post date:** [September 2, 2026, 12:21pm UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/302 "2026-09-02T12:21:35Z")

</div>

My biggest node is like 10tb of data, I see data usage is low. I personally don’t like idea to have several node on one HDD, but it looks like I pay to much to operate according to ToS.

---

<div class="post-metadata">

**Author:** ![hashbackup](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/hashbackup/32/9034_2.png) [@hashbackup](https://forum.storj.io/u/hashbackup)\
**Post date:** [September 2, 2026, 1:44pm UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/303 "2026-09-02T13:44:06Z")

</div>

> [@jammerdan](#):
>
> Nobody will put 30 nodes on a single 16TB disk if the disk would fill fast enough with 1 node

There is more going on than just the total amount of data stored and network growth. Even when the total data stored does not increase, new pieces are being created and older pieces deleted. Nearly everything works this way: backup programs, storing camera video for the past 30 days, collaborating on a media project, etc. So there is _always_ an incentive to cheat to capture as many _new_ pieces as possible, while old pieces are removed.

The purpose of cheating isn’t to increase capacity of the network, it’s to bleed data away from other nodes by:

- making 1 HDD appear to be many independent nodes
- using unique /24 IPs to make nodes appear independent
- using VPNs to make nodes appear to be someplace geographically desirable when they aren’t in reality and would be excluded by customers requesting a specific region
- being statistically more likely to _enter_ races; you have to enter before you can win

The other day I uploaded a file with uplink using --upload-log-file, made a list of the 54 node IPs that won, then asked Chatgpt to classify them by country. I’m in the US Midwest, but only 3 of the winning nodes were in the US and Chatgpt said they were likely VPN addresses. Most were in Europe. That seems really broken to me.

The only suggestion I’ve seen that actually addresses cheating is:

> [@FunFrog](#):
>
> 1. Keep /24 rule.
> 2. Make first 500Gb unpaid for the first node on specific IP.
> 
> This means:
> 
> - One honest server with 10 HDDS = 10 nodes on the same IP - only 500Gb unpaid for the whole server.
> - One cheater with 10 nodes = 10 VPN connections with different /24 IPs - 5TB unpaid.

Sounds like a good idea.

---

<div class="post-metadata">

**Author:** ![Vadim](https://storj.bcdn.literatehosting.com/letter_avatar/vadim/32/5_5575768a8748004e209b776fc1b2916d.png) [@Vadim](https://forum.storj.io/u/Vadim)\
**Post date:** [September 2, 2026, 1:59pm UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/304 "2026-09-02T13:59:13Z")

</div>

> [@FunFrog](#):
>
> 1. Keep /24 rule.
> 2. Make first 500Gb unpaid for the first node on specific IP.

witch node will be the first, if several node on same IP this is understandable, but several node on same /24 doesn’t mean they belong to same operator.

if storj makes first 500gb free for every node, we will not need ip filtering at all.

with 30k nodes, chanses that several pieces from 54 will end up in one location is almost nothing, but repair could be /24, if audit will find several pieces in same IP.  
and this will be much cheaper to operate than today.

BUT first of all we need some tests for it and accumulate data, just because think twice before jump.

---

<div class="post-metadata">

**Author:** ![alpharabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alpharabbit/32/1129_2.png) [@alpharabbit](https://forum.storj.io/u/alpharabbit)\
**Post date:** [September 2, 2026, 2:12pm UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/305 "2026-09-02T14:12:54Z")

</div>

Everyone is arguing to make themself most profit while storj only needs lower payment. The path to achieve this is removing all restrictions from SNOs while cutting payment on a monthly base. The more nodes the more likely pure random node selection is good enough for piece distribution.

---

<div class="post-metadata">

**Author:** ![Vadim](https://storj.bcdn.literatehosting.com/letter_avatar/vadim/32/5_5575768a8748004e209b776fc1b2916d.png) [@Vadim](https://forum.storj.io/u/Vadim)\
**Post date:** [September 2, 2026, 2:28pm UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/306 "2026-09-02T14:28:05Z")

</div>

first need some calculation how it will go. because storj use not only amount of nodes, but some kind of faster is better. and this faster node amount can be much lower, the probability to send piece to same location go much higher.

---

<div class="post-metadata">

**Author:** ![alpharabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alpharabbit/32/1129_2.png) [@alpharabbit](https://forum.storj.io/u/alpharabbit)\
**Post date:** [September 2, 2026, 2:46pm UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/307 "2026-09-02T14:46:45Z")

</div>

They always use choice of n on top for selecting fastest nodes. What we are discussing here is pre-selection for choice of n.

---

<div class="post-metadata">

**Author:** ![peem](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/peem/32/6323_2.png) [@peem](https://forum.storj.io/u/peem)\
**Post date:** [September 2, 2026, 2:51pm UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/308 "2026-09-02T14:51:57Z")

</div>

What is it “fastest nodes” ?  
Where can I find a description of such a concept?

---

<div class="post-metadata">

**Author:** ![alpharabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alpharabbit/32/1129_2.png) [@alpharabbit](https://forum.storj.io/u/alpharabbit)\
**Post date:** [September 2, 2026, 3:01pm UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/309 "2026-09-02T15:01:23Z")

</div>

Ask AI bot of your choice to explain it from source code. Way better than anything you will get here. 😉

---

<div class="post-metadata">

**Author:** ![Roxor](https://storj.bcdn.literatehosting.com/letter_avatar/roxor/32/5_5575768a8748004e209b776fc1b2916d.png) [@Roxor](https://forum.storj.io/u/Roxor)\
**Post date:** [September 2, 2026, 3:34pm UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/310 "2026-09-02T15:34:30Z")

</div>

> [@hashbackup](#):
>
> The other day I uploaded a file with uplink using --upload-log-file, made a list of the 54 node IPs that won, then asked Chatgpt to classify them by country. I’m in the US Midwest, but only 3 of the winning nodes were in the US and Chatgpt said they were likely VPN addresses. Most were in Europe. That seems really broken to me.

We know most free-space [is in Europe](https://storjnet.info/): as are most nodes in general. It would be broken if most of the winning IPs **weren’t** from there, no?

---

<div class="post-metadata">

**Author:** ![hashbackup](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/hashbackup/32/9034_2.png) [@hashbackup](https://forum.storj.io/u/hashbackup)\
**Post date:** [September 2, 2026, 3:56pm UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/311 "2026-09-02T15:56:35Z")

</div>

It depends on the extent of cheating. I’d agree that most IP addresses are in Europe according to the databases used to map IP addresses to locations.

Thanks for the link; I didn’t know about it.

---

<div class="post-metadata">

**Author:** ![mattventura](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/mattventura/32/7831_2.png) [@mattventura](https://forum.storj.io/u/mattventura)\
**Post date:** [September 2, 2026, 4:03pm UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/312 "2026-09-02T16:03:45Z")

</div>

If someone uploads something from the US, it _should_ ideally land on US nodes, no? To provide better performance? I’m sitting here with TBs free + many more drives on standby.

---

<div class="post-metadata">

**Author:** ![hashbackup](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/hashbackup/32/9034_2.png) [@hashbackup](https://forum.storj.io/u/hashbackup)\
**Post date:** [September 2, 2026, 4:18pm UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/313 "2026-09-02T16:18:37Z")

</div>

> [@Roxor](#):
>
> We know most free-space [is in Europe](https://storjnet.info/)

I’m not sure anyone can say how much free space is available in the Storj network because as I understand it, that’s just a number that SNOs enter for the size of their drive, and often times (so I’ve read) it is duplicated when a drive is divided into multiple nodes with volume managers.

Unless Storj filled the entire drive with data and then manually released it as needed, I don’t think the node software can verify that the free disk space a node says it has is truly available.

My laptop says this:

```auto
Filesystem 1024-blocks Used Available Capacity iused ifree %iused Mounted on
/dev/disk1s5s1 244912536 15058276 83053612 16% 502388 830536120 0% /
devfs 186 186 0 100% 644 0 100% /dev
/dev/disk1s4 244912536 2098196 83053612 3% 3 830536120 0% /System/Volumes/VM
/dev/disk1s2 244912536 402432 83053612 1% 2098 830536120 0% /System/Volumes/Preboot
/dev/disk1s6 244912536 3364 83053612 1% 20 830536120 0% /System/Volumes/Update
/dev/disk1s1 244912536 143065044 83053612 64% 418317 830536120 0% /System/Volumes/Data
map auto_home 0 0 0 100% 0 0 100% /System/Volumes/Data/home

```

All of the partitions say they have 83GB available but you can’t write 83GB to all of them.

Edit: it just occurred to me, if free space is not accurate, how can it be used to continue justifying a decrease in SNO payouts?

---

<div class="post-metadata">

**Author:** ![zip](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/zip/32/7813_2.png) [@zip](https://forum.storj.io/u/zip)\
**Post date:** [September 2, 2026, 4:40pm UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/314 "2026-09-02T16:40:27Z")

</div>

> [@hashbackup](#):
>
> Edit: it just occurred to me, if free space is not accurate, how can it be used to continue justifying a decrease in SNO payouts?

They might be using a different metric - such as how many nodes are not accepting uploads (because they are full). There is this `full_nodes` metric on [http://stats.storjshare.io/](http://stats.storjshare.io/), and you can turn this into a percentage of the network for example.

---

<div class="post-metadata">

**Author:** ![alpharabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alpharabbit/32/1129_2.png) [@alpharabbit](https://forum.storj.io/u/alpharabbit)\
**Post date:** [September 2, 2026, 4:50pm UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/315 "2026-09-02T16:50:14Z")

</div>

> [@hashbackup](#):
>
> that’s just a number that SNOs enter for the size of their drive

SNOs are free to set this number but node software will cap it at what OS is reporting to be free.

I am starting new nodes with a 1 TB setting. If free space is going below 100 GB my monitoring software will add another 500 GB.

---

<div class="post-metadata">

**Author:** ![Roxor](https://storj.bcdn.literatehosting.com/letter_avatar/roxor/32/5_5575768a8748004e209b776fc1b2916d.png) [@Roxor](https://forum.storj.io/u/Roxor)\
**Post date:** [September 2, 2026, 5:04pm UTC](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391/316 "2026-09-02T17:04:28Z")

</div>

> [@mattventura](#):
>
> If someone uploads something from the US, it _should_ ideally land on US nodes, no? To provide better performance? I’m sitting here with TBs free + many more drives on standby.

I guess the idea is that the wider the pieces are distributed, the less chance any type of local failure (like an ISP having an outage) could knock any data offline. And then from that broad list of possible nodes… they race and the fastest wins.

Storj was also marketing to Media and Entertainment companies with [global workflows](https://www.storj.io/solutions/global-cloud-storage-and-file-access). The pitch was that data could be accessed quickly anywhere: no matter where the employee was. Parking everything in the US when you’ve got people editing videos in Romania doesn’t help you.

But I think you could always choose to geolocate if you wanted to?

[Previous page](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391.md?page=13)

[Next page](https://forum.storj.io/t/rightsizing-storj-network-payout-rates/32391.md?page=15)
