A Decentralized Guardian Setup: How MetaMorpho LPs Veto Risk Curator Actions
Intro
B.Protocol and Block Analitica recently announced their partnership to become risk curators on the new MetaMorpho lending platform, starting with Flagship ETH and USDC vaults, with more coming later.
Liquidity Providers (LPs) will be able to deposit their funds into the vaults to gain passive income based on risk exposures co-curated by the two leading risk management teams. The risk curators will allocate the funds into Morpho Blue markets, optimizing the yield-risk ratio.
MetaMorpho vaults include a Guardian role which can secure the funds in the vault in cases where the Owner or the Curator of the vault were compromised and/or act maliciously.
We give the LPs of our vaults the control over the Guardian role as a way to secure their funds. For that purpose we implement a decentralized veto mechanism that is based on existing governance tools and grants LPs the ability to vote and execute on-chain transactions to block malicious acts.
In this post, we will present the core principles that guided us in this process, the security model of the setup, and give an overview of how to set up the tools involved in a way that gives LPs control over the Guardian role of a MetaMorpho vault.
Background
Each MetaMorpho vault has four distinct roles to help govern the vault: Owner, Curator, Allocator, and Guardian. Only the Owner and the Curator can list new markets and increase the supply cap of a market, while the Allocator can only change the allocation of the vault’s funds between its listed markets.
The Curator is responsible for choosing the Morpho Blue markets to which the vault will allocate liquidity and determining the extent of that allocation by setting supply caps for each market. From a technical perspective, a market is listed by establishing a supply cap greater than 0.
As Morpho Blue is permissionless, anyone can list any market on Blue. This exposes the vault’s LPs to the risk of losing their funds through a malicious asset listing, or by setting a supply cap too high by the Curator of the vault.
For this reason, the Guardian role is one of the most important roles in the vault’s governance, as it can revoke specific actions that can jeopardize the safety of funds, such as attempts to increase the supply caps of a market among a few other operations.
As risk curators, we want LPs of a MetaMorpho vault we manage to have control over the vault’s Guardian, so they can safeguard their funds by vetoing pivotal modifications to the vault. To achieve this, we have implemented a decentralized setup that gives LPs control over the Guardian role.
The Guardian Role
The Guardian has control over these 4 functions
- revokePendingCap — canceling an increase in the supply cap of a market.
- revokePendingMarketRemoval — canceling the removal of a listed market that still contains vault deposits.
- revokePendingGuardian — canceling a change of the existing guardian.
- revokePendingTimelock — canceling a decrease in the time lock required for the 3 operations above.
Revoking a `Pending Cap` and a `Pending Market Removal` are straightforward ways for the Guardian to monitor and cancel changes that can compromise the vault’s funds. The changing of the guardian itself and the changing of the required timelock for doing any of the other changes can be considered as “meta-security” actions, preventing the removal of the existing Guardian with a malicious one, or listing malicious markets on short notice. It’s important to note that MetaMorpho has a minimum of 1 day hardcoded into its timelock, so active users can withdraw their funds.
Security model
Each of the 4 roles mentioned above has different permissions within a MetaMorpho vault. This creates hierarchical combinations of the outcomes in case a security breach has occurred (e.g. the Owner multi-sig got compromised).
The main concerns are -
- In case the Owner of a vault is compromised — the funds in the vault are at risk. An active Guardian can prevent it.
- In Case the Curator is compromised — the funds in the vault are at risk. An active Guardian can prevent it. Also, the Owner can replace the Curator.
- In case the Guardian is compromised AND the Owner is compromised — the funds in the vault are at risk. A passive Guardian may be considered as compromised.
- In case UMA’s optimistic oracle and/or the oSnap module are buggy or malfunctioning — the Guardian under this setup is considered to be passive. e.g., compromised.
- An active user can always withdraw funds in case of a security breach, as MetaMorpho has a minimum of 1 day delay hardcoded to its timelock.
Below you can find a summary of all the potential security combinations and their outcomes -
X — Compromised/Malicious
V — Not Compromised/Malicious
*The results are the same for the Curator state but as the Owner can replace the Curator it has no additional outcomes.
** The results are the same in case the oSnap module (or the UMA optimistic oracle) is buggy or malfunctioning, as it will make a passive Guardian under this setup.
The following setup will set the LPs of a vault as its Guardian, without the ability of anyone to change the setting, including a compromised or malicious Owner. LPs will be able to vote off-cahin using their yield-bearing LP tokens received for depositing funds into the vault, and execute transactions to block the malicious actions.
The Setup
The setup design had to create a decentralized veto mechanism in order to prevent any changes from being made in later stages by any other vault actor including the Owner.
We used a combination of Snapshot with an oSnap module built by the UMA team for Zodiac on a Safe wallet. This setup enables the creation of a Snapshot Space, where the voting token is the MetaMorpho Vault’s LP token, which together with the oSnap module can execute an on-chain transaction that interacts with the Vault’s Guardian.
As each Snapshot Space requires an ENS (or a sub-ENS) domain, the setup also includes the handling of the ENS that controls the Space.
Once the system is set up, we renounce control of each tool included in it by transferring ownership to a null address (0xeee…), leaving the LPs with control over the Vault’s Guardian.
Here are the details -
Snapshot Space
- Open a new Space with an ENS domain (or sub-ENS to keep continuity of the Vaults’ space names)
- Under “Strategies” — Set the Vault’s LP token as the single voting token of the space. This requires a wrapper contract around the LP vault token to calculate the voting power as a percentage of the current total supply of LP tokens (as the supply is dynamic and Snapshot requires a token’s amount). You can find a testnet example here.
- Under “Proposal” — Use the Basic strategy to set the minimum of the Vault’s LP tokens that is required to open a proposal to minimize spam and malicious votes.
- Under “Voting” — Set the parameters required for the voting period and the quorum required to pass the vote. Pay attention that these settings should be aligned with the settings in the oSnap module (see below).
- Under “Advance” — Add the Gnosis Safe oSnap as a plugin, using the oSnap contract that is connected to this Space’s vault.
Sub-ENS domain
- We opened a new ENS and transferred the ownership to a smart contract. The smart contract cannot do anything else other than opening new sub-ENS domains, preventing any option for the parent ENS to make changes in the Snapshot Space settings, including changing its controller or deleting it (permissions a parent ENS holds over a space).
- We used the sub-ENS to open a new Snapshot Space, keeping it consistent with other MM vaults’ space names for easier tracking of relevant Spaces.
- As the sub-ENS is the controller of the Snapshot Space of the vault, once the setup of the Space is completed (see above), we transfer ownership over the sub-ENS to a null address to prevent making any changes to the space.
Zodiac oSnap UMA module
- The oSnap module built by UMA enables a Gnosis Safe to execute a transaction triggered by an off-chain Snapshot vote that passed under specific criteria.
- The oSnap setup includes parameters required for the Bond (token, size, duration) and the Vote (duration, quorum) to be considered valid.
- Each oSnap is integrated into a specific Snapshot Space by the Space’s unique URL.
- After setting the oSnap and adding it as a plugin to the Snapshot Space (see above), we have transferred ownership of the Safe to a null address as well, so no changes could be made to the oSnap settings and no txs can be initiated by anyone other than the oSnap module.
- You can find a tutorial for setting up an oSnap module here.
MetaMorpho Guardian
- Once everything is set, the Safe address with the above oSnap module is set as the Guardian of the MetaMorpho Vault, leaving only the LPs with control over it, without the ability to make any changes to it.
Here’s a summary list of parameters required for this setup and a tentative suggestion on how to set them -
*The 4 days time lock on the vault gives an extra day for the LPs to execute the vetoing tx once the proposal has passed.
A list of ownership over each of the setup components -
Conclusion
We propose this setup for MetaMorpho risk curators who wish to give their Vault’s LPs control capabilities over their own actions. With the above setup for the Guardian to be controlled by the LPs, risk curators can reassure potential depositors they have a way to monitor and take required actions in case of malicious or reckless acts made by the owner and/or the risk curator of the vault.
It’s important to note that LPs can withdraw funds once a time lock is triggered and that the above setting should be considered a last resort as long as the risk curators are not malicious or compromised.
We will share a tutorial for LPs on how to create a proposal and vote in a separate post.
We wish to thank the Snapshot team and the UMA oSnap team for their support during this integration process.
If you have any feedback or suggestions on this setup please reach out to us over Discord.
About B.Protocol
B.Protocol has been building open-source protocols and infrastructure for risk mitigation and assessment for the DeFi ecosystem since 2020. Through our research arm, RiskDAO, and its novel risk framework, we have supported over a dozen DeFi protocols with risk analysis, research, audits, and monitoring. Our Risk Oracle and SmartLTV formula automate the process of setting risk parameters for lending platforms in a transparent way, building the next generation of DeFi risk management infrastructure.
