Optional DAO Admin

[JakeHartnell]

Use case: SubDAOs where the parent DAO wants to maintain control over the child DAO.

This should probably go into the core DAO contract. Now some DAOs will not have any admin, but something like ExcuteMsg::AdminExecuteProposal could be very useful if a hierarchy is needed between a main DAO and its SubDAOs.

There could additionally be an UpdateAdmin only callable by the current admin.

[elsehow]

Some questions (maybe obvious to those whose heads have been deeper in the v1 contracts):

• Is it the case that all "top-level" DAOs will have no admin?
• It is my assumption that a sub-DAO's admin will be the parent DAO. Is that correct?
• What does it mean to be an Admin? What can an Admin do?
• Is there ever a case when something other than a DAO would be a DAO's admin?

[JakeHartnell]

Some questions (maybe obvious to those whose heads have been deeper in the v1 contracts):

• Is it the case that all "top-level" DAOs will have no admin?

Yes.

• It is my assumption that a sub-DAO's admin will be the parent DAO. Is that correct?

Yes. That is the intention.

• What does it mean to be an Admin? What can an Admin do?

Admin can execute messages directly on the SubDAO. Effectively, the parent telling the child to do something, bypassing the proposal process.

• Is there ever a case when something other than a DAO would be a DAO's admin?

The intended usecase is for a DAO to be the admin.

You could have a multisig committee or even an individual serve as an admin. There is a lot of power in the hands of an admin, so their could also be another smart contract that serves as an admin (setting rules around when this power can be used).

Some SubDAOs may not have an admin.

[elsehow]

Admin can execute messages directly on the SubDAO. Effectively, the parent telling the child to do something, bypassing the proposal process.

It sounds like, in our expected usecase, a proposal the parent DAO passes can override any governance function in the subDAO. Is there ever an instance where a subDAO should have functions the parent DAO cannot override? Elegance heuristic tells me "no," but figured I might as well ask the question.

[JakeHartnell]

Admin can execute messages directly on the SubDAO. Effectively, the parent telling the child to do something, bypassing the proposal process.

It sounds like, in our expected usecase, a proposal the parent DAO passes can override any governance function in the subDAO. Is there ever an instance where a subDAO should have functions the parent DAO cannot override? Elegance heuristic tells me "no," but figured I might as well ask the question.

For this you would use a proxy contract that would enforce the rules of the relationship. For example, limiting the message types that the parent can execute.

[elsehow]

For this you would use a proxy contract that would enforce the rules of the relationship. For example, limiting the message types that the parent can execute.

Are you imagining that the proxy contract ("constitution" contract) would be the admin?

[elsehow]

Another thought: how do we manage #178?

• Dumb option: Search through every deployed contract, find DAOs whose admins are our DAO.
• Inelegant option: Maintain a list of SubDAOs somewhere in the DAO contracts, updating it manually via governance props.
• Smartest (?) option: Do not worry about maintaining a list of SubDAOs.

[whalelephant]

a proposal the parent DAO passes can override any governance function in the subDAO

In the design for a Vectis subdao, @egidiocasati and I had discussed having default execution by the ParentDAO iff child DAO members objection votes do not reach a threshold. This can be a separate proposal module.

In the dimension of when can something execute, this can still allow some level of sovereignty for the subDAO.
In the dimension of what can be executed, this should work with the proxy contract to limit parentDAO control.

[elsehow]

default execution by the ParentDAO iff child DAO members objection votes do not reach a threshold

In the Cosmos SDK, delegators can override their validator's votes. As mentioned in #285, we should emulate the Cosmos SDK whenever possible and wherever it doesn't conflict with our goals.

However, after some thought: a delegator's relationship to their validator is not a perfect analogy for a SubDAO's relationship to its Parent DAO. If anything, the analogy is more like this: a Parent DAO delegates (authority over some scoped concern) to the SubDAO. By that analogy, the Parent DAO should be able to veto any decision the SubDAO makes. Like a validator cannot "override" their delegate's vote, the SubDAO cannot "override" their ParentDAO's vote.

The admin address functionality we describe already would achieve this functionality.

After thinking about it some more, I think the most technically simple thing to do is the admin contract without a SubDAO's ability to override. Willing to hear arguments to the contrary, though.

[whalelephant]

If anything, the analogy is more like this: a Parent DAO delegates (authority over some scoped concern) to the SubDAO.

This is a form of relationship between SubDAOs and their parents. However, there may be different forms that the SubDAO feature can support for synergy. For example, a software (parent) that supports different plugins (SubDAO). In this case, members of the subDAOs will also be members of the DAO but not vice-versa. This means that the parent has members that has nothing to do with some of the subDAOs and should not be able to have complete veto power over them.

[elsehow]

@whalelephant, @janitachalam and I talked about this earlier today, but I'm realizing from @whalelephant 's comment above that the design space for how to model SubDAOs is substantially bigger than I previously imagined. I propose we pick this thread back up after we understand what models other DAO tools have supported and, after mulling those over, decide what models we want to support for v1.