Maximum Self-Delegation Reduction Per Day

[rigelrozanski]

Spin off from the initial work done on this issue:
cosmos/cosmos-sdk#3495

This feature of self-delegation limits was not completed initially in favour of getting the core feature in faster. We should complete it! See the orig issue for more discussion.

Maximum Self-Delegation Reduction Per Day (default very large)
* This parameter _can only_ ever be decreased (arbitrarily by the validator)

CC @sunnya97

[crainbf]

I think what would be much better is if validators could self-impose a limit on the maximum delegation they can receive. e.g. a validator could set their max delegation parameter to 5% of total atom supply, or something like that.

I don't think this feature gives validators an effective way to self-limit their size.

I also don't see the scenario this is meant to protect from as a plausible risk at all. It's going to be a huge amount of work to get a substantial amount of delegation. Delegators will also pay attention to reputation, real-world identity, etc. Why would a validator then go and double-sign?

[rigelrozanski]

I don't think this feature gives validators an effective way to self-limit their size.

correct, the idea behind the "minimum self-delegation" feature is not to impose a size limitation on the validator (which the validator can choose) but instead to provide an added security for the delegators and the network. This particular issue is referencing that a validator should be able to lower the self-imposed self-delegation amount if their circumstances change (in the current code base, it can only be increased, not reduced at all) - however the amount that can lower it should be throttled as to protect sudden self-delegation emptying which would of course put all the delegators stake at risk (nothing at stake issue).

Note (as per the linked issue) the amount of self-delegation limitation is by amount, not percent amount

---

As previously decided, allowing validators to whitelist or "cap" the amount delegation they were able to receive is not a prelaunch feature

[crainbf]

Yes, I understand the intention. I just think the attack scenario that it could protect delegators from is implausible.

I think the feature would do no harm, but also not add much value. So in the spirit of simplicity, my preference would be not to do this.

[rigelrozanski]

referring to the parent feature referenced in this issue the conclusion we've come to within the development team is that this is a real threat and is security critical for launch - and it's already implemented in fact...

However this issue is only in reference to the ability for validators to reduce their self-imposed minimum self-delegation by at a throttled rate. Currently they are unable to reduce their minimum self-delegation at all - it simply provides more due flexibility to validators - however I agree that it's not necessary for launch, it will probably be implemented shortly after launch.

[crainbf]

Okay. Just some context here:
Chorus One has no atoms, while I and my co-founder do have atoms. I expect that we'll receive a non-zero amount of atoms from Game of Stakes. So then the company can properly generate an address and have ownership of that.

If the company wants to have "self-delegation", we'd either have to use a personal private key for validation OR have some out-of-band contract to give custody of personal atoms to the company. Both of these are undesirable. The first is insecure. The second adds somewhat substantial overhead in terms of accounting & setting up legal contracts.

So even though we would delegate to Chorus One, we'd still want to choose a minimum self-delegation of 1 atom. If delegators really care about this figure, of course, we could change that and actually lend personal atoms to the company.

I suspect most validators will reason in a similar way.

But if the minimum self-delegation does exist anyway, I do think being able to reduce it at a throttled rate makes sense.

[rigelrozanski]

yes I believe that the minimum self-delegation must be 0 atoms to allow for pre-send validators which are created using the "CreateValidatorOnBehalfOf" feature... and yes this limit purely self-imposed and I imagine many validators (at least initially) will keep it safely low at least initially.

[jackzampolin]

is this still an issue? Isn't it replaced by #3917 ?

[rigelrozanski]

yes this is still an issue, I made an error (and deleted my comment) in referencing 3917, these two are independent issues