Protocol Design & Risk Management
Last updated
Last updated
Risk management is inter-connected with all parts of the protocol, beginning with our decision to use isolated module architecture, to how asset listings are evaluated, liquidation mechanisms, XY peg stability, and more.
To show how these are all inter-connected:
Isolated modules contain risk to the module (asset) level and not the protocol level → this allows the protocol to take on more risk with asset listings → an asset that is too risky, however, can flash crash without recovery, which puts stress on the liquidation mechanism → if the asset is not properly liquidated, this puts the protocol in bad debt → XY peg is negatively affected as users lose faith in the protocol. Each of these steps and processes are covered in the following pages.
The goal is to create the most capital efficient money market with the lowest risk through technological and protocol design innovations, and many projects will claim that theirs is the one that offers this. While Tren Finance’s goal is the same, we believe that there are inevitable tradeoffs that are made with each decision. It’s easier to think of risk management as a sliding scale:
Most importantly, each user has different levels of risk appetite. So while a protocol might look like the best option in the eyes of its founders, it may not be the best option for certain users. For example, a fund manager managing hundreds of millions of dollars worth of blue chip crypto assets might only use AAVE. For other users though, AAVE deposit yields might be too low, or find that their asset offerings are too limited. These users can (re)collateralize their idle liquidity in the form of LP, money market deposits, restaked positions, etc. on Tren Finance for greater capital efficiency and higher yields.
