Decentralizing IPOR
Last updated
Was this helpful?
Last updated
Was this helpful?
Progressive Decentralization The IPOR Protocol aims to be fully on-chain and decentralized. This is done via a clear road map for progressive decentralization. There are natural limitations of having complete decentralization at the beginning. Thus from the outset IPOR Labs as the first protocol developer sets itself out to build and iterate on the IPOR index initially with the community's help in a transparent manner to allow for feedback and time before the changes take effect. The project's ethos is outlined in the , which acts as a guideline for protocol development. During the first step IPOR Labs will lead core development decisions in order to maintain a stable protocol launch. In the second step, 3-6 months later, IPOR Labs will create a snapshot voting page to allow the community to vote on modifying IPOR and developing new products. Finally, the IPOR Protocol then plans to mature to a fully community-driven DAO. The smart contracts which have been governed by multisignature by IPOR Labs will be cycled out and distributed to include other DAO members, and complete ownership and control of the IPOR protocol will be decided by governance voting by IPOR token holders. IPOR Labs will continue to participate and make proposals DAO willing; however, the ultimate approval will be in a decentralized manner via the DAO. Over time, IPOR will slowly move towards full DAO governance and ownership over the protocol so that it may be completely community-driven. This includes the DAO treasury and updates to the protocol.
In the initial period, IPOR smart contracts are managed by the IPOR Core Team via the structure consisting of Gnosis Safe, Timelock, and Open Zeppelin Defender.
Each contract allowing for state change by admin (such as pause) or upgrades is owned by a timelock.
0xD92E9F039E4189c342b4067CC61f5d063960D248
Proposers: 0xF6a9bd8F6DC537675D499Ac1CA14f2c55d8b5569 (DAO Multisig Gnosis)
Executors:
0xA21603c271C6f41CdC83E70a0691171eBB7db40A
0xaf7ccC20aC512780b6245ff16aB60174dDEdf306
0x4C849F14fE8F7f880cEAcBd09A4f133c3bFa4b40
0xcd6f959660eEF9873c14f84d4b6893beB0Ab8Ef5
At the inception, the minimum time set on this timelock is 10 minutes. In the initial months from the launch highest priority is set on quick response. As protocol continues to operate and transition to the DAO-run governance model, this timelock will be adjusted to increase the minimum timelock.
Each change to either configuration or implementation of contracts using a proxy is done with the help of OpenZeppelin Defender.
Process of making a configuration change:
Transaction changing contract param is prepared and scheduled using Defender
Multisig collects signatures until a quorum is reached. At this point, the Timelock period is set.
After the timelock has passed, the transaction can be executed by one of the above-listed executors.
Process of update (IPOR contracts often use constants as configuration params and require contract updates to change settings. Those optimizations are due to significant gas optimizations):
The new implementation is deployed
The transaction with changing of the contract implementation behind the proxy is prepared and scheduled using Defender.
Multisig collects signatures until a quorum is reached. At this point, the Timelock period is set.
After the timelock has passed, the transaction can be executed by one of the above-listed executors.
0xF6a9bd8F6DC537675D499Ac1CA14f2c55d8b5569
Signing addresses:
0xA21603c271C6f41CdC83E70a0691171eBB7db40A
0xaf7ccC20aC512780b6245ff16aB60174dDEdf306
0x1d682c7eDC203B8A17dC9b8B96cbf1e2ef5B5645
0xcd6f959660eEF9873c14f84d4b6893beB0Ab8Ef5
0x7E8d6204022F77a75Fe49498E5Dc083D5F22Ad2F
0x684EBbf43FbbD29DaB271b9442D15dF34286D861
Consensus: 4 out of 6 - IPOR Core Team - Engineering, Business