Summary
The following proposal completes the Fluid deployment by transfering ownership of the protocol to governance.
- Transferring ownership to governance.
- Low severity bad deployment issue resolved and new vaults deployment.
- Moving rewards from old vaults to new vaults.
- Setting team multisig as deployer for fToken & vaults.
- Give team multisig access to update rebalancers on reserve contract.
- Setting team multisig as guardian.
- Transferring remaining funds to the DAO treasury.
Proposal
It’s been nearly a week since Fluid launched and in this week we have seen phenomenal growth of Fluid. Over this past week, the team has heavily invested their time in verifying all the contracts deployed, config settings and if everything is working as intended.
We were able to find 1 minor issue which occurred due to bad deployment causing issue in rebalancing ETH vault rewards (detailed below). We are now confident with deployments, config setup and it’s time to transfer the ownership of Fluid to governance.
Transferring ownership to governance
Team has transferred the ownership of entire protocol to governance which includes:
- Ownership of Liquidity Layer.
- Ownership of fToken factory.
- Ownership of vault factory.
- Ownership of reserve contract.
- Ownership of INST staking rewards contracts.
Note: The Old vault factory ownership remains with team multisig.
Low severity deployment issue resolved and New Vaults deployment
Note: This issue does not pose any risk to users or the protocol and users will have no impact on their earned rewards.
The rebalance() function became inaccessible due to a bad deployment. The mismatch in the interface made the function unusable. This function does not affect any markets as its function is limited. The rebalance() function serves 2 purposes:
- Distribute rewards to users (currently, in use in 2 vaults)
- Vault specific fee structure (currently, not in use anywhere)
How did this occur?
The entire vault deployment happened in 2 parts:
- Deployment of admin & main2 module - Main2 module consists of absorb() & rebalance()
- Main module - consists of user & liquidator function operate() & liquidate()
The team successfully deployed the 1st step and then when we reached the 2nd step we faced an error of contract over-sizing (aka contract is very slightly bigger than the max limit allowed). The team decided to remove a piece of code which was not in use, this resulted in a slight change in the interface which now throws an error on the rebalance module. After this update we needed to follow the first step again which we missed and resulted in the issue.
We removed:
bytes32 liquidityTotalSupplySlot;
bytes32 liquidityTotalBorrowSlot;
These 2 params are not in use anywhere in the codebase. However, removal of these variables resulted in a slight change in interface which is the main cause of issue.
As the vault codebase is not upgradable, we have to deploy entirely new vaults which include the deployment fix. For current users of the vaults we will add options to the UI, so users can easily migrate to the new deployment.
Migrating Rewards and Setting Permissions
Moving rewards from old vaults to new vaults
Team has set up and initialized ETH rewards on the new vaults and the rewards in the old vault will end in the next 5 days. The old vaults will be deprecated, however users can still migrate after 5 days.
Setting team multisig as deployer for fToken & vaults
Team multisig is the deployer for fToken & vaults. Deployed fToken & vaults are not usable unless governance lists them on the liquidity layer. So deploying doesn’t possess any risk, it just simplifies the governance process to just focus on listing.
Provide team multisig access to update rebalancers on reserve contract
Rebalancers are EOA accounts which we run for regular automation related tasks for Fluid. The main role of rebalancers is to distribute rewards, this is done in a restricted way by calling the rebalance() function on token & vaults. Even if rebalancers are compromised, these accounts don’t pose any risk to protocol, as rebalancers are restricted to rebalancing only.
Setting team multisig as guardian
Team multisig is set as guardian on Liquidity Layer. Guardian has access to pause Class 0 protocols from having access to liquidity, Class 1 protocols have no impact of the guardian. Currently, both the protocols (lending & vault) are listed as Class 0 protocol which will allow the team to have a prompt response in any unforeseen scenario.
Transferring remaining funds to the treasury
In preparation for Fluid rewards, governance transferred funds to the Instadapp Team multisig. Now that rewards have started, all remaining funds will be transferred back to the governance. The amount returned to the DAO Treasury is 238,654 INST & 8.7513 stETH.
Conclusion
This proposal finalized the transfer of ownership of the Fluid Protocol to the Instadapp DAO and sets the Team Multisig as the deployer and Guardian of the Fluid liquidity layer. the Instadapp Team has redeployed the vaults to resolve a minor issue and has facilitated the migration of rewards and users to the newly deployed vaults.