[Proposal] Update access control for proxy manager & pool factory

Proposals
#1

Update access control for proxy manager & pool factory

Summary

The final step required to enable the Sigma program is to grant the Sigma committee limited access over two existing contracts - the pool factory and the proxy manager.

Motivation

In order to build out new pools for the Sigma program, we will need many new smart contracts, most of which will likely be used more than once. We already have a system in place for deploying proxies and handling upgrades, but it only allows the Indexed timelock to add new base implementations or approve new pool controllers. Since the purpose of the Sigma program is to speed up the pace of development, we should allow the Sigma committee to execute certain functions on the existing contracts, rather than complicate our architecture by setting up a myriad of new factories.

Access Control Changes

This proposal will transfer ownership of the pool factory and the proxy manager to separate access control contracts. These new contracts simply define a new administrator role, which is then granted access over specific functions. The Indexed timelock will still be the owner of these access control contracts and will have the sole authority to grant and revoke administrator access.

Below are the new privileges that will exist for the admin and owner roles. All admin privileges are shared by the owner.

Proxy Manager

Admin Privileges

  • Deploy new one-to-one proxies
  • Deploy new many-to-one proxies
  • Add new many-to-one implementation contracts
  • Grant many-to-one deployment access to contracts

Owner Privileges

  • Modify & lock one-to-one proxy implementations
  • Modify & lock many-to-one proxy implementations
  • Transfer ownership of the proxy manager
  • Revoke many-to-one deployment access from contracts
  • Grant admin role
  • Revoke admin role

Pool Factory

Admin Privileges

  • Grant deployment access to contracts.

Owner Privileges

  • Revoke deployment access from contracts.
  • Grant admin role
  • Revoke admin role
  • Transfer ownership of the pool factory

Deployments

Pool Factory Access Control
https://etherscan.io/address/0xb8fdBd8D10b394f85F777969564b6D49D6EbAAA2#code

Proxy Manager Access Control
https://etherscan.io/address/0x3D4860d4b7952A3CAD3Accfada61463F15fc0D54#code

For both of these, I deployed the access control contract, added the Sigma committee’s multisig as an administrator, then transferred ownership to the Indexed timelock.

#2

Background: Contract Architecture

Proxy Manager

The proxy manager is our on-chain deployment hub - it enables several key functions that simplify the architecture for Indexed Finance, enable protocol upgrades and reduce costs. The proxy manager has a single owner, which is currently the Indexed timelock contract.

Many-to-one proxies
The owner can create a new base implementation for a contract that is shared by many other contracts. For example, we have an IndexPool implementation contract which DEFI5/CC10/ORCL5 all use.

The owner can upgrade a base implementation and thus modify the functionality for all the proxies using it. It can also lock the implementation, which disables future upgrades.

The owner can also approve deployers, which can deploy many-to-one proxies, but not modify their implementations. For example, the pool controller used for DEFI5/CC10/ORCL5 is an approved deployer, which allows it to deploy proxies with implementations managed by the owner.

One-to-one proxies
The owner can deploy new one-to-one proxies, which are for singleton contracts where we won’t be deploying multiple versions of the same template. The owner is the only contract which has the ability to deploy one-to-one proxies.

Like many-to-one proxies, one-to-one proxies can be upgraded by the owner to use a new implementation, and they can be locked so that they are no longer upgradeable.

Pool Factory

The pool factory is simply a wrapper for deploying pools through the proxy manager. It is used to deploy only the actual pool contracts, rather than peripheral contracts, and it serves as a hub for off-chain aggregators to watch for new pools, and for on-chain contracts to verify whether pools have been deployed through Indexed. For example, the staking rewards contract verifies that a token address is an index pool deployed by the pool factory before allowing it to be used for staking rewards.

The pool factory has an owner which is the Indexed timelock contract. The owner is able to approve individual pool controllers, which are then allowed to deploy pools.

1 Like
#3

Think it’s obvious I’m in favour of both of these. :wink: