Fixed Rate Vaults Proposal With Deco Protocol

What more encouragement do you need? Do you want Recognised Delegates to weigh in with comments? @PaperImperium @Planet_X @ElProgreso @monet-supply @twblack88

7 Likes

I am generally in favor of what is presented here. My main hang up is with regard to whether this would attract unwanted attention as a security or if it can be structured such that it is clearly not one.

But — with the caveat I prefer to read through things a couple times on different days — I like the functionality if I understand it correctly.

So put me in the “I’d like to hear more” camp.

2 Likes

Have you “testnet” tested this scenario, or you’re assuming all the stars will be aligned if such a scenario plays out?

To be fair—this is probably something @niemerg Yield can add.

Fair enough—but perhaps one day this can be automated.

This is super cool. :+1:

Yup—that came across my mind—but I think this product is unique in the sense that I can’t identify it with any traditional product available today—but maybe I’m not thinking clearly :thinking:

BTW, I wonder if products like this would have an effect on “investment interest expense” for Yankees like us? Meh, hard to tell since IRS can’t provide clear guidance…

@vamsi hey man—looking over the Deco docs, can you please explain the following, and how are timestamp kept accurate, or safe from being manipulated?

“Within insert , governance is allowed to calculate the fraction value externally and directly insert it at a timestamo. It is up to developers to allow governance to overwrite existing frac values, insert values at future timestamps etc. Both are dangerous practives and should typically not be allowed.”

Would it be fair to say that, in your presentation, you basically make MakerDAO issue interest rate swaps? MakerDAO would be the counterparty as it doesn’t have collateral issues (as MakerDAO can print as much DAI as needed, no need to put collateral aside).

While MakerDAO is good at that, no secondary market can (yet). Buyers need to pledge the full amount of future interests upfront. I understand those CLAIM-FEE-ETH-A would be quite complex to manage on a secondary market (as you will have many series, one for each call/minting?).

Therefore it would be similar (but more flexible) to having term vaults on MakerDAO (like ETH-TERM-2022-08). At scale, it poses the interest rate risk that MakerDAO would face (which might or might not be an issue, it’s MakerDAO Governance to decide).

It would prefer to start (or do ni parallel) with an ETH-TERM-2022-08 (maturity August 2022 where SF is raised to 100%), 100M DC, SF 3% (more precisely 3% origination fees and 0% SF) and see what happens. Fixed borrowing demand is currently a hypothesis, let’s find out if it is really there.

4 Likes

I think this is the reason that Deco offers Maker a competitive advantage. Maker is uniquely positioned to take the opposite side of the swap more efficiently than any other potential counterparty. Even if there isn’t much demand for hedging with CLAIM-FEE tokens, I think Maker could gain a lot of information by regularly auctioning CLAIM-FEE tokens at various durations on major vaults like ETH to do price discovery on the yield curve. This could jump-start interest in hedging. Why should we only do custom deals with Institutional and Long Term Vaults Proposal when the origination fee could be a generic feature available to all?

For CLAIM-FEE tokens, what would be a good initial maximum duration? 1 year? 2 years?

Okay, maybe roll the proposal into MIP39c2-SPxx: Adding the StarkNet Engineering Core Unit (SECU) ?

2 Likes

The only thing Deco does is allow you to pay the security fee at a different time (now vs later). How could this make a difference about whether CLAIM-FEE tokens or vaults are a security? It’s just splitting existing vaults into two separate stand-alone products.

1 Like

If we offered it only to the vault user, perhaps? Unsure about what happens if there’s a secondary market.

I like the gist of it. But we live in a treacherous neighborhood and just need to make sure we don’t antagonize anyone needlessly.

I think there’s potential here and want to know more.

So, sorry to be that guy but… I have like no experience in financial instruments beyond what I’ve picked up from crypto. I’d really appreciate it if you could help me understand better how this works.

I think I understand the goal - provide users with fixed-rate vaults over a certain time period.
I think I understand the benefits - open up a new market and mint more DAI (though I do wonder if that market is as large as everyone is hoping. I’d be astounded if we saw 3x the current ETH-A issuance as a result of this for example. Maybe I lack imagination.)

