MIP43 - Term Lending Module (TLM)

The “oracle” for fyDai will be just be to treat the value of 1 fyDai as 1 Dai. Since the join is only usable by the TLM there is no need to track the market value of fyDai. Please note that there will be a separate join for each separate series of fyDai.

The redeemGem method should not be blocked for 2 or 3 years, but only until a particular fyDai series is mature. Currently, no fyDai maturity exists past this year. The redeemGem function is callable by anyone, so you just need one person to call it to trigger the redemptions. But even if no one does so, nothing bad happens.

The idea to have someone else do the redemption rather than have it in the TLM is good one. A simple way to do it would be to allow anyone to buy the fyDai at a price of 1 Dai at maturity. I’m not sure you necessarily need a reward. We are considering making this change to the TLM.

So there will be a collateral type anyway even if the oracle is set to 1 or disabled.

That is fine.

What I am saying is use MIP37 instead of PSM interface which is use to create a market exchange at a fix price. Which is not what you want to do.

1/ instead of sellGem use a flash Mint to populate the vault via governance.

2/ instead of having your redeem as it is, pay someone from the vow to kick the transaction once the maturity is over. Flash Mint like MIP37 and redeem the full position.

That is probably the only way to make it works properly.
Because in your implementation
1 / you start the grab which not what you want.
2 / no one will start the transaction
3 / no one will have interest to exchange fyDai. As there is 0 market gap between one Dai and another Dai.

This is an interesting proposal! Would love to see something along these lines come about. Regarding Notional Finance, we currently do not support ERC20 fCash assets (our version of fyDai) but if this module did exist we would have no problem adding ERC20 support for it.

Notional currently uses ERC1155 to represent our fCash tokens, we chose this standard because we think it offers superior flexibility over ERC20 for term based assets. The integrating contract only needs to whitelist the single ERC1155 contract address and can access any one of our fCash assets via a deterministic id which is determined by maturity and currency. This reduces the need to deploy and list new contract addresses. As I mentioned above, if using ERC20 is a must have we can certainly use CREATE2 to get a series of deterministic ERC20 addresses.

However, I do think the pros and cons of different token standards for fixed term assets should be considered, they do have different behavioral characteristics compared to perpetual tokens like most ERC20s.


Given that fixed-term loans have the potential to generate more DAI at higher interest rates and also offer more tools to control DAI demand, this proposal should be given a high priority. Governance faces many opportunities to evolve MakerDAO, such as adding more collateral types and real world assets. My opinion is that fixed-term loans would be a major functionality upgrade and increase the utility of all the collateral types. I’ll just reiterate that I think that this MIP proposal should be given high priority.

@niemerg It seems like the current design will require setting lots of parameters. I worry that this could be gas inefficient. Maybe some way can be devised to control the interest rate curves across many fixed-term products in a gas efficient way?

Another question: How will this interact with the Dai Savings Rate (DSR)? Maybe it won’t because all generated DAI is ultimately backed by a regular floating rate vault? I feel like I’m missing something though. Does the DSR rate constrain the interest rate curve? It would be great if some smart person could explain this in simple terms.


MakerDAO definitely needs to get into fixed-term lending. It would instantly create a decentralized yield curve.


At first glance, this is a very interesting and useful proposal. This sort of mechanism could be at the inception of bringing benefits to both users and the protocol, just to name a couple.

From a real-world user point of view, this may be the beginning of the road for retail to finally use DeFi to mortgage their homes, should rates be competitive with trad Fi. In the UK and many CommonWealth countries, home lending is not fixed for more than 5 years, even on a 30yr term loan. Home owners are frequently shopping around, refinancing and “hedging” their short vs longer term interest payments. This sort of implementation would be very familiar to those home owners and could create a relatively easy bridge to refinance to DeFi. The challenge is the exchange rate, unless you thought of a GBP or AUD to DAI float -> fixed :slight_smile: .

From a protocol perspective, this may be a game changer in RWA and the discussion around long term maturities. It makes the decision on terms & rates more transparent and passes on (at least) part of the responsibility on the rate setting to the asset manager/originator as what portion of the pool they may want to finance at each maturity, based on their view of the yield curve progression. Of course, considerations on credit quality overlay that pricing, but at least the fixed rate provides a sort of base rate for term setting.


