The Return Of The Jedi

Aztec
,
8

Governance Implementation for The Return of the Jedi & The Republic by Aragon :eagle:

Based on the governance design provided and clarified in previous posts

Aztec Draft, annotated.
Aztec Draft, annotated.1920×932 109 KB

we propose the following governance implementation using Aragon OSx, our new, modular governance framework:

Aztec DAO OSx.drawio
Aztec DAO OSx.drawio1058×1564 190 KB

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 the CitizenAssembly

Functionality

  • createReelectionProposal(address[]): Creates a proposal to reelect the senators. Upon approval and execution, the setSenators(address[]) function in the Senate contract is called.
  • createSenateProposal(Action[]): Creates a proposal (AZIP) containing defined actions to be voted on in the Senate contract. Upon approval and execution, the createProposal(Action[]) function in the Senate contract is called.
  • createEmergencyStateProposal(bool): Creates a proposal to turn the emergency state mode on and off. Upon approval and execution, the setEmergencyState(bool) function in the Senate 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 the CitizenAssembly for the senators to vote on.

Functionality

  • setSenators(address[]): Sets the senator addresses. This function is guarded by the SET_SENATORS permission being granted only to the CitizenAssembly contract.
  • createProposal(Action[]): Creates a proposal for the Senate. This function is guarded by the CREATE_PROPOSAL permission being granted only to the CitizenAssembly contract.
  • setEmergencyState(bool): Moves the Senate into/out of the emergency state. This function is guarded by the CREATE_PROPOSAL permission being granted only to the CitizenAssembly 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 generic Action calls (see the section on Action execution in our dev portal). This function is guarded by the EXECUTE permission being granted only to the Senate contract.
  • grant(Permission)/revoke(Permission): Grants/revokes permissions (see the section on Permissions in our dev portal). This function is guarded by the ROOT permission being granted only to the DAO contract itself (and temporarily to the PluginSetupProcessor during the setup of the plugin). Through execute(Action), the DAO 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.

8 Likes