On insignificance of the "held" amount

I’ve just realized how insignificant the held amounts are. This is actually quite embarrassing that I’ve only noticed it now. Let’s take the BrightSilence’s estimator and consider some scenarios. With current numbers, the months during the held amount is accumulated only manage to fill about ~2.5TB, and the held amount is then ~17 USD. This means that:

  • If the SNO never planned to store more than 2.5TB, worth around 10 USD/month at the current egress-to-storage ratio, the SNO was never expecting large money back anyway. Besides, getting back 8.5 USD after 15 months amounts to less than one month.

  • If the SNO has more space, then the held amount becomes an even more insignificant part of the monthly payment, because it doesn’t grow anymore after those 9 months while the node grows.

The bigger the node, the smaller chunk the held amount is compared to monthly revenue. Hence if a node grows enough, it will likely be unable to recoup, let say, the time needed to keep the node online during the graceful exit process. In essence, it makes no economic sense to graceful exit large enough nodes—nodes whose sudden disappearance impacts the network the most.

I wonder why Storj hasn’t decided to keep accumulating the held amount until, let say, it corresponds to some fixed fraction of average monthly revenue of a node. Ie. if the node grows, then the held amount would increase. If the node stops growing, the held amount becomes capped. If the node starts growing again after a period of stagnation, some revenue is again taken until the cap is met. Also, if a node shrinks, the held amount would be released.

I know I’d be fine with this kind of arrangement.

1 Like

I agree completely. This has been brought up several times in the past, including by me. I don’t think anyone really bothers with graceful exit atm. It’s a slow process and the incentive just isn’t there to put in that effort.

In the past I’ve suggested simplifying the held amount to holding back up to 50% of payouts until the total held amount is equal to the last three months of node income. If income drops, you pay out any held amount over that amount. On my largest node, which makes about $60 a month, that would give me a held amount of $180. You better believe I will run graceful exit for that.

If you still want an incentive bonus for long term stable nodes, you can drop that held amount to last 2 months earnings instead of three after a year (or 15 months if there is a reason to stick to that kind of weird number).

@Toyoo: You could move this to suggestions to enable voting. Though I always wonder how many people would agree with us technically voting against our own interests. :wink:


i think held amount need to be reimagined…

the way it works doesn’t work at all…

cutting the concept down to its core.

it costs money to Repair lost data and is cheaper to Gracefully exit.
so the network want to pay or incentivize SNO’s not to just destroy their nodes.

one simple way might be to take a 10% of earnings,
to a max of something like lets say 10$ pr TB stored.
i duno a good number, but that doesn’t seem totally unreasonable.

this would make it so people get payouts, and slow but steadily over time as a node grows the held amount becomes worth the trouble with doing a GE
Because lets be fair… pulling the plug is pretty damn easy… people want something for their effort and might only GE once.

I must have missed these threads, sorry!

That’s more than what I had in mind, but maybe indeed it’s what it takes to recover the repair costs.

I don’t think this is a matter where a vote should be made, just like we do not vote on new parameters of the redundancy code. If it turns out that a stronger incentive for graceful exits is needed to maintain the network’s reliability, then the decision will happen.


Even though you suggested a different measure, it seems like we’re pretty much in the same ballpark since that would be about 3 months revenue. :slight_smile:

Though if you only hold back 10%, it would take almost 3 years to get to that point. And probably more, since the node is also growing all that time. I think it’s better to collect the held amount early by holding back up to 50%. It will only take 6 months to get there then and you already have a decent incentive to do a graceful exit, even for relatively new nodes.

I think it’s been mostly responses to topics that brought this up. It clearly still is the case, so I think it is very useful to have a topic dedicated to this. Definitely no need to say sorry. :slight_smile:

I don’t think the reason was ever to cover the full repair cost. At the moment, they would need to download 29 pieces to repair 20 lost pieces. And they pay $10 per TB to SNOs.

So that is already $10 * (29/20) = $14,50 per TB.

Then there are the costs of repair workers processing and egress costs to send those repaired pieces back to other nodes.

The held amount is not meant to cover all of that, but more as an incentive for SNO’s to choose the cheaper option for both sides.

I guess that is the real answer… apparently it is not needed atm or they would have done it already. I think there is a pretty solid base of reliable nodes that Storj can deal with those that aren’t for now. That said… this does create costs for them. In the long run, that isn’t really good for anyone.

1 Like

the problem imo is for older nodes the GE incentive can be quite low… also people can just wait out the time period where the held amount is accumulated.

which is why my suggestion works on a continual basis… rather than it will be possible to have a node which could have 20TB stored and like 10$ in held amount…

the current held never changes over time (except for new ish nodes) and so the incentive to GE becomes less and less while the node keeps growing.

so i think the mechanic is fundamentally flawed because it can be bypassed and is almost irrelevant, ofc that also depends on how expensive repair really is.

Yeah, we’re suggesting essentially the same thing. Except you used an amount per TB, while I said it should equal the last three months in payouts. Both will grow along with the node.

1 Like

Perhaps a new thing called Graceful Exit Bonus.


You are correct that there hasn’t been a need to adjust how graceful exit works yet.

With that being said, however, we are always looking to improve incentives to align node operators with the best interests of the entire network, not just themselves. Keep the ideas coming!


yeah i have one of my oldest nodes, which i have been thinking about GE … not because i need to, but simply because the newer nodes earn like 1$ more pr TB stored pr month…

what can i say… i’m running low on capacity… lol
haven’t decided if i will nor not… most likely won’t… but still i did seriously consider it for a good while.

so its not like a high held amount is great either… it needs to be so that the SNO and StorjLabs split savings from the network not having to repair … or something like that…

One more thought. I was thinking whether a decent incentive for graceful exits would be if a graceful exit would guarantee terminal payment even if the node’s address does not meet the minimum threshold. Though, at least as of now, any decently large node whose sudden disappearance would hurt most would meet the threshold most of the months anyway.

It used to be the case that nodes that became inactive always got a terminal payout. There was a lot of backlash to that as it meant nodes that left would get paid while reliable nodes that stuck around did not. It never really bothered me personally, but the backlash was enough that Storj Labs decided to stop doing that. I think at the time the suggestion was brought up to only do it for nodes that gracefully exited, but the response at the time was that the payout script couldn’t differentiate between exited nodes and nodes that just disappeared.

I still like the idea though. But I can imagine that being quite hard to implement. Since people can have multiple nodes it’s not always clear whether they have all exited or not. And what if one finished graceful exit but another one just disappeared?