Governance Implementation for The Return of the Jedi & The Republic by Aragon ![:eagle: :eagle:](https://emoji.discourse-cdn.com/twitter/eagle.png?v=12)
Based on the governance design provided and clarified in previous posts
we propose the following governance implementation using Aragon OSx, our new, modular governance framework:
For simplicity, only relevant state variables, functions, and parameters are shown.
Next, we present details on our proposed implementation.
On-chain Governance
The on-chain governance consists of three contracts
CitizenAssembly
Senate
DAO
and two sets of actors
- Citizens
- Senators
The DAO
contract is created through the standard Aragon OSx DAOFactory
, which allows you to select (multiple) plugins adding functionality to your DAO.
For Aztec, Aragon would provide an AztecGovernance
plugin comprised by a CitizenAssembly
and Senate
contract. An associated AztecGovernanceSetup
contract would deploy the CitizenAssembly
and Senate
contract and establish the permission relations between them and the DAO
contract. This allows the Aragon OSx PluginSetupProcessor
to set up the plugin. To build the plugin, we can re-use existing functionality from our TokenVoting
, AddresslistVoting
, and Multisig
plugin.
Because the difference between The Republic and The Return of the Jedi lies on the protocol part, the on-chain governance implementation we propose can be used in both designs.
CitizenAssembly
In contrast to the original design, we propose the CitzenAssembly
contract as a second governance body, allowing the citizens to exert their powers on the Senate
. We did this to clearly separate the governance logic involving the citizens from that of the Senate
on the contract level. Although we prefer this separation from an architectural standpoint, the CitizenAssembly
logic can be incorporated into the Senate
contract as well without any change in behavior.
State
address dao
: The address of the associated DAO (required access the DAO permission manager).Proposal[] citizenAssemblyProposals
: a list of proposals that token holders create and vote on in theCitizenAssembly
Functionality
createReelectionProposal(address[])
: Creates a proposal to reelect the senators. Upon approval and execution, thesetSenators(address[])
function in theSenate
contract is called.createSenateProposal(Action[])
: Creates a proposal (AZIP) containing defined actions to be voted on in theSenate
contract. Upon approval and execution, thecreateProposal(Action[])
function in theSenate
contract is called.createEmergencyStateProposal(bool)
: Creates a proposal to turn the emergency state mode on and off. Upon approval and execution, thesetEmergencyState(bool)
function in theSenate
contract is called.
Calling the three functions in the CitizenAssembly
requires you to be citizen (i.e, a token holder) and custom conditions can be added on top (e.g., minimum number of tokens held).
Senate
The Senate
contract allows the senators to exert their powers of approving and executing AZIPs coming from the CitizenAssembly
through the DAO
executor.
State
address dao
: The address of the associated DAO (required access the DAO permission manager).address[] members
A list of senator addresses.Proposal[] senateProposals
: a list of proposals proposed by theCitizenAssembly
for the senators to vote on.
Functionality
setSenators(address[])
: Sets the senator addresses. This function is guarded by theSET_SENATORS
permission being granted only to theCitizenAssembly
contract.createProposal(Action[])
: Creates a proposal for theSenate
. This function is guarded by theCREATE_PROPOSAL
permission being granted only to theCitizenAssembly
contract.setEmergencyState(bool)
: Moves theSenate
into/out of the emergency state. This function is guarded by theCREATE_PROPOSAL
permission being granted only to theCitizenAssembly
contract.vote(proposalId)
: Allows senate members (senators), to vote on a proposal. The details of the voting process (vote duration, delays, etc.) settings are customizable to the needs of the Aztec’s community. Features can potentiallybe added through follow-up updates.executeProposal(proposalId)
: Allows senate members (or optionally everyone) to execute a proposal.
DAO
The DAO
contracts is the identity and account of your on-chain governance system. Besides other, essential functionalities, it allows you to execute arbitrary actions, manage permissions, and validate signatures.
Functionality
execute(Action[])
: A non-reentrant executor allowing to execute genericAction
calls (see the section on Action execution in our dev portal). This function is guarded by theEXECUTE
permission being granted only to theSenate
contract.grant(Permission)
/revoke(Permission)
: Grants/revokes permissions (see the section on Permissions in our dev portal). This function is guarded by theROOT
permission being granted only to theDAO
contract itself (and temporarily to thePluginSetupProcessor
during the setup of the plugin). Throughexecute(Action)
, theDAO
can call the function itself.
Protocol
The protocol part is immutable, independent of the on-chain governance part, and will be developed by Aztec. This is also the part where architectural differences between The Republic and The Return of the Jedi can be found.
However, the connection between the on-chain governance and the protocol part is equivalent, as the interaction occurs between the DAO
and the Registry
in both cases.
Registry
Although there are differences between The Republic and The Return of the Jedi, the connection between the on-chain governance and the protocol part is identical: Through the DAO
contracts execute(Action[])
function, the Senate
has the ability to call the setGasPricing(address)
and setSequencerSelection(address)
in the Registry
contract to set the implementations that the StateTransitioner
contract will then interact with. No other address than the DAO
is allowed to call the Registry
setter functions, which is achieved through onlyOwner
modifiers.
We propose that the Registry
should have a setOwner(address)
function allowing it to change the owner to another address. Furthermore and in case the Senate
is corrupted, we suggest putting a mechanism in place allowing the CitizenAssembly
to call the setOwner(address)
function through the DAO, thus bypassing the Senate
and in case the emergency state was triggered.
Social Coordination
Technical/Jedi Council
As clarified in a previous post, the technical/Jedi council has an informal role. Councillors/Jedi are nominated by the citizens, inform the senate and deploy new contract implementations of the GasPricing
and SequencerSelection
contracts that the senate can set through the DAO.
Considerations on Upgradeability
Aragon OSx DAOs are upgradeable by default. The DAO upgradeability can be disabled permanently or time-locked.
Aragon OSx plugins can be upgraded or replaced by other plugin implementations, and we designed a complete lifecycle around it (i.e., installation, updates, uninstallation). Plugin developers can provide newer versions (containing security patches or feature additions) that DAOs can upgrade to. Again, you can opt out of this system by permanently disabling or time-locking this functionality.
I am happy to receive feedback and discuss improvements.