Scaling up with conditional basic income

[ephemeral_25]

@adintium

In my ideal cosmos hub setup, there would be a re-delegating mechanism. Essentially there is a limit to how many delegations a validator can hold. Hence, for the surplus, the validator can re-delegate the delegation… except the validator can only re-delegate to other validators in the active set (+5 of the top in the inactive set).

I don’t think it’s about the numbers of delegations but more about the amount of delegations (VP).
A simpler approach to what you are describing could be to just cap the max bounded tokens. Delegators would just have to delegate elsewhere since validators could be ‘full’.

Allowing a validator to redelegate for it’s delegators is pretty risky, let’s say the cap is 5% VP but the validator is managing an extra 20% to redelegate because of the CAP, one single hack could have huge repercussions.

But again I’d consider this die trying, survival mode type of measure and it goes against what I was describing earlier.

@adintium

As there is no real incentive to opt-in in the future and the validator is also rewarded for inaction, I cannot yet see how this is beneficial for the Hub or atom holders in the long-term.

As far as I can remember the opt-out is not a permanent feature.
It needs to be implemented so that current bottom validators can still have the diversity of tokens to offer to delegators despite not being able to validate the consumer chain (because it would not be economically viable for them).
If you where to have a validators outside ICS only offering $ATOM as staking rewards, I doubt any new delegators would like their stake there and perhaps the ones already positonned would re-delegate which would create a major void in our current validator set and a pending bankruptcy for ALL the bottom validators, diminuishing even more the spread of the VP, accentuating even more the concentration at the top.

But I agree this should not be LT, perhaps it’s up to delegators to take action accordly.

@adintium

If we have a situation where validators #100-#175 aren’t willing to validate for consumer chains (because of the understandable cost issues), but inactive validators #175-#180 are willing to take the cash flow risk and provide this service… then I would like to encourage validators #175-#180 to be productive and contribute to the network security. But the dynamics of such situation would be hampered if the soft opt-out validators continue to be rewarded despite not validating on consumer chains.

Once again I think that’s not ours to take care of in any way, shape or form.

If validators are inactive they should remains so and not forcely put to the active set against previous active validators.
A validator should only be in the active set in the first place because he is financially stable, therefor providing continuous and sustainable security to the Hub.
Swapping them around is not solving anything, you are just replace a weak link by another faulty one.

And let’s say an inactive validator is still WILLING to do so, then he should just already be in the active set by providing for himself the needed tokens proving himself financially stable to the rest of the hub.