# Index Coop Onchain Governance

## Table of Contents

[TOC]

## Background

In [IIP-170: Modify the Organization Structure](https://gov.indexcoop.com/t/iip-170-modify-the-organization-structure/4468), Index Coop created a Safe called the "Delegate Safe" that was designed to implement approved changes from offchain votes on Snapshot. Particularly, the Delegate Safe will make changes to the representatives of Engineering, Treasury, and Operations Pods in the event of a successful vote. The Delegate Safe was designed to be a temporary measure until Index Coop could implement onchain governance whereby tokenholders would be able to make these changes directly.

This document outlines the path for Index Coop to create a Governor Contract and a Timelock Contract which will become the "Manager" of the aforementioned Pods.

## Overview of Governance Contracts

The OpenZeppelin governance contracts are a suite of modular, extensible, and secure smart contracts designed to facilitate the implementation of on-chain governance in decentralized protocols and organizations. The documentation provides an overview of the main components and features of these contracts, which can be customized and combined to suit various governance needs.

Key components and features of OpenZeppelin's governance contracts:

**Governor:** The core contract that handles the creation of proposals, voting, and execution of actions. It is designed to be modular and extensible, allowing for the addition of new features or modifications.

**Governor Timelock:** An optional component that introduces a time-lock mechanism for executing actions, adding a delay between the approval of a proposal and its execution. This allows for increased security and an opportunity for the community to react if a malicious proposal is approved.

**Counting strategies:** A set of contracts that define how votes are counted and proposals are approved. The available strategies include simple majority (GovernorCountingSimple) and more complex mechanisms such as quadratic voting.

**Voting power:** OpenZeppelin governance contracts provide the flexibility to define voting power based on different factors, such as token balance (GovernorVotes), token time-locked (GovernorVotesTimeLock), or a combination of factors.

**Delegation:** The governance contracts support vote delegation, allowing token holders to delegate their voting power to others, who can vote on their behalf. This feature can be customized based on the specific requirements of the organization or protocol.

**Compatibility:** OpenZeppelin's governance contracts are designed to be compatible with various token standards (e.g., ERC20, ERC721, and ERC1155), allowing for seamless integration with existing projects.

## Implementation Decisions

Index Coop currently uses the INDEX token for governance on Snapshot, however, in order to migrate to onchain governance, there will be several additional steps. Because the [INDEX Contract](https://etherscan.io/address/0x0954906da0bf32d5479e25f46056d22f08464cab#code) is not upgradable, there will need to be a wrapper around the INDEX token. Wrapped INDEX will be able to integrate with Governor Contract, but it will require existing INDEX holders to stake or wrap their INDEX in exchange for wINDEX.

Index Coop will need to deploy three contracts:

1. **Staking Contract:** The staking contract will allow users to deposit INDEX and receive vw to autocompound their rewards and wINDEX should be equal to INDEX. This provides some benefits like allowing INDEX to trade on CEXs since there will be no value accrual to these holders.
2. **Governor Contact:** The core OpenZepplin Governor contract handles the creation of proposals, voting, and execution of actions. It is designed to be modular and extensible, allowing for the addition of new features or modifications.
3. **Timelock Contract:** This contract introduces a time-lock mechanism for executing actions, adding a delay between the approval of a proposal and its execution. This allows for increased security and an opportunity for the community to react if a malicious proposal is approved.

The Governor Contract can be configured using this [OpenZeppelin Wizard](https://wizard.openzeppelin.com/#governor) and it should be configured with the following settings:

| Setting | Current | New |
| -------- | -------- | -------- |
| Proposal Threshold | 1,000 INDEX | 10,000 wINDEX|
| Quorum | 10% of INDEX | 5% of wINDEX|
| Voting Period | 3 days | 5 days |
| Voting Delay | 0 days | 1 day|
| Timelock Delay | n/a | 7 days |

The parameters are a balancing act between ease of passing proposals and security against malicious proposals.

Below is [guidance from Tally](https://docs.tally.xyz/user-guides/deploying-governor-daos/pick-good-governor-parameters) on how to pick good Governor parameters:

* **Proposal Threshold** should be set somewhere between 0% and 2% of circulating token supply. Note, that in this case it will be dependent on the wINDEX supply. This consideration will also affect quorum.
* **Quorum** depends on voter turnout, usually somewhere in the range of 1-10% of circulating token supply. Since participants need to opt-in to voting by deposit INDEX in the staking contact, quorum can be higher as a percentage of supply.
* **Voting Period** is usually between 3 and 7 days, giving everyone time to review a proposal.
* **Voting Delay** is usually 0, but if there is a delay, it is usually one day or less. A delay gives token holders time to delegate their voting power before the vote starts or buy more votes.
* **Timelock Delay** is usually 0 for Governors that only manage a treasury, but for those that control a DeFi protocol, the delay is closer to 7 days.

## Implementation Process

1. **Deploy the Staking contract & wINDEX token contract**
2. **Deploy the Governor contract**
3. **Deploy the Timelock contract**
4. **Integrate the Timelock with the Governor**: Update the Governor contract to use the Timelock as the executor for approved proposals.
5. **Enable vote delegation:** Configure the Governor contract to support vote delegation, allowing token holders to delegate their voting power to others.
6. **Set the Governor Contract as the Manager**: In [Metropolis ](https://pod.xyz/podarchy/index-delegates), add replace the index-delegates.pod.xyz with the Timelock contract address as the manager of the Engineering, Treasury, and Operations pods.
7. **Set up Tally**

## Additional Consideration

### Governance Use-Cases
Onchain governance needn't be limited to just changing signers on the Engineering, Operations, and Treasury pods, however, it does seem like the most reasonable use case to start. In the future, it may be beneficial to attach onchain governance to other aspects of Index Coop.

These include, but are not limited to:
* Allowing for token holders to object to new rebalance weights and having a resolution process in that case
* Direct control over the Treasury's reserves(ie, index-treasury-investment.pod.xyz)
* Adding a module or adapter to Index Protocol

### wINDEX Use-Cases

It must be stated that the need for wINDEX is a sub-optimal user experience, however, there are some benefits. One example is that wINDEX will force users to opt-in to governance giving a much more accurate circulating supply.

Additionally, the Staking Contract could be used in a future proposal as a way to distribute revenue to token-holders. One method for this could be to use a portion of revenue to buy back INDEX and distribute it to wINDEX holders. wINDEX could become a rebasing token that rebases whenever new INDEX is added to the staking contract from revenue sales.

### Metagovernance

While it still would require more research, it appears that metagovernance votes could be executed automatically.

## Other Explored Solutions

Instead of wrapping the INDEX token, it is possible to use the Gnosis Zodiac Governor module which would turn a Safe into a Governor, however, the INDEX contrac does not appear to be ERC20Votes compatible. While it includes some voting functionality, it is not the same as the ERC20Votes extension from the OpenZeppelin library.