Measures taken to ensure the safety of ShardVault depositor funds
While specific measures will depend on the protocols used and the specific borrowing terms / yield farming strategies, the principles applied will remain the same - automate as much as possible in order to ensure timely adjustments and minimize room for human error.
Generally we leverage OpenZeppelin Defender for most of our risk management - doing on-chain data checks every single block update and automating specific actions relating to loan management.
The scripts work by monitoring the target LTV of the vault vs the LTV reported by Chainlink's oracles. The scripts are listening to the EVM on every block, and whenever the Chainlink Oracle emits a price update event, the script runs to ensure LTV is still healthy.
Target LTV is determined as a function of liquidation LTV and a buffer depending on the past price volatility of the underlying NFT collection, e.g. if liquidation is at 50% LTV and buffer is 10% then the target LTV we maintain is 40%. We determine this buffer by modelling the largest price declines in the history of each collection we borrow against and adding an additional margin of safety. This ensures that there wouldn't be a decline steep enough in a singular price update that would prevent us from paying down in time.
It is important to also note that the Chainlink Oracle quotes prices based on TWAP thus mitigating extreme price changes and as a consequence risk of unexpected LTV jumps.
JPEG token LTV boost management
For the vaults using JPEG time-locked LTV boosting we have created a script that monitors time remaining for the boost and automatically rolls it over every month to provide flexibility to ensure boost continuity while not locking up the JPEG tokens for longer than needed.
We have an internal alerts channel that quotes us important updates from all the scripts in use. For the LTV management script it's any time LTV on the loans changes and also if our script pays down the loan. For the JPEG token boost script it's alerting when the time-lock is nearing expiry and also when the script extends the time-lock.
Besides the event specific alerts we also have an all-encompassing dashboard displaying real time values of all the vault and loan parameters.
In the case of yield farming with JPEG'd's Citadel we perform no active management of the investment position, however we manage the yield payouts to our users in a way to ensure there's always enough funds for repaying the loan in full.
In addition to the automated scripts, and alerting, our vaults are configured in a way that the team can manually trigger an emergency paydown using either the vault's farming position, or PETH that the team provisions ourselves in a pinch