Blacklists for Aragon Apps


#1

In a previous thread where I was analyzing the AGP-1 voting results, I asking if there was a blacklist for voting and @jorge said:

We think implementing an on-chain blacklist for voters is a bad idea as it introduces the meta-governace aspect over the list

And I wanted to create a thread around this to see what people think. Shouldn’t a DAO be allowed to decide if they want to maintain a blacklist? Why is maintaining a whitelist (the Permissions app) a good idea, but a blacklist a bad idea? Isn’t whitelisting also meta-governance?

Hence for ultimate flexibility, wouldn’t it be great if out of the box, all applications can support blacklists, similar to how the Permission manager works works for whitelists? I assume it should just be part of the Permissions manager.

If such a feature existed, it can help with this issue:

Addresses on the blacklist should:

  • For the case of voting, their token balance would not count against quorum and they would not be able to vote
  • Additionally you can make it so they just can’t perform any actions across all of the DAO’s apps or selective apps (in the case of other Aragon apps interacting with each other…)

The other benefits are this can help with reputation-based DAOs, where the DAO has non-transferable tokens. It can be in the DAO’s code of conduct that they should not sell these tokens by wrapping them and selling them. E.g. wrapping your rep token and selling it on the “black market” will render it useless. This means the DAO would have to maintain a list of wrapped rep tokens and then not let these actors participate in the DAO, which is essentially a blacklist. (Question: does the Revoke Token action work for non-transferable tokens? I guess that may be more useful for the reputation use case)

Yes this does add a meta-governance layer, but shouldn’t it be up to the DAO to decide if they want to deal with this meta-governance or not?

I just think it would be great if DAOs who want blacklisting don’t have to fork every app to be able to support it, especially when the concept of whitelisting already exists out of the box.


#2

Generally agree that there is no reason not to support a blacklist other than cost/complexity… but I also don’t think it should be a priority. I struggle to think of a situation where a blacklist would both be effective and necessary–and requiring every application to support some blacklisting standard might be much more complex than it initially seems, in some cases Im not sure it would even be feasible.

I believe so!

This feels like the correct approach and will be much more powerful with proposal agreements and the court in place–as you can have the revoke tokens action protected by a proposal agreement. This wouldn’t require any application to conform or be aware of a blacklist, and would be more powerful as a blacklist can be evaded simply be moving tokens to a new address.