[Ideas] A Plan for Improved TRU Tokenomics

Authors/Contributors: @tylerw @hal Yuchen @ryan.rodenbaugh @MoreNapalm


Over the last few weeks, it’s been clear that we need to develop a more sustainable, long-term approach to lending pool incentives.

  1. Ryan first posted about this on June 9 (A long-term strategy for lending incentives) that highlighted the fact that we are currently spending way more on lending pool incentives than originally anticipated. TL/DR is that if we stay at the current rate, we’ll run out of TRU lending pool incentives in 9 months, rather than 2-3 years.
  2. This was followed up by a post on June 15 (A Medium-Term strategy for lending pool incentives) which included slightly reducing USDC and USDT from the highest level and severely reducing TUSD while – most importantly – proposing that we adjust rates every two weeks to be more in line with pool utilizations.
  3. Rafael then followed up on June 18 with a post proposing to reduce all farms by 30%. That post had some good back-and-forth, but seems to have landed on the fact that this is not something we want to pursue at this time.
  4. Since then we’ve continued to adjust rates every two weeks and this seems to be working well as a short to medium-term measure.

In the June 9th post, Hal commented about the improved staking gauge and additional ideas around locking TRU to boost lending pool rewards.

This post extends on some of those plans:


Better tokenomics and more long-term alignment between stakeholders

  1. Increase TRU utility + incentives to hold & stake TRU

  2. Improve TrueFi default protection by providing incentives for longer staking periods and higher slashing rates

  3. Create scalable system for distributing lender pool incentives

  4. Spur ecosystem innovation on top of TRU token

  5. Provide stronger incentives to borrow TRU

  6. Create opportunities for Yearn or Convex-like protocols to aggregate lenders and stakers to maximize stkTRU boosts

Our goal is to have this fully specc’d out in the next three weeks so that we can include it in the next smart contract development cycle!

Step 1 (Committed):

Introduce the TrueFi staking gauge in our next big smart contract update. This feature is being audited now.

The details of the staking gauge:

  • Right now each of our pools has its own smart contract which determines how many TRU will be distributed to that individual pool. In this updated model there will be one staking gauge for all current and future pools.
  • The gauge will be set to distribute a fixed number of TRU per block and then through ‘allocation points’ or utilization-driven system the gauge will determine how many TRU are distributed to each pool.

We will also scope this distribution model to slowly decrease TRU distributions over time, allowing us to extend the remaining TRU rewards over several years. We encourage you to share details of other projects that have done this well.

Step 2 (The Proposal):

We want to increase the usage for TRU by giving lenders more reasons to own and hold TRU. We have a few proposals for how we could go about this, but are very interested to get feedback and work on this as a community.

We think Curve’s vote locking for higher CRV rewards is a great system that has both created a mini-economy on top of Curve (see yEarn vs Convex wars) and creates additional utility for the token. That said, Curve’s system can be viewed as a bit complex. We want to make TrueFi very accessible to mainstream and TradFi audiences and want to cut out as much complexity as possible. Other projects have adopted Curve’s system with slight edits and that’s what we’d like to do as well.

The core of our proposal comes largely from Badger. We think their “Badger Boost” program comes from the same place our tokenomic revamp is coming from:

Until now, the Badger app hasn’t had mechanics in place to reward those who were long term supporters of the protocol. Instead the largest liquidity providers would earn the most Badger or Digg rewards and in many cases they would sell to realize gains immediately.

Badger aims to improve this by:

Badger Boost enables users to earn more rewards based on the dollar value of Badger or Digg they have staked relative to the dollar value of their Bitcoin deposits in the app. We call this the Badger Ratio and the formula is calculated as follows;

[$ value of BADGER Balance + $ value of DIGG Balance] / [$ Value of non-native staked sett positions].

In the context of TrueFi, this means that the $TRU incentives you receive for lending would be boosted based on the amount of TRU you stake relative to the amount you lend. A proposed formula for TrueFi could be:

[$ value of TRU staked] / [$ value of assets lent across all pools]

As an indicative example (with made up numbers), let’s say:

  • Ryan had 10,000,000 USDC and 1,00,000 USD worth of stkTRU
  • Tyler had 1,000,000 USDC and 500,000 USD worth of stkTRU

In this example, Tyler would have a higher boost than Ryan because (500k/1mm) > (1mm/10mm). Ryan would likely still receive more TRU since he’s lending 10x as much as Tyler, but Tyler would receive a higher ROI relative to the amount of capital he’s lending.

