**Issue Discussion Call #02: Fixed-Rate Vault Solutions**

--- tags: Issue Discussion Call --- # **Issue Discussion Call #02: Fixed-Rate Vault Solutions** ## Agenda [00:10](https://youtu.be/44l1BQUQ9Os?t=10): General Introduction [03:30](https://youtu.be/44l1BQUQ9Os?t=210): Topic Introduction [03:30](https://youtu.be/44l1BQUQ9Os?t=210): Discussion Question 1 [18:49](https://youtu.be/44l1BQUQ9Os?t=1129): Discussion Question 2 [24:57](https://youtu.be/44l1BQUQ9Os?t=1497): Discussion Question 3 [30:08](https://youtu.be/44l1BQUQ9Os?t=1808): Discussion Question 4 [48:12](https://youtu.be/44l1BQUQ9Os?t=2892): Discussion Question 5 [50:47](https://youtu.be/44l1BQUQ9Os?t=3017): Discussion Question 6 [52:05](https://youtu.be/44l1BQUQ9Os?t=3127): Discussion Question 7 [54:49](https://youtu.be/44l1BQUQ9Os?t=3299): Conclusion ### Video <https://youtu.be/44l1BQUQ9Os> ## General Introduction ### David Utrobin [00:10](https://youtu.be/44l1BQUQ9Os?t=10) - Welcome to October 12th, 2021 issue discussion calls, a new series that we are piloting at Maker. - We use these calls to bring together broad stakeholder participation to focus on an issue and, depending on what it is, try to it down. - I have the pleasure of hosting this wonderful call focused on the fixed-rate solutions that have come about at Maker. And just as a brief intro to those solutions, there are currently three, and they are at varying stages of the governance process at Maker. - The first one is the term lending module, associated with yield protocol, and Alan numeric is here as our guest representing Yield. TLM was already ratified, and it’s currently in the backlog for being implemented in the protocol. - Second, there’s Deco protocol, which is led by Vamsi, who couldn’t make the call today, and his Core Unit is in the solution for fixed rates in the middle of RFC, for doing it through a Core Unit. The term lending module was proposed as a technical proposal, and Deco is being offered as a whole development effort with its independent team. - The third and final fixed rate solution that the maker protocol is considering is the Pairwyse solution in the pre-MIP, pre-Core Uni phase; it’s still in the discussion phase. - This call’s theme is comparing solutions and figuring out what’s best for the Maker protocol and its end users. The TLM exists; it’s on the backlog; there is, in theory, a path for Maker to implement a fixed rate solution, but then there’s these other two that are in the process of also being considered. And so, to start the call, I want to give the guests who are Alan Niemerg from Yield and Akiva Dubrovsky from Pairwyse. ## Topic Introduction ### Allen Niemerg #### David Utrobin: Alan, do you want to start us off with the term lending module? Since you have the voters already on your side? [03:30](https://youtu.be/44l1BQUQ9Os?t=210) - I’m excited to talk about fixed-rate lending and how it can improve Maker. I don’t think the TLM is a fixed rate solution for maker bolts. On one level, before we even begin, let me just say that it’s maybe not even what we’re discussing here today. And I can talk about why; what I’d like to do is just talk a bit about your protocol and the TLM and how it works to understand the history of how we proposed it as a fixed rate solution. - Yield protocol was created with the idea of bringing fixed-rate, collateralized, fixed-rate borrowing and lending. That was our goal, and that’s what we’ve been building towards. We started by trying to solve the simplest problem that we saw, or maybe a limited problem. We want to be able to do fixed-rate borrowing and lending Dai using ETH collateral. We built what we would call Yield protocol version one; we just wanted to show that you could do collateralized fixed-rate lending in DeFi and use the technique we had published in the original protocol paper. - That technique is relatively simple in the sense that it may be or maybe not. Still, it involves a user deposit and collateral meeting a new kind of token against that collateral, where that new kind of token has properties like zero-coupon bonds, and which specifies the properties are, it’s a token that at some future date becomes redeemable for an underlying or base asset like that. That’s it. - The power there is what you can do with that system; you can do fixed a fixed-rate borrowing because you put the collateral, you met that token, and they sell it for the asset that you want the fixed-rate borrow. You sell it at a discount to the face value of that token, and the discount that you receive implies an interest rate. So, if you sell that, and your token matures in a year, and you sell your five tokens at 95, 0.95 Dai, for example, right, you’ve effectively got an interest rate of 5%, a fixed rate barring a 5%. - That’s just the general vision of what Yield protocol is and how it works. - For version one, we built it on just addressing that ETH-Dai situation, borrow a fixed rate Dai, you see. To make it all work and make it work well, we built it on top of Maker, so we’re using certain Maker parts in the backend, and after we did that, we found that like the Dai lending market, at least for the fixed-rate felt very illiquid. There weren’t necessarily many people out there who were looking to buy a fixed-rate denominated bond, which led us to build the TLS. A natural party here would like to own fixed-rate bonds that affect the bonds that pay and Dai. And that’s Maker, and Maker has potentially several reasons for doing so. One is that it promotes the Dai ecosystem to create liquidity there, which is useful. - Another powerful reason the Maker might want to buy fixed-rate bonds in the space is to manage the yield curve to better maintain the peg. - Thinking that through, and that potential there, that led us to create the TLM, but the TLM is a very comprehensive and powerful technology; on its protocol agnostic, it isn’t tied in with Yield in any particular way; Yield would just be someone that could, or one sort of possible use case. And it’s flexible. - If you create a zero-coupon bond like a token that meets the very simple standard on your token, it could, in theory, be bought by the TLS, so it’s very open and extensible. And it’s also just very tied to many Makers objectives over say Yield protocols objectives, for example, you say why the way that it works is Maker can choose which funds it might want to buy an ecosystem or bonds that correspond to that excuse my interface and, it can determine what interest rate wants to buy them at and then. - You know, how much debt it’s willing to take on to buy these. So it’s all in the control of the Maker governance. They can decide: we’re willing to buy five tokens, zero-coupon bond-like instruments for Dai at 5% and only 5%. It would let anyone sell those to the Maker, particularly ones that have already chosen it’s willing to buy at that rate. Then the tail end holds it until maturity, so it holds that bond until it becomes redeemable. - Then they’re essentially what it allows us is for somebody to come by and back out of the TLM at face value so that anyone can sort of close the respective redeem the bond on behalf of Maker. And that’s it, simple, open, and extensible. It felt like the easiest way to implement it, but it means that the protocol is just actually a one-use case for the TLM, and others could, in theory, be built on top of it. So, I think that with time passing, since we post it, and ecosystem is evolving. - I think other use cases might ultimately be more interesting or interesting, in addition to the Yield protocol. I think that’s an exciting and interesting possible thing to get into, into greater detail; just to summarize your protocol, we’re building fixed-rate, borrowing, and lending. We think Dais is a very important part of that. We think the TLM could be useful for encouraging that the fixed-rate and borrowing and lending part of things and many other use cases. I’m excited about how the TLM can address the use case; we want to talk to you today, but also awesome anymore, and I can talk about that a little bit as we go on, or maybe we can set that aside and sort of focus on the agenda we have for today, but that’s my basic spiel. - David Utrobin: If anybody has questions, feel free to add them to the chat. Typically like, we’ll hold them for the end. Then, we’re going to transition into a more discussion-based segment for the rest of the call. [11:45](https://youtu.be/44l1BQUQ9Os?t=705) #### David Utrobin: Does the TLM use the surplus buffer? - Allen: Yes, the TLM does use a surplus buffer. The TLM buys, as I said, these five tokens at a discount at face value, and eventually, they become redeemable, so a surplus is generated, and that surplus goes to the surplus buffer. [12:41](https://youtu.be/44l1BQUQ9Os?t=761) #### David Utrobin: It generates surplus? I think this question was on the other side if it use Dai from the surplus buffer for anything? - Allen: No. The TLM just simply makes money, does not spend any money. - David Utrobin: I also think, like his question was, from the context of potentially needing Dai liquidity behind FYI Dai, which I know as a part of TLM model is actually like, from the Maker protocol standpoint, it takes the FYI dye in series. It generates Dai against them, and that’s where you get that liquidity from, and so you kind of and you solve the zero-coupon demand problem by just letting Maker be the liquidity there. - Allen: That’s right, so I’m behind the scenes. Maybe it’s a little bit technical, but the way that that it works is Maker approves a particular type of token, particularly circuit bond that is willing to buy and when it buys those it goes into a special TLM controlled you know to join or you know, which is just a bucket that those bonds go into and then they can borrow Dai at face value against it. Or but for I guess it, it’s not face value; it’s at it borrows daI at the interest rate set by Maker Governance, right? It generates those Dai, and then it gives it out as the purchase price. So, no, that doesn’t come from the surplus buffer. It’s used as the core mechanism of Maker to generate the Dai that’s used to purchase the zero-coupon bonds. - David Utrobin: One question from Frank Cruz. What would happen if Dai becomes insolvent in Yield protocol does not? Does it mean that FYI Dai would need to be redeemed first during the emergency shutdown? - Allen: I think, raises a question that I should have explained. There’s the existing protocol that we have today Yield protocol V1, which is built on top of Maker and, since all the assets in Neo protocol V1 are held basically in Maker, the sort of emergency shutdown approach that we had in mind was basically like, Maker Governance figures out how to do with things. - The thing with Yield protocol version one is its limited lifespan; it ends at the end of this year. So, it doesn’t live much longer, and we’re about to launch Yield protocol V2, which is quite a bit different. And Yield protocol V2, we’re no longer built on top of Maker and are the key things we’re trying to do is permit other kinds of fixed-rate borrowing and lending for collateral. - So, you could, in theory, have USDC fixed-rate borrowing and lending protocol. In that case, for V2, which we believe is the future of the protocol. Then it’s different. When Maker is buying five tokens, they’re essentially subject to the control of the yield protocol. And therefore, you know, you do have protocol risk, right. So, there is some risk that the fly tokens that Maker buys may not be, you know, may not be paid back because of the hack or something. That would be something that should be sort of considered whenever, you know, a governance process is initiated to add, say, a Yield protocol Fi, token Fi Dai as, as something that’s going by. That doesn’t need to be figured out to launch the TLM. - The TLM, since, as I said, it’s protocol-agnostic, can be launched without, you know, even thinking about the risks of your protocol. If Maker governance decides we want to buy these spy bonds from Yield, then at that time, it should it’s entirely reasonable just to look and think, okay, what’s the risk that your protocol can’t pay back the stock future? - David Utrobin: So, the short answer to that is that during an emergency shutdown, there is some risk that five Dai can’t cover. So just for the audience, watching an emergency shutdown is something Maker voters can trigger, and it creates an unwinding of the whole protocol. So Dai becomes, all the Oracle price feeds freeze at that moment of an emergency shutdown, and Dai becomes a claim on a pro-rata portion of $1 of collateral. So that’s kind of what happens, and it’s curious to see what would happen to five Dai in that event? Like, presumably everything on the Yield system and Dai like nothing really would be broken? It would just be the price would not be par? And then Dai would just need to be redeemable. - Allen: I would have to give this more thought, but the initial reaction is just as we’ve said; that is, the protocol should continue to work fine. I don’t think it would break because your Dai would still be an ERC 20 asset that you could freely move around; it would just no longer be fixed at the peg, that that shouldn’t have - I don’t think, an impact on your protocol. It may impact the users, but not the protocol itself, and I don’t think it would affect the soundness of the protocol itself. ### Akiva Dubrofsky [18:49](https://youtu.be/44l1BQUQ9Os?t=1129) - Thank you, David, for having me here today. Let me tell you about myself and what I think Maker should be looking for in fixed-rate protocols. - Before this project, I worked at KPMG; one of my jobs there was to communicate the policy to the partners on avoiding conflicts of interest in blockchain. - Conflicts of interest or major issues in all businesses, especially in financial services. Anybody who understands the nature of business, and conflicts of interest, impede good business. - What I believe is that regulators very well understand part of that. Regulators have for a long time tried to enforce separation. In Canada, we have what’s called separation of the pillars, where different segments of the financial services industry are separated from each other. Originally that was going back to the Great Depression, the early 1900s, when commercial banking and investment banking were merged. The calls from investment banking permeated into commercial banking, which allowed for the low cost of capital. Then that part was largely created. The Great Depression created with Paper Imperium was pointed out in the forums as the Glass Steagall act. In many regulators, Canada, the US, and Europe, there was this idea that you need to keep the pillar separate. - That is one of the ways you prevent conflicts of interest. We believe that even today, regulators, even though the Glass Steagall act was repealed, there’s still been criticism of the financial sector, where conflict of interest exists because of commercial banking and investment banking. So, we see that Maker, we describe, we see, it’s not a bank. Still, it does parallel the commercial banking world where Dai is almost like it’s not a deposit. Still, it’s similar to a deposit. We see that we want to keep separate the commercial banking and the investment deal and aspects of DeFi because we believe, after a lot of research, regulators also want to keep the pillar separate within DeFi. - My background is focused on bringing out conflicts of interest and maintaining proper integrity and business to avoid that about my project work being separate. We’re not planning on ripping or asking for any money for MakerDAO. We believe that if we’re going to be in a profitable business, which is going to generate profit, we’re not going to ask money for MakerDAO because that would be commingling of the pillars, and we think that would sacrifice integrity. - Our product is a fixed rate product; it’s floating to a fixed product that solves asset-liability issues for Maker. We’re on the Main net with a small amount of money, and we’re going to continue to go to market over the next few months and plan to scale up. - As I said, we’re not asking for money from MakerDAO, or we’re not even asking for anyone to change any pieces of code. All our code integrates kind of seamlessly, right over the Volcan Dai systems that already just today. So, we were able to deploy everything. I mean that without even any integrations, there was all-time permission just by integrating with the API. - We didn’t notice that, as Alan said, the demand for fixed rates is not as strong right now for several reasons. One is that if you approach people who currently have vaults open, they’ll say, Okay, well, why do I need to worry about a fixed rate if there’s a $3 billion surplus buffer. - If there are billions of dollars in the surplus, that’s like protection against the DSR because the DSR can’t move on while the surplus buffer is there. So we’re not planning such aggressive marketing or launch for the time being, partly because we want to get, you know, low millions on the platform, and then as the DSR starts to move over the coming months, or the coming years, that’s when we’re going to look to scale. That’s a strategy which we’ve had really for quite some time. Now. That’s what we plan on pursuing. I think that gives you a good summary. We’re focused on minimizing conflicts of interests or preventing the formation of cartels by keeping separate pillars of investment dealing with commercial banking. We’re funded independently of Maker. The last thing is that we own the intellectual property for converting floating to fixed on MakerDAO that has been granted in Japan as of a few months ago. It’s pending in more countries as well. And after that, I’d like to open it up to questions. ## Discussion ### Question 1 #### Prose11: I was just curious if the speakers benefit and like multiple fixed-rate solutions within the protocol? Do you see any interactions between the different ones we presented here? And just more philosophically, a good thing? Bad thing? What do you think? [24:57](https://youtu.be/44l1BQUQ9Os?t=1497) - Akiva Dubrofsky: I think yes, money is to play here pretty well. I think the TLM is a great addition to me here. I’m a big fan of the TLM. Maybe one day I’ll be using my product, the Pairwyse product, or use the TLM? Who knows? I think the TLM is good. I don’t think it can work well with what I’m doing. And to answer Frank’s question, does Pairwyse use the circle over so we don’t touch the circle as buffer other than the fact that the revenues from the vaults go into the surplus buffer. So we’ve seen that, so we don’t catch it so much. But yes, I and antimony supplies, like I think we could potentially put FRA bonds into the TLM. That’s, that’s a great solution. - Allan Niemerg: I’d like to answer that as well. And first to keep it just to close your thought out. The TLM probably could work with, with yours as a system? I’m not super familiar with it. So I’m happy to take a look. I mean, we’ve tried to make it as sort of, as I said, protocol-agnostic as possible, so if you have something like a zero-coupon bond, that could be made to work. Regarding having multiple fixed-rate solutions, I think it makes sense to have various solutions in the ecosystem. For sure, I think that having lots of people trying different ways to make Dai great is valuable. That’s what I think; one of the fantastic things about centralized protocols is that you can build on top of them and do cool things. - I needed the question, should fixed rates be natively integrated within the Maker protocol or something left out in the community? And in on that, I think that the answer is what makes Maker better if there’s a reason that you need to, I don’t think you need to integrate fixed rates, borrowing, and lending to make in the Maker protocol natively, to make it great, but I know that there’s a lot of interest in doing so on, and if it solves, critical problems for users for Maker to do that, then great. I think that’s fantastic. I don’t think we should do it. I think one thing I was thinking about this, and just this problem that I’d like to key on is, I don’t think the decision should be like the way to think about it is, well, Maker needs fixed rates. - Therefore, we need to integrate something in there just because we need it. Therefore, we should build it into the protocol; that’s probably not a great consideration and could lead to a poorly designed product. And second of all, I don’t think that it should be done just like this would be a way to raise the TBL of Maker. I think that that is a poor way to think about what Maker, like maker succeeding. One of the great things about stable coins and Maker is it’s not TBL is not important. Maker success, I think, is when the maker ecosystem and maker economy perhaps grow. I’d like to analogize it to like GDP of a country, right? Like, what you want to see is lots of Dai out there being used and turned over by lots of people that success for Maker, not TBL, not how much is in Maker properly. It has Dai out there, and that can be done, improved by a core part of Maker being. - Now we have fixed-rate vaults on and, lots of people using that could be one way that you could there, or it could be, we have we’re supporting community-built solutions to do that, through many different ways. With that in mind, I think the form of success, multiple ways to do fixed rates in space, can be great. The limiting factor is probably things like: do we have the dev resources to do various things? Do we have the mental bandwidth that Core Units must get multiple things done? This is something beyond my ability to comment on, but I think what the Maker success case looks like in terms of the Maker success case? I think it’s probably like supporting lots of things. Different ways where you have diverse solutions that address different users’ needs. - David Utrobin: One interesting comparison piece between Pairwyse and the other two solutions is that on Pairwyse, you can have custom FRA, like OTC, you can kind of agree on custom terms. In comparison, the other two solutions have more fungible pricing strategies or like market discovery pricing strategies. On the one hand, I can imagine a world where a Pairwyse FRA is one tool that can be used, but a more standardized FRS can be too. It’s just whether you want to set a custom rate with a specific client, or if you want to kind of buy into, to the market set rate, or the governance set rate. ### Question 2 [30:55](https://youtu.be/44l1BQUQ9Os?t=1855) #### Primoz Kordez: I am curious about the Pairwyse. From what I understand, these two proposals differ because TLM depends on MakerDAO being the counterparty. MakerDAO is the lender, whereas its Pairwyse is the external lender. My question for Akiva is about the borrowing fix you mentioned as presently appealing. But what about the lenders? With yield farming taking place, the present rates are high. They may now be a bit lower, but no lower than ten percent. As an external partner that is not Maker, who is on the lending side would be willing to lend at these rates? How big is this market to find lenders to get two to three percent for six months or twelve months? My second question is for Allan. You mentioned the protocol risk that Maker would face, so there are dependencies. The same goes for Pairwyse as well. What is the magnitude of these rescore dependencies? From what I understand of the TLM, MakerDAO buys loans from your protocol. We need to evaluate every single aspect of your protocol. How do the auctions work? How do you set up parameters? Is there a governance token? - Akiva Dubrofsky: On my side, I can address that. The two questions are even somewhat connected. With all the different protocols, there is always the smart contract. Smart contracts are not always perfect. However, we have recently just engaged Peck Shield, which is one of MakerDAO’s auditors. They are going to be auditing our smart contracts over the next few weeks. Your other point about lenders is a good question. We already have relationships with crypto investment banks. We are developing more of these relationships to target lenders and/or corporate treasuries who want to secure some yield and are not interested in yield farming. Yield farming is very attractive for some people because of its very high yields. - There is also credit risk. There have been cases of sharp drops and credit losses. While not common, some people cannot risk this credit loss. When we are sourcing lenders for low-interest rates, those lenders all have the benefits of the surplus buffer. For example, Maker can have 55 million in the surplus buffer that is all junior and subordinated in taking the first loss against credit losses against the whole DAI supply. That exists in our platform. This led me to analyze how to put the surplus buffer and Maker’s creditworthiness to good use. We want to source lenders who like having the surplus buffer backing them up as credit support and a credit enhancement system. We are already collaborating with MakerDAO’s ecosystem to source those deals. If MakerDAO wants to continue building its financial institution, it must be placed to get DAI users. Part of this process is sourcing DAI users who want the good creditworthiness of MakerDAO and at a fixed rate. When the DSR was first announced in the summer of 2018, if I remember correctly, it was aimed to incorporate treasuries. It is incumbent on us to work together with the MakerDAO team and my team to source those lenders. That is how we build a successful ecosystem. - Primoz Kordez: Cool, thanks. [36:18](https://youtu.be/44l1BQUQ9Os?t=2178) - Allan Niemerg: I am happy to answer that question. Firstly, you asked who would be the lenders at two to three percent. With all this yield farming, who would lend at that level? That is exactly what led us to create the TLS. When we launched protocol V1, we saw weak interest from lenders to lend at this relatively low rate. With yield farming, people were looking to receive returns around 20%, which was quite high. Well then, who can lend DAI to two to five percent? Maker can. It makes sense for it to do so because this grows the total DAI usage in the ecosystem. This creates an incentive to grow the DAI lending ecosystem even at rates considered low by farming standards. That question ties in with why we created the TLM. On the second question regarding protocol risk, you must look at the protocol risk whenever you do something that ties with another protocol. In Yield, we are doing all the things you would expect. Our first protocol had at least one audit, and protocol version two has had two audits. The TLM has also been audited. For the Yield protocol, we are holding collateral for all issuing loans, so all the Fi DAI would be backed by collateral held in the system. Of course, we have a liquidation system that is not different from Maker’s liquidation system. - With that said, there are still risks. The way you manage that risk, especially with the TLM, is through the debt ceiling. You would limit how much exposure Maker has to any particular zero-coupon bond, or at least to any particular protocol via zero-coupon bonds, and you raise that over time as you feel increasingly comfortable with your counterparty. That is a simple and effective mechanism built into the TLM. While we have not yet put the TLM in place, we do not even have to look at the protocol risks because the basic module is not tied to yield protocol. As I said, it is a very open and extensible piece of software that five tokens can use. I noticed you are raising your hand; I’ll wrap this up. With five tokens from anyone, we can launch the TLM without having to do some big risk assessment of your protocol. It is just looking at that individual code. You can later decide if you want to add your protocol to the TLM. ### Question 3 [39:44](https://youtu.be/44l1BQUQ9Os?t=2384) #### Primoz Kordez: While smart contract risk is important when referring to protocol risk, I referred to governance risk. How are your two protocols being governed? What is the execution? Is there a community? Is there a token? - Allan Niemerg: I am happy to answer that for you. For protocol version one, we had no governance. The smart contracts were designed to be deployed on-chain and then run until their expiration at the end of this year in December. At the first launch of protocol version two, we will have relatively tight control over it from the devs. We will have a time lock in place to not just run off with the money instantly. The first step will be to make changes. After, we intend to slowly transition to multisig then make the transition to even greater community-based ownership [40:51](https://youtu.be/44l1BQUQ9Os?t=2451) #### Frank Cruz: To follow up on that question by Primoz, how important do the both of you think it is for Maker to have a monetary policy that controls fixed rates since we do not have a monetary policy in place? - David Utrobin: May I add to Frank’s question? It is interesting because TLM Pairwyse and Deco have different methods of rate discovery. Allan, you can answer the question as is; I will not attack anything. - Allan Niemerg: Thinking about Maker’s monetary policy is super important. The TLM places that in Maker’s hands by allowing it to set an interest rate that is willing to buy loans. Maker has absolute control over that. A future version of TLM could theoretically allow Maker to sell those loans at some rate to perhaps permit Maker to use the process of buying and selling term loans to affect monetary policy. That is a very exciting future because it is likely that the DAI denominated debt market will increasingly grow on-chain. It is very small today but will become very big. In the long term, using that market and affecting rates in that market by trying to influence them or setting the rates will be a powerful tool in the toolbox of Maker. When we were building the TLM, we were especially looking forward to that future. We thought about building a tool to further our direction and insight into setting the long-term rates to improve monetary policy at Maker. [43:17](https://youtu.be/44l1BQUQ9Os?t=2597) - Akiva Dubrofsky: Setting fixed rates is essential for MakerDAO. It is a simple exercise. You can just talk to different people who are involved with the RWA. This could be an agent helping facilitate a transaction with Maker or the end client with a lending company. Ask them if they can afford GSR exposure. The answer is always going to be no. Certainly, nobody in the RWA business can accept a DSR term in their credit facility within the present near future. In addition, I would add to something that we have been talking a lot about in the forums. I am happy to see some good interaction from Maker’s response to this idea. Once you are decentralized, have a fixed peg, and set fixed interest rates, you are at attention. You can set interest rates and have your fixed peg. - We have been trying to draw attention to this asset-liability management issue. The solution lies in the fourth part of this trade-off which is the maturity and tenor of each contract. Maker certainly wants to set fixed rates and keep the peg. Then the last tool, used by every financial institution to manage the assets and liabilities, is to control the client tenors and maturities. Suppose Maker wants to set peg DAI that is good. If Maker wants to keep its decentralized aspect and offer fixed rates, that is also good. After you have selected all three, the final tool is to build an adaptable and flexible asset-liability policy that sets tenors and maturities to allow for capital flows in and out of MakerDAO to maintain equilibrium. When I first started this project, this was the result of my research into this topic. I want to give a huge shout-out to Makerman, who in the forums and calls picked up on this as being quintessential to everything MakerDAO does. We see this as the solution, and it is very promising to see the future that way. ### Question 4 [46:02](https://youtu.be/44l1BQUQ9Os?t=2762) #### David Utrobin: As a person who is not deeply inundated with knowledge on fixed-rate protocols, I am curious about the rate discovery. Yes, Maker protocol needs to set these fixed rates. However, its method is not by setting the rates directly but by controlling the tenors and maturities. Is that what you are saying? Is it still fundamentally a free-floating rate market? - Akiva Dubrofsky: You have to offer a fixed rate. Yes, the maturities and the tenors are used to control the pack. Banks will create a level of assets and liability that make these lines appear to overlap. And in doing so, they maintain cash flow in and out of the institution in a stable way. Now doing that allows you to maintain the peg in a stable way. We see this as the solution to the impossible trinity that Maker is facing. You want to have your cake and eat it too. You want to have all the features of your ideal currency, but you are faced with essential drawbacks. A simple example is that you get a client who wants to open a vault, and their collateral is super safe. So, you tell them that I will offer you a low rate, and you can only accept the fixed rate. The collateral is super safe, so you charge them a cheap interest rate. When you do that, your monetary policy and the DAI head go off, and now you must raise the DSR. Your hands are now tied behind your back because you just promised your client a fixed rate due to their safe collateral at such a low rate while the DSR is going crazy. How do you deal with that? This situation is an asset-liability issue. However, we believe it is possible to have fixed rates and a stable DAI peg if you maintain that ALM policy. ### Question 5 [48:12](https://youtu.be/44l1BQUQ9Os?t=2892) #### David Utrobin: That is interesting. How does the PSM fit into this because? It sounds like you are not factoring it in. Does PSM fix the problem? - Akiva Dubrofsky: The PSM only works when the DSR is at zero. Once the DSR goes to zero, the PSM kicks in. If DAI drops below one dollar, the PSM has already been cleared out with all those billions. Then if the peg drops below one dollar, you can no longer use the PSM to set the peg back. This happened to Maker in 2019. Maker can only get the peg back on track if DAI drops below a dollar by aggressively hiking the interest rate; if it is not done aggressively, the DAI peg breaks. People will lose confidence, and everyone will go crazy. What if you have that 2019 scenario where you need to get a bit hawkish? Meanwhile, you just promised your best client these low fixed rates. That is the core of the issue we got set up to solve. - Allan Niemerg: I would like to extend on that. You kept us right in terms of the angle at which he was approaching. But in terms of the TLM, Maker controls the rates at which it is buying via the TLM. It can raise those rates at any time via the governance process. So, as you could imagine, in the same call that you are deciding the ETH-A rate or the DSR, you can also decide our rates for the TLM. You can raise and lower those as appropriate to affect monetary policy. It does not change the rate somebody has already previously locked in via the TLM but would change all future rates, which is a powerful tool itself. In a future version of the TLM, if Maker wants to further affect rates, it could add a feature where it starts selling perhaps five tokens or the zero-coupon bonds that it has brought to alter interest rates in the ecosystem. The TLM, in that sense, is not fixed in quite the way Akiva was talking about if you just had a fixed rate bolt that you have given someone. You can always change things on the margin; you are just not changing fixed rates that somebody has already locked in. ### Question 6 [50:47](https://youtu.be/44l1BQUQ9Os?t=3017) #### David Utrobin: You are only setting the rates of any new maturities and new series that are coming out as they come out. Did I ask if there is any fundamental problem with Maker setting both variable and fixed-rate products? I’m curious if there is some sort of conflict of interest there. At the beginning of the call, Akiva talked a bit about the separation of certain activities, but I was unsure if this was what he was talking about. - Akiva Dubrofsky: Fixed rate and variable are possible. A lot of financial institutions do that. What we need to separate is the core MakerDAO business and the business of selling fixed-rate products. Maker can offer it at its core level. However, that investment dealing process needs to be kept separate from the actual sales function of roadshows and sales presentations. In terms of the core Maker level, it can offer different products. - David Utrobin: Okay, I understand. Thank you. Frank just posted in the chat. Frank, do you want to get on the mic? ### Question 7 [52:05](https://youtu.be/44l1BQUQ9Os?t=3127) #### Frank Cruz: Yes. Most folks are focused on the fact that there has been a lot of appetite for fixed rates. Most people have not thought about the technical challenges associated with such. I wondered if anyone could bring up anything about the technical challenges of integrating with the Maker sandbox? I ask because Vamsi, a former foundation employee and CU team member, probably knows the system better than most of us on this call. I have not checked with anyone here. Hopefully, you understand my question. - Akiva Dubrofsky: There are different challenges in setting fixed rates, such as the technical challenges aside from the business and monetary challenges. One thing is computing the simple computations of what the interest rate is. On Maker, everything is compounding on an instantaneous basis. These are some challenges. We have engaged the best developers in addressing this, such as mathematicians who can calculate the per second interest compounding. There are also technical considerations around the components of a vault interest rate. What we have done to address this and to make it a good experience for our clients is building simulation. We run forks of the blockchain all the time, which forks the MakerDAO code by going into it and start playing with all the interest rates. This is all on test nets and the net forks, not the main chain, and we play with the interest rate. We test to see if our calculations are accurate. We run this for clients all the time and show these little charts of where the DSR goes up and down. We find that no matter where the DSR goes, we can always calculate and achieve the correct balancing. That activity helps us in our sector and sales. ## Conclusion ### David Utrobin [54:49](https://youtu.be/44l1BQUQ9Os?t=3299) - Nice. We have about one minute left of the hour. This call was fascinating. We hit on a lot of related but spread about points. The goal of this call was to give the attendees and the viewers a better understanding of the differences, status, and trade-offs of each of these protocols. Even for me as the host, there are still a lot of open gaps in my understanding, so I can imagine how a viewer or a voter is also approaching this. I want to caution that if you vote or consider these solutions, do not just reply on this call. There are many additional resources, from all three solutions, from Yield, Pairwyse, and Deco. As we progress, we are going to be able to further compare the solutions. I hope this was super helpful. I will give it over to Akiva and Allan to give their final contact info if anybody is interested in following up. Thank you, gentlemen, so much for coming on the call and taking your time out of your day to speak with the Maker community and to dive into these interesting, complex, and important topics. - Allan Niemerg: Thanks, David. I am happy to give a place for people to find more information about us. Soon we will be live at [yieldprotocol.com.](https://yieldprotocol.com/launch/) You can follow us on Twitter [@yield.](https://twitter.com/yield?lang=en) - Thanks, David. I just posted my email in the chat. It’s Akiva@Akiva.capital. I look forward to hearing from you. - All the links can be found in the call notes, so you can find those on the forum. Anybody with the link can view, and those will exist into perpetuity. Thank you guys again, and I look forward to our next interactions. ## Credits - Andrea Suarez produced this summary. - Artem Gordon produced this summary. - Larry Wu Produced this summary. - Everyone who spoke and presented on the call, listed in the headers