What I don’t understand is the costs and the implementation.

So for costs:

  • How do we ensure that fees are stable? Who pays the difference if fees rise? Who receives the difference if fees decrease?
  • Does DAI remain fully-backed throughout this (given that we’re talking about using DAI minting to compensate for the lack of a counterparty)?
  • What are the initial and on-going governance costs to this? (What does governance now need to worry about and manage with the addition of DECO?)
  • What are the development and deployment costs to this? (What new vaults do we need, what new development needs to happen?)

For implementation:

  • I’m not even sure where to start here. I’m afraid the (very pretty) clarifying diagram was not terribly clarifying for me. I think the main issue I had with it was that I didn’t understand why each of the steps was being made? Like I understand the eventual goal, but not the breakdown of that goal into the steps communicated.
  • How does this differ from us creating an ETH-D vault and pledging that the stability fee will not change for time t? And what is the benefit of this over that?

Maybe you can walk through what implementation looks like from our perspective (fill in the ???)

  1. Governance decides it wants to implement DECO.
  2. ???
  3. Profit (presumably.)
4 Likes

As somebody not affiliated with the Deco term, let me see whether I can answer your questions. Obviously @vamsi can correct me if I come to any wrong conclusions. I’ll update my reply in an hour.

1 Like

A CLAIM-FEE token is composed of a notional value and a duration. For example, suppose I draw 100 DAI from an ETH vault for two weeks and then pay it back. I am obliged to pay the stability fee during those two weeks while the loan is outstanding. If I buy a two week CLAIM-FEE token for the notional amount of 100 DAI then that CLAIM-FEE token will mint exactly the amount of DAI that I will need to repay the stability fee of my vault (regardless of changes to the stability fee by Maker governance).

  • notional value = 100 DAI
  • duration = two weeks

However, the CLAIM-FEE token does not have to match the value and duration of my loan. If I hold my 100 DAI loan for more than two weeks, the CLAIM-FEE token will expire; I will be back to paying the floating stability fee out of my pocket, the stability fee which is a floating rate determined by governance. Or alternately, suppose I take out a 200 DAI loan instead of 100 DAI for two weeks. In this case, the CLAIM-FEE token will only pay for half of the stability fee.

Now to answer your question. CLAIM-FEE tokens are purchased by vault owners and are sold by the Maker protocol. Once purchased, the CLAIM-FEE token mints DAI to pay the stability fee (whatever the current rate is) for the duration of its existence. If the stability fee increases after the CLAIM-FEE token is issued then the vault owner will save some money on the stability fee and Maker will collect less DAI then it would have had the CLAIM-FEE token not been purchased. If the stability fee decreases after the CLAIM-FEE token is issued then the vault owner overpaid and Maker will collect more DAI in fees then it would have otherwise. The other thing to keep in mind is that the fees are collected at a different time: with CLAIM-FEE tokens, the fees are collected by Maker when the CLAIM-FEE token is sold. In contrast, without the CLAIM-FEE token, stability fees are collected continuously by the Maker protocol.

The worse possible situation for the Maker protocol is to sell long duration, high notional CLAIM-FEE tokens cheap while the stability fee is zero and then for governance to aggressively raise the stability fee very high. Suppose the stability fee is raised to 20%. In this case, fortunate vault owners who purchased CLAIM-FEE tokens will not be affected by the new, much higher stability fee until the CLAIM-FEE tokens expire. So DAI remains fully backed, but Maker is not able to change the price of risk on these vaults until the CLAIM-FEE tokens expire. Presumably we moved from a low-risk environment to a high-risk environment. The CLAIM-FEE tokens delay the change in fees.

Although it may seem like it would be hard to manage hundreds of CLAIM-FEE tokens with different durations and notional values, they are all priced the same way. There is some mathematical formula that takes CLAIM-FEE token parameters and the stability fee, and outputs price. Another ingredient to this formula is some measure of expected stability fee volatility.

Governance can look at the total duration and notional value of issued CLAIM-FEE tokens to understand how much inertia exists in anticipation of changing the stability fee. If all outstanding DAI loans are 100% covered by CLAIM-FEE tokens for the next two years then stability fees have been effectively fixed for two years. Governance can change the stability fee, but it will not have any effect on loans covered by CLAIM-FEE tokens.

