Add Tribal Council and Optimistic Governance pods#582
Add Tribal Council and Optimistic Governance pods#582thomas-waite merged 45 commits intofeat-governance-upgradefrom
Conversation
| /// @param minDelay Delay on the timelock | ||
| /// @param publicExecutor Non-permissioned smart contract that | ||
| /// allows any address to execute a ready transaction | ||
| function createOptimisticTimelock( |
There was a problem hiding this comment.
what about vetoing? The "cancel" functionality should be exposed by some kind of veto controller and veto tribe role imo.
There was a problem hiding this comment.
Imagining a contract like the PublicExecutor called the VetoController which stores a mapping of which addresses can veto which pods or which roles can veto which pods and exposes the "cancel" functionality through them.
There was a problem hiding this comment.
Probably not required for this MVP
There was a problem hiding this comment.
Love it, was breaking this out into a seperate PR to ease reviewing load.
More broadly, torn whether it makes more sense to include in one PR - so you get a wholistic overview, but arguably harder to review - or whether these things should be piecemeal in smaller feature PRs
|
|
||
| /// @notice Validate that a member can be removed from a pod by the admin | ||
| /// Note: Orca sets the memberTokenID to be the podId | ||
| function testRemovePodMember() public { |
There was a problem hiding this comment.
how would the DAO remove a pod member?
There was a problem hiding this comment.
PodAdmins can remove pod members.
The DAO is the podAdmin of the TribalCouncil so can remove members from the TribalCouncil by calling memberToken.burn(memerToRemove, podId) (there's an e2e test validating this)
The TribalCouncil in turn is the podAdmin of child pods. It in turn can remove any member from a childPod by calling the burn function.
There isn't a direct way at the moment for the DAO to remove members from child pods - it's devolved in this implementation to the TribalCouncil. Is that something we want to add?
There was a problem hiding this comment.
The DAO absolutely should have the ability to remove members of child pods imo
There was a problem hiding this comment.
Agreed. Individual pods only support one podAdmin address - adding another PR to make the podAdmin a smart contract, which itself will have a relaying method exposed to the intended pod admin as well as the TribeDAO.
In this way, we can have the podAdmin (Tribal Council) and TRIBE DAO able to add/remove members
thomas-waite
force-pushed
the
feat-deploy-pods
branch
from
3b7afb7 to
54d073c
Compare
xklob
left a comment
xklob
left a comment
There was a problem hiding this comment.
Overall looks great! Are we importing a bunch of stuff from Orca by copying-pasting? If so, can we use git submodules instead?
4 participants
Summary
Introduces
OptimisticGovernancePodsto the protocol. Specifically adds theTribalCouncil, a candidate base pod, factories to deploy both and make the process more scaleable/manageable and an FIP script together with e2e tests.There is further functionality that will be added in seperate PRs:
Timelock details
In general, the more executive and powerful a contract or role, then the longer the associated timelock should be. As pods get more and more specific and isolated timelock requirements should decrease.
Specifically: