# Governance Process
Our governance process works exactly the same as Compound's. [Their documentation about the timelock](https://compound.finance/docs/governance) has nice diagrams and a good explanation of the process.

# Access Control

## Committee Proxy
The committee proxy is owned by the Indexed Timelock.
The owner can change the admin address.

The committee proxy has an admin, which is the committee multisig.
The admin can execute arbitrary transactions.

## Committee Timelock
The committee timelock has an admin, which is the committee multisig.
The admin can queue transactions, which the timelock can execute after 7 days.

The committee timelock has a superuser, which is the Indexed timelock.
The superuser can execute anything on the committee timelock, including external calls, canceling transactions and changing the admin, without waiting for the transaction delay.

The committee timelock will hold 600k NDX tokens.

## Pool Controller

The pool controller can deploy new index pools, which it will be the controller of.
Index pools are deployed through the proxy manager.
Each index pool has one `UnboundTokenSeller` and one `PoolInitializer`, both of which are deployed as proxy contracts.

The pool controller is owned by the Committee Proxy, meaning it is controlled by the committee multisig, but the Indexed Timelock can override the multisig address.

## Proxy Manager
The proxy manager can deploy two types of proxies: one-to-one (1T1) and many-to-one (MT1).
Many-to-one proxies use a single proxy implementation for many proxy contracts.
One-to-one proxies use a single proxy implementation for a single proxy contract.
Proxies can be locked to disable changes to their implementations.

The proxy manager has an owner, which is allowed to do the following:
- Add new proxy implementations (runtime code storage) for MT1 proxies (mapped to specific IDs)
- Deploy new 1T1 proxies with any implementation address
- Modify proxy implementations for MT1 and 1T1 proxies.
- Lock proxy implementations.
- Approve proxy deployers.

Proxy deployers only have access to the deployment of MT1 proxies with an existing implementation, but not to any of the other functionality in the manager.

The Sigma program will need to give the committee multisig access to these functions:
- Add new proxy implementations for MT1 proxies
- Deploy new 1T1 proxies
- Approve proxy deployers

So the new pattern will still only allow the Indexed Timelock to actually modify proxies, but will allow the committee to deploy new proxies.

The way we will do this is with a new proxy owner contract (which has not yet been added).

# Deployment Process

1. Deploy Gnosis safe with committee members as signers.
2. Deploy Committee Timelock with `admin=multisig` `owner=indexedTimelock`
3. Deploy Committee Proxy with `committee=multisig` `owner=indexedTimelock`
4. Deploy proposal with Indexed governance to transfer 600,000 NDX to the committee timelock
5. Deploy new ProxyManagerOwner contract with the new access control scheme described above.
6. Create proposal with Indexed governance to transfer ownership of the proxy manager to the new ProxyManagerOwner.
7. Deploy new proxy implementations:
- `PoolInitializer`
- `UnboundTokenSeller`
- `IndexPool`
- New pool controller
8. Add new proxy implementations to the proxy manager
9. Deploy 1T1 proxy for new pool controller
10. Approve new pool controller proxy to deploy MT1 proxies on the proxy manager