It is the same, but how do you choose time t? With CLAIM-FEE tokens, any arbitrary duration can be selected by the buyer. As CLAIM-FEE tokens are issued, every one will have a different duration. I don’t really see how to offer this kind of duration flexibility via a regular vault.

6 Likes

Thanks for this question: no assumptions are being made regarding star alignment. Please note the next sentence, which describes how the design that handles any abrupt emergency shutdown when there is an untoward event. This is an additional feature to improve the MakerDAO UX and ensure that Dai holders do not have to think about new assets like fyDai or CLAIM-FEE tokens when going through the redemption process.

You can find the tests for the close feature which this relies upon in the codebase. deco-base/close.ts at master · deco-protocol/deco-base · GitHub In the past, I have written specifically about emergency shutdown and how integration partners can mitigate losses for their users by using the right patterns. developerguides/emergency-shutdown-design-patterns.md at master · makerdao/developerguides · GitHub

There is a fully trustless function called snapshot to capture yield values for the current timestamp directly from the smart contracts and then referenced later. Timestamp is a block timestamp and cannot be manipulated. Yield value comes from the FEE token directly.

The instructions are written for integration developers to remind them of the tradeoffs they make with certain choices: insert is an optional function which we ask them to keep in mind and implement to allow governance (MakerDAO in this case) to insert yield values, and also to give guardrails to developers to be placed during the implementation design phase in order to restrict what governance can or cannot do.

The snapshot function is its trustless equivalent, where the yield values are captured directly from the FEE token. The whitepaper goes in-depth on why implementing only the trustless function is not always safe for users. We will work with MakerDAO and decide which one to implement based on the requirements gathered.

Their effective collateralization ratio will have to be maintained a bit higher due to the upfront cost. I don’t think it is an issue specific to Deco though, as it will be the same when vault owners use an up-front origination fee solution as well. Any fixed-rate solution that does not collect the fees upfront for the term risks the vault owner halting their payments mid-way.

The timestamp when minting occurs does not automatically become the issuance timestamp. Thanks to this design, there is no fragmentation or creation of a new series automatically for each minting. MakerDAO is able to mint more to satisfy new demand for an existing standard series in the market. The number of series in the market will be determined by business goals and requirements. The technical implementation is already designed to avoid fragmentation and align on standard issuances.

One big complaint against Maker vs Compound or Aave is market rate discoverability; this design achieves this feature through a sales process.

The smart contracts that need to be developed to charge 3% origination fees are going to be a bit complex as well considering Vat cannot be upgraded and all solutions are similarly bolted on. We’ve designed Deco to achieve a superior UX solution for vault owners. With these goals in mind, we hope that when we move to evaluate market demand and fixed rate appetite we are not confounding user experience, third party protocol risks, and market demand. Some other confounding factors we have attempted to control for are MakerDAO setting a suboptimal right fixed-rate and reducing demand, or only evaluating market demand from large vaults and accidentally omitting the smaller vault market segment.

Considering crypto markets, and the need to pay stability fees upfront, our current suggestion would be to start with a 6-month maximum.

Assuming you mentioned L2 to improve UX, we describe above how Deco does not fragment issuances beyond what the market desires and create a UX problem that requires vault owners to do a ton of transactions.

3 Likes

In order for an RWA issuer to have proper ROI on their investment in the Equity/Junior/Subordinate tranche - they cannot pay extra for additional contracts. This makes the “I” in ROI proportionally bigger and hence the “R” proportionally smaller. This effect is amplified with the duration of the contract. It messes with the “gearing.”

In an ideal solution the RWA issuer would rehypothecate their Vault collateral and use that to pay for any additional hedges.

3 Likes

It would be easy to structure this within the sales process by giving additional CLAIM-FEE tokens to the vault owner to cover all additional stability fees they would accrue on their additional I. Maker and RWA issuer can use a structure like this in their shared definition of ROI. You should note that vault owner is allowed collect yield from CLAIM-FEE tokens multiple times before maturity date and can rebalance periodically pushing their total debt back to the fixed debt amount which means their I will stay constant for the duration as defined upfront. There is no effect, which means there is no amplification of it either across any duration.

