Earlier this month, the Steakhouse USDC MetaMorpho Vault launched. Currently, the USDC in the vault supplies liquidity to two Morpho Blue markets that have wstETH and Backed’s bIB01 (tokenized T-bills) as collateral. This essentially allows vault depositors to gain passive income from the “dual engine” of crypto and tradfi yields.
This report highlights the drill that Steakhouse conducted to demonstrate that depositors into the vault can protect themselves using the Guardian feature. How? Let’s dive in.
Each MetaMorpho has four distinct roles that help govern the vault:
Owner/Curator (Steakhouse, 2-of-3 multisig): Oversees the selection of Morpho Blue markets to which the vault will allocate liquidity, and determines the supply caps for each of those markets.
Allocator (Steakhouse, 1 EOA): Oversees the allocation of the vault’s liquidity between the selected Morpho Blue markets. It runs an off-chain bot that reallocates liquidity every 15 minutes if needed. Even if compromised, lenders can always remove the liquidity and the owner can remove credentials and restore proper allocation.
Guardian (SteakUSDC depositors): In MetaMorpho, certain actions that could jeopardize the vault’s safety are always timelocked (minimum of 1 day) to protect the depositors. Currently the Steakhouse USDC MetaMorpho’s timelock is 1-day, though it will be extended to at least 7-days soon. Further, the Guardian has the authority to veto pivotal actions, such as external attempts to 1) increase the supply caps of a listed market, 2) delist a market with vault deposits 3) alter the current guardian or 4) reduce the time lock required for the aforementioned operations.
Notice the above structure ensures that vault allocations are executed exclusively within the risk parameters established by the Owner/Curator. In other words, Steakhouse’s role is limited to choosing the Morpho Blue markets and the respective supply caps and allocating the vault liquidity between those markets. By design, Steakhouse has no ability to do more.
But what happens if Steakhouse exercises poor risk management and for instance, adds a Morpho Blue market that is deemed unsuitable by the depositors? Below, we simulate a hypothetical scenario to demonstrate how depositors would be able to protect themselves through the Guardian setup.
Borrowing the recipe from B.Protocol, we set up the Guardian to be a Safe wallet controlled by steakUSDC holders via Snapshot. This is enabled by the oSnap module built by UMA. For more information on how to create a Snapshot vote and execute it, B.Protocol has a helpful tutorial on their previous forum post.
With the setup, we test the defenses.
To simulate a malicious scenario, we create a transaction to remove the Guardian. As mentioned, such critical transactions are behind a timelock, allowing either depositors to withdraw their funds or the Guardian to revoke the change before execution.
To test the system, we initiated a Snapshot vote (anyone with 10k steakUSC can create such a vote) to revoke the proposed change. The holders of steakUSDC (i.e. vault depositors) with decentralized control over the Guardian role would of course want to refuse the change proposed above. To do so, steakUSDC holders vote “FOR” refusing the proposal (TL;DR: In case of malicious actions, you should vote FOR).
In the exercise, the vote achieved a quorum of 50k steakUSDC, surpassing the 10k needed to pass.
Once the off-chain Snapshot vote passes, the oSnap module facilitates the Safe wallet to execute the transaction, subject to a challenge period. The oSnap setup requires a bond and a challenge period to be specified. The bond is the amount that both the submitter of the transaction and the disputer are required to post. In the event of a dispute, the correct party will receive the loser’s bond.
In our simulation, the bond was set at 2000 USDC, which the submitter of the transaction had to post. He/she loses that amount if found to be malicious. The challenge period, lasting 24 hours, allows for open challenges to the Snapshot vote execution.
No one challenged the execution so after 24 hours it was possible to execute the transaction and the MetaMorpho vault logged an event of revocation for the pending Guardian.
While the drill was successful, we noted two areas for improvement.
First, steakUSDC holder participation was quite low as only one holder voted. This is expected as the protocol is still very new and we communicated the drill only on Twitter (but let us assume that if we do something malicious we wouldn’t communicate at all). This reinforced the decision to have a low quorum (10k steakUSDC), needing very little depositor participation to revoke a change.
Second, oSnap provides a great way to control the guardian but some UI bugs were limiting usability. Specifically, it was not possible to create a contract interaction (using function names) and we had to use a raw data interface. But even then, voters on Snapshot were unable to view what the call was doing (neither the raw data or a decoded version); they had to vote blind, which isn’t ideal. The UMA team was super responsive and is working to correct the UI.
The above Guardian setup, demonstrated in the drill, offers vault depositors protection from malicious actors or from the Curator’s reckless behavior. This feature is similar to the ‘dual governance’ that Lido DAO is considering for stETH holders, whereby the users of the protocol have direct veto power over critical actions.
While the time-lock on MetaMorpho vaults allows depositors to withdraw funds once triggered, the above Guardian setting provides a second layer of defense. These drills are part of our efforts to improve both the efficiency and security of the Steakhouse MetaMorpho vault.