I want to make a few proposals to the community because I see some problems with the TRU token’s utility and value and would like to address the concerns that some members including myself have and propose of a solution to fix them. This proposal is by no means a final draft, and I want to open more discussion and ideas concerning this.
We have seen a previous proposal/idea of incentivizing borrowers by giving them a lower rate if have TRU tokens staked, but this proposal takes it a little further than that.
The tricky thing that TrueFi has to deal with is scaling both the staking pool and the lending pool at the same time while balancing the risk vs. reward for both parties.
Both the staking pool and the lending pool(s) are pillars to the TrueFi protocol, but if we place more emphasis on the lending pools, then I believe there is actually no incentive to have a TRU token at all: If we remove the TRU token + the staking pool and only operate with lending pools, the protocol essentially remains the same. Take the slashing from the staking pool and add it to the lending pools and the main fuctions of this protocol remains unchanged regardless of whether there is a TRU token or not.
Important Premises to Explain:
#1 - Give generated revenue from the protocol to the TRU staking pool. Lower generated revenue from the protocol to the lending pools.
#2 - The rate of emissions for TRU tokens should be greater in the lending pools than the TRU staking pool.
#3 - Emissions to the lending pools should be changed to stkTRU instead of TRU tokens directly.
#4 - Have a better slashing rate for the staking pool and add a slashing rate for the lending pools.
Explanation of Premise #1
Giving generated revenue back to TRU stakers is essentially equivalent to giving a better loan rate for borrowers who stake their TRU. Both accomplish the same desired outcome. Since this incentivizes borrowers to actually hold TRU, they will most likely increase their share in the staking pool, making it even more counter-productive to default on loans.
This will scale the usage of TrueFi into our native TRU token directly. More loans being emitted will increase the APY in the staking pool, thus arbitrage will drive more TRU tokens to be staked. This also solidifies the significance of the TRU token as equity.
Note: Many protocols don’t seem to give income out to their users and do manage to still have a functioning product, but keep in mind that TrueFi is already giving this income out at current time, so TrueFi is already, by definition, not part of that category of protocols.
Explanation of Premises #2 and #3
The lending pools should be given more TRU ownership to lending pool providers because not only are they contributing to one of the pillars of the protocol, but having shrinking lending pools is obviously bad.
One solution to this is to give the lending pools stkTRU instead of TRU tokens directly. This would effectively put a lock-up on their rewards as well as keep the APY the exact same. Not only will it delay some token dumping, but it will also give participants of the lending pool a direct access to the staking pool and provide much more liquidity in the staking pool at any given time.
If tied together with #1, we are basically changing the dynamics to this environment:
- TRU stakers will be earning more income (rewarded in USDT/USDC/TUSD…).
- Lending pool providers will be earning more equity (rewarded in stkTRU).
In my opinion this makes more sense than what we currently have now, where both earn TRU tokens (tokens which only produce 10% of income generated when staked as opposed to 90% for lenders).
Explanation of Premise #4
Since #1 to #3 creates a different dynamic, the staking pool and the lending pools will each earn a different income weighted by equity vs. income. Thus having an even slashing rate would maybe make this much more balanced.
As it currently stands, the TRU staking pool will always be the first one to get slashed, and whatever remains defaulted that can’t be paid by the maximum slashing of 10% from the staking pool will be covered by the lending pools themselves.
With our current numbers in the staking pool, it is quite obvious that with any default over 3-5M, the protocol would have to use a little of the lending pools to repay the loan. Any default over 5M will be significantly more risky to the lending pools. This means that as it currently stands, staking TRU rewards you with more tokens that will be first in line to get penalized in case of any defaults, without generating any income, but that you can use to vote for who to distribute loans to. Contributing funds to one pool with a completely different pool taking the first hit of the risk is very… weird?
I believe no pool should come as “more important” than the other, as both need to be equally scaled and growing in order to have a stronger protocol.
With all this said, the benefits are massively skewered to the side of providing loans to the protocol instead of holding or staking TRU. As it currently operates, there is actually not much need for a TRU token for TrueFi to function properly.
On-chain data confirms that providing to the lending pools has a better risk vs. reward than contributing to the staking pool (by a huge margin). At current time of writing, we have 224 Million $ in the lending pools, compared to only ~ 20 Million $ in the staking pool. Also being in both those pools, I can tell you that there is less incentive for me to be in the staking pool than the lending pools.
Swapping the rewarded assets between the lending pools and the staking pool will not change the APY at all, it will simply swap the type of rewards given out.
ROLLING OUT IN STEPS/PHASES
Making all these changes without losing any momentum would require different rollout phases, because such drastic changes will make investors uncomfortable and most probably reduce the liquidity in the lending pools, which is very bad. So I have a proposed rollout solution (not a final draft at all, up for discussion) that is broken down in multiple Phases, each comprising of 4 steps.
Each Phase will include these Steps:
1- Remove 10% of TRU rewards from staking pool.
2-Add 10% of TRU rewards to stable pools.
3- Remove 10% of generated income from stable pools.
4- Add 10% of generated income to staking pool.
We should start with removing 10% of TRU rewards from the staking pool because it will lead to the least amount of damage (the pool is already too weak, a little less in there won’t spell doom for the protocol).
Notice that the lending pools will never, under any circumstances, have a net negative impact in terms of APY, they will only have brief periods where they can benefit from a 10% bonus before their rewards are swapped from one asset to the other. So the lending pools should technically not suffer any losses during the time it will take to change.
It would also help to market and advertise the bonus rates of the lending pools during the 2 weeks of added incentives, which might see more capital inflow into the lending pools. Will they stay forever? Maybe, maybe not, but at least more capital will want to flow in to take advantage of the rate and more exposure was gained; and all this while fixing the problem.
These Phases can be done over and over until we reach a sufficiently balanced state. Maybe instead of 10% per Phase, we can do 5% (the rate was only given as 10% for example purposes).
Moving forward, I would suggest these proposals to be reviewed by the community/team members:
Slowly swap the income generated by the protocol (rewarded in Stablecoins) from the lending pools to the staking pool with the staking rewards generated by the staking pool (rewarded in stkTRU) to the lending pools. Rolling out in Phases will be more effective to retain all TVL. As for the % we should move at every step, that is up for discussion, as I cannot predict how the TVL will change based on the exact amounts, but I think anything between 5-10% would work well.
- Stakers will be getting rewarded with MORE income (aka stablecoins) and LESS TRU.
- Lenders will be getting rewarded in MORE equity (aka stkTRU tokens) and LESS stablecoins.
The APYs of each pool should remain unchanged.
Emissions to the lending pools should be changed to stkTRU instead of TRU tokens directly.
Amend the slashing rate to a fixed 50%/50% between the lending pools and the staking pool. I believe this change should be saved for last for the following reasons:
- With our current pool of borrowers we have onboarded and using our platform, the default rate seems to be very small, quasi-none. So the slashing rate is not our most important concern at current time.
- Boosting the TVL of the staking pool to catch up with the scaling of the lending pools is much more important, and having more incentive to stake TRU should hence, be a priority.
- Since the APYs technically do not change much I don’t believe changing the slashing % would have much of an effect, and it is in no way compromising any APY for the lending pools at all.
With these proposals in place, we could follow the intended consequences with this logic:
- Since stakers earn USDT/USDC/TUSD, they will be able to apply upward pressure on TRU’s price by using those earned stablecoins to buy TRU.
- If stakers want to deposit their rewarded USDT/USDC/TUSD from staking in the lending pools, then that is also a positive gain for the lending pools TVL.
- On the flip-side, since lenders are earning more stkTRU, there will be less short term dumping of TRU, thus resulting in less downward pressure on TRU’s price.
- Lenders have a possibility of treating the stkTRU as income-generating assets, possible leading to less downward pressure on TRU’s price.
I believe these proposals will help scale the usage of TrueFi directly to it’s native TRU token. There must be a lot of stuff in here that people will disagree with, but I am ready to take the heat. Love it or hate it, this is my proposal and I do stand by it. I would also like to listen/read about what others think about what I got wrong in case I am completely missing some points.
Again, nothing in this proposal is set in stone, but I would like to know the community and team member’s thoughts about them.