@psychonaut was spot on in his reply. I’ll add some more context to his answer.

Dai remains fully backed throughout. ZERO-FEE tokens are locked as collateral and back the Dai debt. These ZERO-FEE tokens themself are fully backed 1:1 with Dai, and which are always present within the system and used to cancel the debt once ZERO-FEE tokens mature. Additionally, we have an emergency-shutdown mechanism which can trigger debt cancellation immediately, irrespective of the maturity date, if emergency-shutdown in Maker is triggered.

The initial step is to setup the ZERO-A collateral type and adapter so that can create CLAIM-FEE tokens for all collateral types.

One Deco instance, and FEE token, needs to be deployed for each collateral type MakerDAO wishes to introduce at a fixed rate. Unlike other fixed-rate protocols, Deco is built to handle all maturity dates from one deployment. This design effectively reduces the work needed for MakerDAO. There is no longer a need to deploy these contracts every month or every three months for each collateral type due to maturity dates.

No on-going smart contract deployments are required beyond those noted above and weekly or monthly CLAIM-FEE issuance will be executed using this infrastructure through spells to meet the business goals of fixed-rate sales.

Deco’s will handle the settlement and remove the tokens issued from circulation, as well as the debt in the ZERO-A collateral type, after maturity, without the involvement of governance using public functions anyone can execute.

ZERO-A adapter contract and FEE token development are Maker specific and the cost of development would be borne by MakerDAO as part of this integration. We have incurred the cost of Deco development and the design cost of a Maker integration. If the project is approved, there will be the cost of integration and deployment of the Deco Protocol on Maker.

The goal is to have a free-standing token like CLAIM-FEE which vault owners can independently use to off-set the fee changes that would happen on a normal vault.

In Step 1, we are creating the tokens (CLAIM-FEE) which are used to track the stability fee for a collateral type and a fixed duration.
In step 2, these tokens are sold to vault owners who pay an upfront cost for the privilege of purchasing these tokens.
In step 3, the vault owners hold the tokens; if the stability fee changes, Dai flow through the claim token changes in turn, effectively providing a stable fee. The vault owners fee is fixed at the upfront cost paid to purchase the token and holding the token offsets any additional stability fee accrual.

There is no way to incorporate a maturity date within ETH-D. So, Maker would have to maintain multiple ETH-D collateral types, e.g., ETH-D-SEP21, ETH-D-DEC21, at the bare minimum, unless the complexity of managing maturity dates is forced outside to a Deco-like solution.
Deco is built to attach maturity dates to assets, and consequently allows the same ETH-A vault to target any maturity date.

MakerDAO has to update the stability fees after the maturation date to match the ETH-A stability fee. But Maker governance cannot force debt payoff right after a maturity date and move the vault owner back to the main ETH-A vault. Maker governance can threaten with a large stability fee increase and perhaps force the vault owner to move, but the process is not deterministic. We can already see this issue in the amount of debt Maker is forced to hold on to for long periods despite setting the debt ceilings to 0.

If an origination fee is not collected upfront, the vault owner will use it only when the fixed-rate is favorable and has a free option to move during the fixed-term. There is no way to lock-in an ETH-D-XXX vault owner for a fixed term without requiring payment of an origination fee; otherwise, Maker would risk a re-financing as soon as rates drop below the agreed upon fixed-rate. Additionally, Maker has no way of imposing a penalty fee. Selling CLAIM-FEE tokens at the market rate forces vault owners to book a loss or gain, and to be exposed to market conditions should they wish to exit the fixed-term early. Handling these issues may require some additional development or maintenance, but certainly cannot be accomplished by simply creating an ETH-D type and attaching a pledge from governance.

At a high level the missing step is, Maker gives Deco an implementation budget to develop the additional adapter and fee token contract required for the integration. Deco sets up a core unit to operate this feature on behalf of MakerDAO and receives a share of the fixed-rate revenue.

5 Likes

I am still trying to digest this but it looks like what is being proposed here is a prepaid Maker SF vault fee token. Basically the user purchases this token by paying up front the DAI in SF over the period of concern at the instantaneous SF rate. Not understanding the mechanics but intent is that once this token is purchased it basically has a price decay like an option which will either expire in or out of the money so to speak. This looks to me like a separate product that costs the borrower extra up front, that doesn’t do anything to stifle the SF fees accumulated in the vault. At some point it is expected this token product would be redeemed within a market based on the difference in fees.

Here is what is not clear to me. If rates drop basically the fund that accumulated the extra SF fees will be in surplus relative to the markets. Basically the fund for a particular note can only redeem for some fraction < 1 of the purchase value because the rate par value has dropped. The opposite is true if the SF increased. The fund basically will not have the funds to cover redemptions, or someone taking the opposite side of the interest rate bet on these token instruments will have to cough up DAI. In turn the holders of these notes will have to redeem to get their DAI and then they can pay down their loans.

My biggest problem with these is going to be the extra gas and transaction costs they will incur. 1 month worth of interest at even 5% on 1M is going to be about 4170 DAI. If this rate difference is 1% this drops to like 800 DAI. I don’t see who is going to be the counter party to these at institutional level investing, Maker protocol itself? My problem here is that the only clean way to do this is to segregate the DAI from these instruments from the surplus generally. I also have a significant concern that if Maker needs to move on rates against these contracts it will effectively tie hands of governance in a lose if you do, lose if you don’t scenario.

SInce these notes are not going to pay SF, and basically act independently of the protocol as a kind of interest rate spread insurance instrument prepaid in DAI, paying out in DAI at term why does this have to be tied into the protocol at all? Why not do this independently of the protocol using a completely independant bond fund? Use this spread to earn return. My point here is that using the DAI SF over the term up front isn’t enough of a risk premium. Normally such instruments are going to collect a premium on top of what they know has to be paid and I see no mechanism for pricing this ‘at all’. This is a cost free interest rate risk spread as it is structured and so can only yield returns for the backers if rates are going to drop. Even if rates stay the same - there are no gains to the counterparties to these notes.

I don’t see the benefit here and I also don’t like Maker basically being the counterparty in this fashion because governance will not be free to move rates without possible loss or gain implications on these instruments. Loosely speaking if the protocol sells these governance has a strong conflict of interest that regulators would surely ‘look into’ if the holders of these instruments lost money.

I am not even sure this can be structured not to come under scrutiny as a security honestly.

I want to remain open to these and really need to spend some time looking at this, but just logically thinking about this I don’t see how the protocol can take this on without having significant conflict of interest.

Honestly going to have to read more carefully the above, but not seeing any mechanism for fee management above and beyond the SF due to be paid over the period I don’t see how these can work at all. Maker as the counter party on these entails conflict of interest as well.

1 Like

If you had bothered to study the proposal then you would know that Maker is the counterparty. Since Maker is the counterparty, DAI can be minted to cover redemption and any surplus would be added to the surplus buffer.

Yes. That’s why Maker is uniquely positioned to implement this protocol in a more gas efficient way than a 3rd party.

I don’t follow you here. Maker has to price the risk environment anyway. How does adding floating-to-fixed tokens pose any additional conflict of interest?

2 Likes

Apologies for not digging deeper was just trying to deal with this from what was posted here vs. a document deep dive.

Yeah I guess that is what is required here given the complexity of this. Actual many hours worth of study to digest some basic issues. The basics of how this is might even look from a vault users perspective. What funds go where, and when? What market is being talked about. My problem here is the deco documentation is trying to be general, and even the specific Maker example in the proposal post talks about 100,500 DAI and has a figure showing 12,500 DAI and even then things about the numbers don’t match. This alone stopped me from trying the ‘whitepaper’.

Can we simplify this somewhat.

If there are markets please explain who is the buyer and seller of what? My problem here if these CLAIM-FEE-ETH-A tokens can hit any market is the expectation of return, this by definition would make them a security.

If the markets are internal and have basically fixed prices based on the difference between the instantaneous SF from the purchased - locked SF within a ‘period’ of time covered by the instrument then there isn’t a market but simply a price.