I am not sure that the current design will require setting lots of parameters. There is really only one parameter to set per maturity date: the interest rate Maker would pay to buy fyDai. In theory, this could be set once and never changed. More likely, the interest rate parameters would be updated roughly as frequently as the stability fee, so every few weeks or so. That should not be too high of a burden.

Regarding the Dai Savings Rate, that is another Maker governance controlled interest rate. The considerations that Maker governance might use when deciding what rates to set the DSR and the fyDai interest rates are too many to list or consider here. But I think adding fyDai only increases Maker’s effectiveness in managing Dai supply and demand. If there were unexpected interactions caused by the introduction of fyDai, Maker could withdraw from the fyDai market quite easily by lower the debt ceiling for fyDai.


Great proposal! This looks like a form of Yield Curve Control (YCC), where long term fyDai rates are effectively set by Maker Governance. I can imagine Maker supporting multiple fixed-rate markets in the future, influencing rates across various venues and products, such as Notional, before eventually settling on the one with the deepest markets and/or with the least amount of risk.

Although interesting and beneficial for the community, IIUC it looks like fyDai is a synthetic debt token, and under extreme market volatility, is therefore at risk of becoming insolvent, as was mentioned in the MIP. It looks like Yield relies on its native reverse Dutch Auction liquidation mechanism to discharge unsafe collateral positions. I’d be interested to learn why a reverse Dutch Auction model was chosen over a Dutch Auction model, as has been proposed in Maker’s upcoming LIQ2.0. Would you have any data to share about liquidations? How’s the level of recent keeper participation? As one involved in LIQ2.0, I’m be interested in learning more.

@niemerg Could you elaborate here? What would Maker Governance need to do to prevent losses caused by fyDai?


Very interesting proposal for TLM!

Could I ask - how is the rate calculated - based on which interest rates ?

‘‘The price of a fyDai token in terms of Dai is determined by the interest rates in the market. If interest rates go up, the market value of fyDai goes down. Thus, fyDai purchased by Maker may lose value when marked to market in an environment with rising interest rates.’’

1 Like

Teddy from Notional here. This is an interesting proposal! I’m curious to understand how the market dynamics might work here. It seems like this proposal would encourage the following behavior:

  1. Borrowers borrow through liquidity pools and push interest rates up.

  2. Lenders lend through liquidity pools and then turn around and sell their loans to Maker. This pushes the rate down on these liquidity pools into line with the Maker governance determined rates.

My question is, shouldn’t Maker just lend to borrowers directly at their policy rates? The market dynamics above seem convoluted and inefficient. In this setup, pool LPs would take two cuts out of every trade. If Maker lent directly to borrowers, there would be no need for an expensive and inefficient middleman.


While it could be the case that loans are sold to Maker via arbitrage, they don’t have to be. For example, if MIP43 were to pass, and Maker governance decided to buy fyDai tokens, then the TLM could be used for direct origination of loans. For example, when users use Yield, the web app could decide to route the sale of fyDai to either the liquidity pools or to the TLM based on whichever has a better interest rate. In that case, Maker would be lending directly to borrowers at their policy rates whenever that rate is best.

fyDai interest rates are market based. Or put another way, the price a fyDai token imputes an interest rate because fyDai are like zero coupon bonds.

@KentonPrescott. Yield Curve Control is certainly one way Maker Governance could choose to take advantage of the TLM. I certainly hope that this MIP is the start of Maker being active in fixed-rate lending markets as you suggest.

Regarding the “reverse” Dutch auction, when liquidating a position, Yield protocol is attempting to sell as little collateral as possible to receive a particular amount of Dai. So the auction is a “reverse” auction because the protocol continually raises the amount of collateral it is willing to sell to receive that amount of Dai. I am not sure that Maker’s upcoming version is actually different (I am not that familiar with it).

As of the last time that I’ve looked, there have been no liquidations on Yield Protocol. This is because the price of ETH has gone more or less only up since Yield’s launch. During that time, some team members have continuously run a keeper.

Regarding the steps that Maker could take to prevent losses caused by fyDai, as a very simple example, if there was a bug in Yield that caused assets to be frozen in Yield, then Maker would have the power to unlock those funds. Many other scenarios are possible, and it sort of depends on Maker’s threat model to determine whether Yield collateral being held by Maker protects Maker or not.

1 Like

Ok thanks Allan. A direct lending facility makes more sense to me.

