# Governance Implementation for *The Return of the Jedi* & *The Republic* by Aragon 🦅

Based on the governance design provided and clarified in previous posts


we propose the following governance implementation using [Aragon OSx](https://aragon.org/aragonosx), 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 two 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](https://discourse.aztec.network/t/the-republic-a-flexible-optional-governance-proposal-with-self-governed-portals/609) and [The Return of the Jedi](https://discourse.aztec.network/t/the-return-of-the-jedi/744) 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](https://devs.aragon.org/docs/osx/how-it-works/core/dao/). 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](https://devs.aragon.org/docs/osx/how-it-works/core/dao/actions)). 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](https://devs.aragon.org/docs/osx/how-it-works/core/permissions/)). 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](https://discourse.aztec.network/t/the-republic-a-flexible-optional-governance-proposal-with-self-governed-portals/609) and [The Return of the Jedi](https://discourse.aztec.network/t/the-return-of-the-jedi/744) 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](https://discourse.aztec.network/t/the-republic-a-flexible-optional-governance-proposal-with-self-governed-portals/609) and [The Return of the Jedi](https://discourse.aztec.network/t/the-return-of-the-jedi/744), 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.