# Immediate vetting old reputable storagenode **URL:** \ **Category:** Product Discussions\ **Tags:** storagenode, vetting, identity\ **Created:** [July 25, 2026, 10:47am UTC](https://forum.storj.io/t/immediate-vetting-old-reputable-storagenode/32057 "2026-07-25T10:47:03Z")\ **Posts on this page:** 1\ **Showing post:** 6
**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:** [July 26, 2026, 3:06am UTC](https://forum.storj.io/t/immediate-vetting-old-reputable-storagenode/32057/6 "2026-07-26T03:06:02Z")
This difficulty was introduced to prevent the automatic addition of new nodes, which could otherwise be considered an attack: you planned for the satellite to handle 40,000 nodes, but received 1,000,000 in 15 minutes. What do you think will happen to your satellite? And you suggest something even worse – register them as vetted. Great, now the attacker becomes the sole owner of all your clients’ data. And they can demand additional payment from you, while they hold your clients’ data hostage. Also I saw somewhere that you want to remove /24 limit. Now you literally invited them to perform this attack and it can be done from the single device, like a wrt router or even weaker. All these restrictions were created by smart people who understand cybersecurity, and yet you’re trying to weaken your satellite completely by removing all these useful features (not identical keys in satellite components, identity difficulty level, /24 filter, vetting process). What else do you want to remove to make it even more vulnerable to attackers? Regarding the idea to restrict the vetting skip only for the old identity doesn’t make sense and I answered to the same suggestion here: > [@Publishing vetting status of nodes by satellites](https://forum.storj.io/t/publishing-vetting-status-of-nodes-by-satellites/22987/2): > > The vetting state here is for a reason. It actually could be a completely different node, than when you started it: you may migrate it any time. I support the idea, that node should gain a reputation on each satellite independently (and vice versa), I do not like an idea of preferences only because you stored data for other satellites. Because it also requires that the system should have a memory, and each new node started after the failed one must be considered as unreliable in this extreme ca… I can only add that there is no way to check that the identity is old and reputable, satellites doesn’t share this information. --- _[View the full topic](https://forum.storj.io/t/immediate-vetting-old-reputable-storagenode/32057)._