Open Questions:

  • What is the exact formula we want to use to calculate the boosts?
  • Do we allow users to lock their stake for longer periods of time (> 14 days)?
    • If yes, how does this work into the boost formula?
    • The veCRV model incentivizes longer staking and allows users to lock tokens from 1 week for up to 4 years.
  • Should we allow users to volunteer to accept higher or lower slashing rates?
    • If yes, how does this work into the boost formula?
    • We could use something like [$ value of slashable TRU] / [$ value of assets lent across all pools] to incentive higher slashing rates
  • If desired, how should we implement a voting weight determined by three variables: (i) # of TRU staked, (ii) slashing %, and (iii) staking period?
    • Are there models we can look to as good examples?
    • Models like veCRV only use two variables: staking period and amount staked
  • Should we incentivize lenders to lockup funds in lending pools for longer periods of time (30/60/180 days)?
    • Such a mechanism could help visibility into future lending capacity and utilization
  • Should these boost apply across all pools or should they somehow be pool by pool?

Additional Resources:


Posted in discord and will post here as well. To re-iterate, this is good @ryan.rodenbaugh but I still don’t see any word on the token burn or lock for unwanted tokens which are already circulating. The reason why its different for us compared to CRV, CREAM is we already have a surplus of tokens in circulation. CRV has massive TVL and the token release was gradual as TVL jumped up and the token lock was organically introduced to begin with. Cream has a very small token supply and hence this strategy will allow IceCream to boost cream. For us, due to any concrete plan for a token burn, Price is at presale level already due to this excess emission and already surplus supply of tokens. Hence, unless there is a strategy to burn a chunk of circulating tokens just trying to fix the future emission will not help much. That’s just my opinion.

the SUSHI/xSUSHI model works too.

  • distribute loan fees to stTRU holders. this would, of course, require TrueFi to collect origination fees and/or take a small % of the interest for every loan. it would decrease the APY for the pools/farms but you’re doing that anyways by reducing TRU emissions.

  • more fees might be a solution. i wouldn’t recommend more fees if you don’t have enough liquidity but it appears you have more TVL than you do loans. so adding a withdrawal fee (Yearn charges 0.5% withdrawal fee, Vesper 0.6%) might make sense. but of course, you already have an exit fee but that’s a little different.

Responding to a comment George wrote in Discord.

His comment:

The proposal for step 2 is great, love the concept of the badger model.

Regarding the slashing % dynamic, I think that makes it a bit too complicated. Ideally Tru should be focused on a way to increase the treasury with stable coins to support any loan defaults, so we don’t have to worry about slashing dynamics. Then stake the treasury in aave/compound to allow it to grow.

Should also think about doing something similar to the badger model on the borrower side. Like creating a separate staking system just for borrowers to lock their TRU for infinity, in return they get discounted interest rates on their loans based on the TRU value they locked vs the size of the requested loan. Could use tiered levels of (locked tru / loan size) %, to determine discount %. This accomplishes an effective burn of TRU supply and increases token demand. I don’t really see a downside to this as long as its separate from stkTRU.

Regarding your first point, yeah I guess that’s true. I had not really thought that actually. But yes, if the SAFU/insurance fund was so big, it could eliminate the need for staking.

Regarding borrower staking, we have a draft proposal here: [Idea] Borrowers can stake TRU in order to increase their credit limits

Just needs to be built

I fully support the idea of building a stablecoin backstop to offset default losses.

Building a protocol treasury/backstop from the protocol’s earned fees could improve TrueFi’s risk management and make TRU more attractive (i.e. this could get us to a buy-and-burn or similar model).

As a starting point, TrueFi could direct 10% of interest earned by TrueFi pools into this treasury/backstop (i.e. divert the 10% currently going to stakers). This treasury/backstop would grow steadily over time and once it grew large enough, “excess reserves” could be used to buy-and-burn TRU or distribute funds to TRU stakers (governance would decide what to do with the funds).

While 10% might seem like a trickle today, it can easily build up to $1M+ within a few months. So far in 2021, over $2M has been repaid in interest (i.e. such a treasury would have ~$200k worth of stablecoins had it started in Jan).

My rationale is that “building a warchest and reinvesting into growth” (quoting Hasu here) is the best use of today’s TrueFi protocol fees. Imo, there’s little lost in building the warchest today as governance can always decide to distribute the funds at a later point in time.

Such a system would be similar to MakerDAO’s, which I’d written a bit about earlier this year:


I like the xSUSHI model too. We could start using the protocol fee (10% of interest) to buy TRU on the market and send this purchased TRU to the stkTRU pool.