This post seeks to address several key open questions:
- Do pools managed by the DAO make loans directly to borrowers? How?
- How can the protocol improve risk mitigation (SAFU, stkTRU)?
- How should fees be handled by the protocol?
After defining each of these issues, this post puts forward solutions to address these issues in the near-term. Each of these solutions is intended to be implemented within <1 month.
Below are three high priority items I see:
Fees to TRU stakers were recently removed from DAO-managed Pools (tfUSDC/tfUSDT/etc) without a clear resolution.
- Fees to TRU stakers were turned off in May 2022, in order to avoid an outcome where lenders might see negative yields.
- As described in this post, current TrueFi pool contracts do not take into account fees when calculating LP token virtual prices and need significant work to fix this.
DAO-managed Pools (tfUSDC/tfUSDT/etc) and portfolios both make loans, and it is unclear how pools & portfolios interact with each other.
- This forum post puts forth the idea of moving lending activity to underlying portfolios, where DAO-managed pools act as something like a “fund of funds” governed by an allocation committee. This model seeks to (i) provide transparency on how lending decisions are made and (ii) build a moat / network effect for TrueFi where third party managers come to TrueFi to raise capital. In this model Fees would be paid at the portfolio level, and it may not make sense to charge additional fees to pool lenders.
The protocol’s risk mitigation systems could be improved, as SAFU and stkTRU mechanisms have been negatively affected by reductions in TRU price.
- Slashing stake TRU provides strong incentives for TRU holders to participate in the protocol’s risk management, but it also makes TrueFi’s ability to cover defaults dependent on TRU price.
- TrueFi could remove or adjust this slashing mechanism as discussed in the #dao-tokenomics-committee channel and/or add pool cover where lenders stake LP tokens in return for enhanced yields.
To address the issues listed above, the following immediate / near-term steps are proposed:
1) Move to “fund of funds” model for tfUSDC/tfUSDT pools, where all loans to borrowers are made by underlying portfolios.
- DAO-Managed Pools (tfUSDC/tfUSDT/tfTUSD/tfBUSD) become “fund of funds” where these pools put funds into underlying portfolios
- New loans are generated via third-party managed portfolios like the Alameda SBP, or by single borrower lines of credit
- Empower TrueFi governance to make decisions on fund allocations
- for MVP, TrueFi governance can elect members to allocation committee multisig as proposed here
2) Strengthen protocol risk management with staking module enhancements.
- Expand “pool cover” on DAO-managed pools
- Add “junior tranche” where DAO pool lenders can stake LP tokens as cover
- Keep stkTRU slashing in place as a negative incentive for stakers
- Modify TRU slashing mechanism so that slashed TRU is sent to the incentives pool to replenish future staking rewards (instead of being sold off)
- Both stkTRU and LP stakers should receive compensation for taking on risk, perhaps in the form of TRU rewards and/or a share of fees from protocol treasury
- stkTRU continues to perform “loan rating” where loans are only approved once a quorum of stkTRU has voted YES on a loan (i.e. stkTRU retains veto power over allocation committee)
3) Protocol fees generated by portfolios are routed to DAO treasury.
- Moving forward, protocol fees should occur at the portfolio level only (i.e. the current stkTRU fee mechanism should be deprecated)
- When tfUSDC deploys capital to a portfolio, the underlying portfolio generates fees for the protocol and sends fees to the DAO protocol treasury (see treasury address 0x2369 which currently receives fees each time portfolio loans are disbursed)
- Governance decides how to allocate treasury funds. Potential uses include:
- Fund DAO growth and expenses
- Distribute fees to TRU stakers via dividends/buybacks
- Build “rainy day” fund
Minimal viable product (MVP) versions of these changes should be able to be implemented quickly, with the protocol building out more robust/automated versions as time goes on.
Please share your thoughts on this direction. If you want to be involved in executing these items, let’s continue the chat in the Discord gov channels: