Some of the holders could have passed away sadly between them staking to the pool and now. This ADA is lost forever. The retired pools ADA should be automatically unstaked from threat of inefficiency due to dead ADA in retired pools.
Solutions ?
1 Like
Thats definitly a good question and as far as i remember this question was already raised a few times.
Will follow this thread to see if a few new ideas come up. 
Is Randomised auto stake distribution at the protocol level possible? Autopilot. FSS - Fully Self Staking.
Id say alot is possible but the question is, do we really want that? What prevents someone from spinning up 100 pools, or even more, and do bad stuff?
If we dont do something about it. We all will die in a 100 years and at that point a lot of ADA will die with us as well. So many dead pools, dead stakes etc, a lot of inefficiencies in the system. Dont you think ?
Somewhen it the future this definitly could cause an problem, yes i do agree. But im not sure yet how to fix it.
1 Like
Lost keys and people who have just left the ecosystem for good are a quite similar problem to dead people.
For delegations – to pools as well as to dReps – an expiration of delegations has been proposed often to prevent such sticky stake staying there forever.
If it is to retired pools and dReps, it is not really a problem, though. It just doesn’t count. It doesn’t take away any chance to produce a block and it also doesn’t take away any rewards from anybody. (Which is also why it is simply not necessary to delegate it to random pools – or dReps. It’s totally fine to just expire/undelegate it and leave it undelegated.)
Far more serious is if such sticky stake is delegated to active pools and dReps who then have it practically guaranteed forever and are harder to compete with.
While expiration of delegations is possible and in my opinion an excellent idea that should have been implemented from the start in both – pool and dRep delegations – there is no good way to deal with the inaccessible ADA itself. If the keys are lost – irrespective if due to bad management or death – we can’t do much without sacrificing some of the core principles of cryptocurrencies – nothing is done without the owner’s consent and signature.
Such UTxOs and stake addresses will just pile up in the ledger. Not sure if that will become a problem or if nodes can just deal with it.
3 Likes
Possible to simulate and study reasonable outcomes ?
What exactly do you want to simulate under which assumptions for what purpose?
Guessing the number of addresses and stakes where access is lost due to technical or biological reasons seems rather wobbly. And won’t change that some – over time a lot – of them just will exist.
That, from the point of view of the chain, we can’t really distinguish between loss of keys, death, or just long-term inactivity is also kind of a fact that does not have to be simulated.
It’s also not that hard for node implementations to optimise: just put the parts of the ledger, of the UTxO set, of the list of stake addresses, that haven’t been touched for years somewhere on disk where they aren’t in the way, but can be retrieved in the case the keys were not lost, the owner is not dead, but comes back in the next bull run or one of the ones after that.
I’d concentrate on advocating for delegation expiration. That seems sensible not only for this scenario, but also because choosing a pool and/or a dRep should require some activity at least once in a while.
1 Like