There are a variety of reasons for the protocol to increase its DAI holdings in the short term. In addition to DAI being the main asset used by FEI’s current peg mechanism, many upcoming FEI initiatives could increase the protocol’s need for DAI (see the four reasons listed here).
Fei Protocol has the ability to use all of its DAI, LUSD, ETH to support the FEI peg through PSM contracts. Only the FEI-DAI PSM is currently activated because this allows FEI to utilize DAI’s very tight peg for highly efficient peg maintenance. Unlike the FEI-DAI PSM, the FEI-LUSD and FEI-ETH PSMs rely on oracles that suffer from possible precision issues and MEV-sandwiching issues.
Rather than using the FEI-LUSD PSM, it would be more efficient to convert LUSD to DAI as needed. Under current market conditions the protocol can do this on-chain with deep liquidity + low slippage on Curve.
This can be performed in an automated fashion using sentinels. Sentinels are automated tasks that can be set to perform various PCV maintenance operations when certain conditions are met. Combined with the PCV collateralization oracle that tracks all PCV deposits on-chain, a sentinel can be triggered to act when assets balances cross some threshold. Here the sentinel would be activated to liquidate LUSD for DAI when DAI reserves fall too low.
Specification
Create a PCV sentinel with the following parameters:
Whenever the PCV has less than 5M DAI remaining, liquidate 5M LUSD for DAI on Curve
Revert the transaction if the realized price is < 99% of the LUSD-USD Chainlink oracle price
Revert the transaction if the realized price is < 0.99 LUSD per DAI
I don’t like the assumption of this parameter as MEV likely will mean that each sentinel swap will lose 1% of the value of LUSD every time. I think the parameters on this sentinel should be tighter, so that it only accepts a loss of 25 basis points per swap.
There should be a role in the Tribe DAO sitting behind a very short timelock, say 1 hour that has the ability to swap with a bit larger slippage, but of course limited from 1-2% for more extreme market conditions.
I can see the other constraint (“the realized price is < 99% of the LUSD-USD Chainlink oracle price”) being more problematic wrt MEV. I dont think the price floor constraint will create any more MEV than the oracle price constraint. I would be down with making the oracle price constraint 99.5% instead of 99%
however if it becomes too tight then this mechanism will become less effective during stressful market conditions. during such conditions preserving the peg is more important than saving 0.25%…0.25% of $5M is $12,500 which is not very significant compared to the other considerations at stake
The new role would be behind a timelock + multisig and would be granted the ability to sell LUSD with up to x% slippage by a snapshot proposal that specifies the “extreme market conditions” under which this role can sell.
I’m unsure that we would need to measure this onchain, it could be fully specified offchain, the timelock can have its rights revoked or proposals cancelled by a guardian, so if it acts out of line it will get proposals cancelled and privileges removed.
A sentinel should execute through an MEV protected transaction, I think a 1% flexibility is reasonable to ensure the sentinel can effectively maintain the FEI peg with DAI liquidity but also fine with a reduction to 0.5% slippage tolerance. Does the sentinel include measures to prevent risk of compromise, such as limiting the rate of sentinel actions and ensuring a sentinel can’t act more than once in a single block?
Responding to both @OneTrueKirk and @elliot here. The PCV Sentinel is designed to operate permissioneslessly as long as the guard conditions have been met; gating a sentinel action behind a new role is hacky and not really how the sentinel is designed to work.
Yet, MEV is an issue here. Even if we wish to operate sentinel actions through flashbots, the permissionless nature of sentinel guards means that savvy MEV-bot operators will bundle a sentinel-triggering transaction that they send with a frontrun that they execute.
Thus the parameters of the liquidation need to be fairly tight (but not too tight as to have high likelihood of failing).
I much prefer an automated sentinel mechanism over introducing a new optimistic multisig that requires significant human intervention. a new optimistic multisig wouldnt completely solve the MEV problem either
this will become a bit of a moot point with the upcoming governance changes that allow much more standardized and precise governance structures. but in the short term for this specific circumstance I think a sentinel makes the most sense
I see, thank you for the clarification. I’m not sure I understand why it’s desirable for the sentinel to be permissionless, which as you say introduces MEV or other griefing risk. Seems better to allow a constrained set of addresses to perform this role, including some keepers.
I think a proactive strategy could be more effective than a Sentinel in this case. I’m pretty open to both options, but avoiding a situation like we have now where the protocol is low on DAI could be done with more lead time.
The sentinel perhaps would be configured with “last resort” kind of parameters which only execute in an emergency, when slippage is less of a concern
last resort is what I had in mind as well. in a perfect world this sentinel will never get used. but if it’s needed then it’s needed and it’s better to have it than not
Most Sentinel actions don’t induce MEV risk (ie, automating pausing of certain psms based off of market conditions, or pulling funds to safety if an oracle is detected to be compromised)