FIP-XX: First class peg step 2


Following the discussion on the road to 1B FEI thread, this FIP propose to improve the peg.


While the reduced fees on the DAI PSM end of January helped significantly to narrow the peg, it is trading more widely than FRAX. Those last few days it was trading with a 20bps deviation to the peg.

Tribe incentivize a hug pool of capital for its peg with the FEI/USDC 1bps Uni v3 LP. Yet this pool is drained for days now. We are paying 10% APY for people to hold FEI without providing external value to the protocol. That’s a bit high.


To make the matter worse, the DAI PSM is not well filled which reduce arbitrage effectiveness (it should reduce deviation of the FEI price to 11-12bps). Therefore, the size of the buffer seems good (20M), it’s just an issue of automation (which doesn’t fall in a FIP process I guess).

Therefore I suggest we put DAI input fees of the PSM to 3bps. This will provide a backstop to the USDC-FEI Univ3 LP. Indeed, with the feeless DAI<->USDC PSM of MakerDAO USDC and DAI are the same thing and bots know how to use it.

We currently have 35M of DAI as a liquidity buffer, this a quite small regarding the 300M user FEI (around 10%). We also have a LUSD PSM and a ETH one but those are paused.

I would suggest to move the LUSD PSM to the same kind of PSM as DAI (no oracle, at least for redemptions) and allow a redemption with a 20bps fee. I’m open for anything between 3 and 40bps. 20bps allows to be a backdrop for the LUSD-USDC Uni v3 pool. We have 89M LUSD with an unclear yield (but let’s keep the asset discussion for another thread). Not having a vault yet owning a lot of the supply, we are responsible of the inflated price of LUSD.

LUSD price will spike when ETH crash as people want to repay their loans. Such a move will enhance LUSD price and provide us liquidity when we need it (as we have the opposite reaction due to significant FEI in crypto-FEI LPs (ETH and TRIBE but ETH is no longer used due to that impact).


  1. Set the DAI PSM redeemFeebasisPoints parameter to 3bps (from 10bps)
  2. Specification for the LUSD PSM depending on the discussion.

Voting Options

  1. YES, approuve specification
  2. NO, do nothing

thanks for the proposal. Im strongly in favor of the DAI part

I think the LUSD part needs more consideration. the FEI-LUSD PSM is good to have as a backup when DAI reserves run low but during normal operation I think it will have problems, especially with a tight spread. the lower the spread on a PSM, the more important it is for the PSM’s trading asset to have a steady peg. otherwise you have to depend more heavily on an oracle to deal with the trading asset’s volatility, and you subject yourself to oracle frontrunning issues. the FEI-DAI psm works particularly well because 1) FEI is pegged to DAI and 2) DAI has a very steady peg. a FEI-LUSD PSM would work better than the FEI-ETH PSM did in this regard but still would have problems compared to the FEI-DAI PSM


Including Fei3CRV, the DAO is paying ~10% in TRIBE on ~200m in stablecoin liquidity. The swaps volume supported by all this liquidity is quite small, could use help estimating but looks around 5m daily.

It seems to me that this incentivized liquidity could be phased out and entirely replaced with an adequate PSM, as it is in the case of MakerDAO, especially if the proposed FEI savings rate can be implemented. Holding 10-20m DAI or USDC in a zero fee PSM could facilitate this.


@storm For the LUSD PSM, there is no risk of selling them below 1 FEI (corrected error). It’s good for them to keep a peg and good for us as we get the premium.

For minting FEI from LUSD, here is a risk and it would be great to keep it disabled and need to be enabled only when we need/want it.

Reducing the DAI PSM fees will generate an outflow of DAI from Tribe. 30M DAI are need to balance the DAI-USDC Univ3 LP. Therefore, to look strong, we need another source of liquidity and LUSD seem quite indicated (especially as it is counter-cyclical).

maybe Im not understanding your proposal. if LUSD is trading for >$1 then it doesnt make sense for to let 1 FEI be redeemed for 1 LUSD. and if LUSD is trading a different price than DAI then there are also weird cross arbitrage opportunities that arise, especially with tight spreads and deep PSM liquidity. what am I missing?

agreed that there will be a temporary outflow of DAI when the DAI-FEI psm fees are adjusted. this could be dealt with by on-demand activation of FEI-LUSD psm when needed or it could be dealt with by exchanging some LUSD or other assets for DAI

1 Like

Thanks @storm corrected the error. My point is to sell 1 LUSD for 1.0025 FEI for instance. By arbitrage, I assume it will net increase our DAI holdings by 1.0025 and decrease LUSD holdings by 1.

Since April 1st, we lost 30% of our DAI reserves (50M → 35M). If we reduce the spread, it will drain more DAI. I would avoid to have a tight peg just to fail miserably at the first crash because we have no reserves. Reputation matters.

An alternative is to sell some LUSD to DAI before the PSM update (directly of by enabling the LUSD PSM for some time with low fees).

what about times when LUSD’s market price is > 1.0025? there the FEI-LUSD PSM would need to rely on an oracle which introduces a lot of challenges that don’t exist with the FEI-DAI PSM. this leads me to believe the FEI-LUSD should only be activated as a backup PSM during times when the FEI-DAI PSM is out of DAI. it is more efficient + more robust for the protocol to preferentially perform peg maintenance using DAI

1 Like

I would say no, as we just offer the ability to trade 1.0025 FEI for 1 LUSD. If we allow that, regarding how big our share of LUSD is, LUSD might never go above 1.0025 anyway.

But I’m fully open to other solutions to refill the DAI exposure so the DAI PSM is enough.

Agree with storm here. The DAI reserves are too low at the moment to support tightening the spread, so it makes sense to prioritize more FEI demand through a savings rate or MakerDAO line of credit

Let’s delay this FIP until we solve the DAI buffer size.

1 Like

agreed on the sequencing. it would be very good to get both of these solved relatively soon. im evaluating a couple additional proposals to this effect

also we call them "FIP"s around these parts :wink: :wink: