yearn / yearn-vaults-v3

GNU Affero General Public License v3.0
104 stars 37 forks source link

Should we add a way to restrict deposits to a subset of users? (by whitelist, veYFI tokenholders, ...) #74

Closed jmonteer closed 2 years ago

jmonteer commented 2 years ago

I am thinking some vaults could take great advantage of being able to allow deposits only to a subset of users.

This module, if set, would return a true or false when asked. For example, a module might check if the deposit is coming from a cryptopunk holder. Or from a veYFI tokenholder. Or from a KYC'd account. Or in a simple whitelist.

Thoughts?

storming0x commented 2 years ago

My first thought, is yearn should avoid adding it to the design because it seems like something that can be used to censor existing vaults, but if you start the vault as permissionless, you shouldnt be able to switch it to a blocked/whitelisted one

V2 initial versions had this for intention of restricting deposits in testing, but later removed since it was mostly never used in practice.

Adding this feature for unknowing folk, can see it as a way to send a ruling to prohibit or block in the software certain addresses with could be a never ending whack a mole show, i rather yearn leaves it up to integrators to restrict t at the UI level and not leave it possible at all in the protocol.

Just having the term in the codebase may prompt misinformed persons to think its possible, even if we code it in a way that you can't enable/disable it after the fact

jmonteer commented 2 years ago

Good points.

So whitelist should be something that either you add or you can't never add in the future. That way, when a vault is permissionless, there's no way to make it permissioned.

Regarding your point re restricting at UI level, that's not possible. Either you restrict at deposit contract or you can't. That's the reason I want to add it here.

Lastly, I wouldn't care much about disinformed people. They will get it wrong no matter what.

jmonteer commented 2 years ago

moving (potential) discussion to #79