Here is my problem with this. Lets say these CLAIM-FEE-ETH-A tokens are just an internal accounting mechanism, there is only one market which basically works as follows. Maker vault protocol sells or buys these from Maker vault owners protocol to person. A vault owner can purchase them or sell them back to the protocol (or make claims for DAI based on return). In effect these become a rate modulation instrument between Maker and the Vault owner. The mechanics of this while relevant are irrelevant because there is no market. What is entirely unclear to me is how the DAI mechanics work on this vault if these options are a just an internal accounting mechanism for the SF lock - SF floating rate * time.

Take the example with the 100,500 DAI outstanding debt, 500DAI that went Where? and 100,000 DAI that the user has borrowed and the 100,500 CLAIM-FEE-ETH-A that are ‘Where’? Now the vault owner has 100,500 DAI borrowed not 100,000 so the interest will be 502.5 not 500 over the period of interest which didn’t jive for me. Other points/questions

So 500 DAI is the interest on 100,000 over 3 months (SF 2%). For simplicity lets say the SF rate instantly jumps to 6% once this option is released and purchased. Will the vault DAI debt after 3 months be

100,500? or will it be more like 101,500 and the vault holder will basically have an option worth 1500 DAI they can redeem, or will this look like something else.

If the 101,500 is the number (and not something else) where does the 1000 DAI come from and when does it move where?

Another question - what happens if the vault owner decides to pay back the debt after 1 month and the SF is still 2%? Do they then get to sell/redeem the options to get their 333.33333… DAI back or what?

My problems with reading this is that the numbers just don’t match. Is the borrow 100,500 or 100,000. When does any surplus or deficit in these ‘interest rate options’ get paid, to/from where?

Regarding conflict of interest here. I really had to rethink this because no matter how one looks at this - some interest is being paid by vault owners. The issue becomes how much. Invariably there will be this temptation by governance (rightly so btw) when considering rate changes to vaults to have to consider how much money will be made or lost with these options based on SF changes. This may potentially affect how governance sets rates to the favor of generating returns over risk management to the detriment of DAI holders potentially. Not saying this is true but it could complicate this. Is it a conflict of interest, maybe not…

Edge case in point.
Why would the protocol sell these options at 0%? Why WOULDN’T it sell these options at 20%. Now a vault owner if they can get these options for 0 cost at 0% - why wouldn’t they buy all they could for free? And at 20% why would a vault owner in their right mind buy them? The conflict of interest here is in the sense of issuance management and using this structure to generate additional return from vault owners by basically selling lots at high rates (whatever that is) and selling none at low rates.

Scratches head here. At this point I am just not seeing how this is good for the protocol and not something that is done by a 3rd party on a cheaper network. My problem here is if interest rates are 0 basically the fees to buy these would have to represent the risk of SF being increased to some level over the time frame of interest. Same issue would occur when rates are high the fees to purchase these would likely be low I don’t see the pricing mechanism for this SF rate change risk at all in the pricing mechanisms. If there is a real market pricing these, well then I am back to them being potentially a security because they promise a kind of return even if it is paying less interest which based on the above is entirely unclear to me. Are these things options that redeem DAI that is used to pay down DAI debt, or are they options used to reduce DAI debt.?

Thanks again and my apologies I literally don’t have days to dig through this. It already looks complicated enough to cause me to pause… The implications for smart contracts changes, and implications to SF management seems really complicated and I don’t see the protocol getting more income but less for the most part implying a higher risk profile at key times.

1 Like

@vamsi I started reading but found the text hard to follow.

You start with the terms “fixed rate” and “yield rate”. Fixed rate’ is defined and understandable, but “yield rate” is here used in contradiction to the normal meaning.
I assume that you mean “variable rate” or something along those lines?

Further down in the text “fixed rate” and “yield-rate” were replaced by “pure-yield” and “zero-yield”, but I found no definitions or explanations of these terms. In light of “pure-yield” being a term that Google could not help me with, I think this might need clarification. Also, the words “yield” and “rate” appear used in a way that mixes up the two, but they mean different things.

Where will the FEE-CLAIM tokens be traded? How many different versions of this token will there be?