The only other thing I’ll say is that we are very early here in the development of a fixed rate market and there are some significant structural differences between ourselves and Yield. I’m biased of course, but I would suggest that Maker retain optionality for the time being and refrain from committing to a single platform before the market proves out the relative merits between the two.

Join us next week as @niemerg and @equivrel explain the in-and-outs of this MIP!


Know your MIP - Know Your MIP #05: Term Lending Module - February 10, 2021 - YouTube

Very cool! This is going to be a huge market.

My only worry is that we will be dependent on another protocol’s liquidation process. We know how hard liquidations are to get right and to ensure the liquidity is there. Of course we could set a low DC but if we want to meet the demand I foresee this having we are going to take on a lot of 3rd party risk.

I feel bad saying this, but I think this is something Maker should implement itself.

1 Like

During the very good presentation (now in youtube) I had the same feeling.
Yes, the project is cool but:

  1. MakerDAO will carry external risks (their liquidation system, their absense of Surplus, etc). As they mentioned, there is significant risks of losses when ETH drops quickly (like -33% in 1h).
  2. MakerDAO will help Yield to grow its market share/business for free basically.

Please note that I think Yield is a great team, they developed a cool idea, and this partnership will be good! But it would be even better if they could be incorporated directly in MakerDAO:

  1. they would work directly on our codebase (not just on “very similar code”)
  2. they will work within the framework of our Auctions (2.0 coming), and
  3. MakerDAO’s surplus buffer would be able to protect us against incidents.

TLDR: It would be nice[r] to “buy them” rather than having them as partners :slight_smile:


Yes, liquidations are an important component to this, and we worked hard to develop a good auction system. It certainly is a source of risk, but it’s also possible that a slightly different auction system may provide some resiliency, as it is less likely to fail under the exact same conditions as Maker’s. Nevertheless, I do think Maker should carefully evaluate that risk, and should deal with it via the DC mechanism.

Regarding your comment and @iammeeoh’s comments about how MakerDao should add fixed rates, I expect that Maker eventually will add native fixed rates. But eventually can take a while. When we started Yield, we were told that Maker was considering adding fixed rates by Maker Foundation members. Over a year later, Yield is live, and there isn’t yet any work on adding fixed rates directly into Maker that I see. And for good reason: Maker has higher priority initiatives like real world assets that are going to be huge and there isn’t the bandwidth to do everything.

That’s where the TLM comes in. It’s not trivial to do fixed-rate loans. We’ve had to solve a lot of problems along the way, and it still remains to be seen whether we got it right. Before Maker invests a lot of resources trying to add native fixed rate loans, buying loans can help Maker evaluate the market and the technology. If it works, the lessons learned can be used to build fixed rates into Maker. Yield would support such an effort, and this MIP can be thought of as the first step in that direction. You might even say that Yield is helping Maker to add fixed rates for free, basically.

Look, we could have built Yield a lot of different ways. We could have focused on USDC borrowing first, and that probably would have given us faster adoption. We wanted to do Dai first because we believe in decentralization. Decentralization is important. That’s why Yield v1 is fully decentralized, no governance, no upgrade keys, with Maker under the hood.

This MIP doesn’t help pump any tokens, and we don’t earn any fees from it. All we get is kudos. I hope that’s a fair trade.


Thanks man for the nice answer! :pray:

Keep up the good work!!! And if it might eventually interest you and Yield, consider proposing a Maker Core Unit (e.g., “Fixed Rates Core Unit”) to keep doing amazing things under the umbrella of MakerDAO! :muscle: :muscle:

1 Like

Hey guys,

Have you considered how this could affect Maker’s ability to protect its peg? Right now, when the Maker system needs to contract the supply of DAI it can raise the interest rate knowing that all Dai vaults will immediately start bearing this increased cost.

But if you allow people to generate DAI by borrowing fixed, the Maker system loses the ability to impose a cost on those vaults. If, for example, the majority of DAI were created via fixed borrowing, how could Maker incentivize them to close out their loans? Am I missing something or would this put at risk one of Maker’s primary tools to protect its peg?

1 Like

@twoodward In theory fixed term loans could potentially limit Maker’s ability to influence the peg through rate changes - you are correct about that.
However, one of the lessons learned from handling the peg is that sheer mass of DAI is at least as important as interest rate changes. Other methods such as PSM and soon™ flash loans are probably much more effective means to ensure the peg.

So I welcome MIP43 and have zero worries about the peg.