Reading the first pages of the whitepaper did not assist my attempts to climb the learning curve. This is most likely due to my limited ability to understand new things, but you might want to take a look at that document as well.

1 Like

Many of the assumptions you have made, e.g., the difference calculation, possibility of going OTM, price decay, are not applicable to Deco and the proposed technical solution. This is a novel and disruptive product and as such, reaching clarity in understanding the technical solution can be challenging. Consequently, we intend to hold a launch pod session to review the technical solution and its implications. We would be pleased to have you join us. We will also be recording the session and it will be available for later viewing.
In short, the CLAIM-FEE token purchaser is not purchasing an option, nor is the purchaser exercising an option at any point before the maturity date. The purchaser will always collect the yield received from the CLAIM-FEE token. The purchaser will not be OTM before expiry if the difference in rates is lower than the locked-in fixed rate. No Difference Calculation is being performed either within Maker or within Deco.

There is not a solvency issue because Deco is not independent of the Maker protocol. In this proposal the Maker protocol is the exclusive issuer (no one else is authorized to issue), giving Maker certain advantages: locking in a fixed-rate to smooth out revenue instability, selling a pure-yield instrument to discover market rates/yield curve, and expanding the partnership with vault owners by offering them fixed-rates so that they stay within Maker, et cetera.
Deco is helping Maker become a fixed-rate lending protocol like Yield or Notional protocols. This proposed iteration of Deco is specifically designed for Maker. Maker will never be at risk of not having funds available: stability fees are accruing debt for the system at the same rate as the token is accruing Dai. It is simply a token the Vault owner holds that provides and offsets the vault debt, provided they hold the appropriate quantity and proper class for the vault collateral type.

Please see previous response. MakerDAO is the counterparty the same as it is with vault owners right now, nothing new. Maker stability fee revenue would come from two buckets of debt- variable-rate stability fee vault debt, and fixed-rate stability fee vault debt. Adjusting the variable rate stability fee higher or lower on all debt does not pass any losses(or gains) from the fixed-rate revenue bucket from past issuances to variable-rate revenue bucket.

Yes, there will have to be a premium, just like in the real world, and Deco would not limit Maker from collecting it. We see a stability fee and rate premium also suggested by PE, Growth, and Risk in the institutional vault proposal. Deco would be no different in that regard, except that it enables market driven pricing, if desired. For the first time MakerDAO will not have to set rates by itself. Maker may use sale mechanisms like auctions to discover market rates, while setting a limit order for the floor fixed rate that starts with a premium to ensure an appropriate exchange of value.

Rate volatility protection, in exchange for a fixed payment, is the promise of a CLAIM-FEE token.

100,000 DAI = the current vault debt. 500 DAI = new debt they take on and use to purchase 100,500 CLAIM-FEE tokens. 100,500 CLAIM-FEE tokens will be in the vault owners’ ethereum wallet. Any variable stability fee applied on the vault which now has 100,500 DAI in debt is offset by the yield from 100,500 CLAIM-FEE tokens. Both vault debt in dai and CLAIM-FEE yield in dai compound at the same rate. When the variable rate is high and the additional debt on the vault starts to affect the collateralization ratio, vault owner is allowed to collect yield from Deco to payback debt and set the notional amounts of both back to 100,500 Dai, from where they start compounding at the same rate again. You raise a good point and we’ll verify that this works as intended for vault owners with more realistic numbers in a blog post shortly.

No, it is not an option. There is only one action available after purchase until maturity: “collect yield”.

No worries, we will have a presentation shortly!

Yield Rate is a typo in the title, it was supposed to be “Pure Yield” and we’ll fix that. We do not use the word yield rate anywhere else in the whitepaper.

They were defined in the glossary within the whitepaper and we are happy to expand the definitions. We have to use a new word “pure-yield” because it best describes CLAIM-FEE tokens which do not have a comparable term outside of DeFi.

Would you be able to point out an example? We understand the difference and will take a pass again on the whitepaper to make sure any errors are corrected.

It would be helpful if you let us know which parts, and we’d love to write a blog post and give those topics additional clarity. This is a challenging topic and we attempted to write the paper for multiple audiences, including financial and crypto amateurs, of course that presents its own challenge.

4 Likes