Fixed Rate Vaults Proposal With Deco Protocol

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.


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/ 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.


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.


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.


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?


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.


Would it be possible to consider a lesser maturity—perhaps 4-weeks? My guess is that shorter maturities can provide an upside for both Maker & the borrower—depending on the movement of the SF. Also—How Gas intensive would it be to repurchase CLAIM-FEE token? Or perhaps a 3-month maximum would work as well. Interested in hearing your thoughts.

Very different game theory here versus Opyn who’s looking to roll out “Everlasting Options” to avoid the end-user going thru “rolling position” strategy.

1 Like

One feature being discussed as part of Institutional Vaults - Economics & Terms is a limit on how fast the stability fee can change for fixed rate beneficiaries. Deco doesn’t currently offer this (correct?), but would it be feasible to add? For example, suppose I purchase CLAIM_FEE tokens at an implied fixed rate of 2% for six months. I hold these tokens to expiration. Can I renew them for another six months at an implied fixed rate of 3% or less, regardless of the current stability fee?


Deco contains features which can be implemented to achieve a comparable outcome. We anticipated that vault owners may not be willing to pay the entire stability fee up-front for longer durations, e.g., a year or more. In these situations, we added a function called Slice to Deco which can be programmed to achieve the result you mention with the use of a small custom sale contract.

The following is an example of an implementation which achieves the result you suggest:
For example, Slice can be used to convert a 100M CLAIM-FEE Q1_22-Q1_24 balance (issued for two years) into 8 new balances, each representing contiguous quarters. We now have eight 100MM CLAIM-FEE tokens and each 100MM representing one of 8 quarters from the original two-year term: 100M CLAIM-FEE Q1_22-Q2_22, 100M CLAIM-FEE Q2_22-Q3_22, …, 100M CLAIM-FEE Q4_23-Q1_24. The time is sliced and the 100M notional amount stays the same on all these slices.

The sale contract can be designed to define the rate at which the vault owner will purchase each 100M CLAIM-FEE balance that represents one quarter and the date at which they are eligible to purchase each CLAIM-FEE balance, (one week before the start of each quarter perhaps?), to achieve the use case you described. The sale price set for each one of these CLAIM-FEE token balances sets the fixed-rate stability fee that vault owners would receive.

Using Deco, a Vault owner does not have to trust MakerDAO governance to receive the future CLAIM-FEE tokens at an agreed upon rate. Instead, the vault owner can receive the stability fee offset in a trustless manner at pre-defined intervals.

There may even be a superior implementation using Deco, but the main point I’d like to make is that tokenization of the stability fee and some neat native functions we designed, like Slice, allow Deco to be flexible. Deco can handle new use cases like this with ease and without introducing new complications or stretching the current protocol. In the example given above, CLAIM-FEE slices are not treated any differently than the initial tokens. They rely on the same central yield snapshot mechanism (called Fraction Values in Deco). Slicing the terms and using this feature will not introduce additional complications to Maker governance or to Deco in terms of managing the settlement. The safety mechanism Close can settle all future maturities in one go and take them out of circulation the moment emergency shutdown is triggered. The Close feature makes long-range issuances like the ones described above safe.

1 Like

I need to verify but are stability fees on collateral types being set once per month already making them stable over that duration? Deco can target any issuance frequency as long as it is beneficial for both MakerDAO and vault owners.
A minimum of two transactions would be required for the entire fixed-rate cycle- a token purchase transaction on a DEX, and a collect transaction to collect Dai yield and payback vault debt. I can run some simulations and give you an accurate gas estimate but collect is fairly simple and cost to execute it would be similar to a token trade.

I will read the post and revert back.

1 Like

I believe the rates working group meets
every week, and the Parameter Proposals are first presented on the Maker Governance forum and are then entered into the weekly governance cycle.

Thanks again for providing feedback Vamsi!

1 Like

My feedback

  • for Institutional Vaults a fixed rate is fine as long as it in general is above the floating SF and the potential users have expressed an explicit interest in this product.

  • for general Vaults I am sceptic, it does not matter if it is Deco or any other provider. The argumentation is as follows.

Interest rates in Maker, Aave etc don’t matter unless they are 10-15+%. Why? because crypto is so volatile that the cost of capital (interest rates) is insignificant compared to the potential capital gain (if the price of lets say ETH goes up).

This is why lowering the Stability Fee does not really work that well, but lowering the Liquidation Ratio is the way to go if you want to attract more business, it simply provides more dai.

The same applies to Fixed Rate Vaults. It is a maybe useful feature for a small minority of Vault holders. Example: at the start of Defi Summer 2020 you start a ETH-A Vault. You mint Dai and buy more ETH at DAI240. 31 December 2020 you close the Vault at an ETH price of DAI750. At the same time Maker stability fee for ETH-A has gone from 3-4% to about 5-6%.
You get my point?
It does not matter at all if the SF is variable or fixed since ETH has gone up 3x in the same period. Fixed or floating - it is totally irrelevant.

You have a use case where fixed rates makes sense? My motivation here is not that I am trying to prevent the protocol being loaded up with features nobody really wants and prevent a lot of work for nothing.


I respect your opinion, but I want to push back on this. It’s hard to assess the potential interest in a feature that isn’t available yet.

If what you say is true then why is the rates working group keeping stability fees so low? We’re in a bull market and protocol income is slashed to starvation levels because we’re trying to use stability fees to discourage USDC? Today the MKR/ETH ratio is less than 1. :cry:

Maybe, but fixed rates would distinguish Maker from the competition and seems likely to facilitate new business opportunities. For example, the institutional vaults product would be a lot simpler to put together if most of the pieces could be built out of standard floating-to-fixed swap components. Closely integrating the yield tokens with the Maker protocol (Deco) offers a particularly slick user experience that cannot be mimicked by add-ons like Yield or similar fixed rate protocols.

It seemed to me that a key point of Deco was that there was not much additional work for the protocol.


Yes, and more details to follow soon! The remaining work is the integration and then the maintenance of the protocol Deco has borne the cost of design and development and consequently de-risked these components to Maker’s benefit. This is not an R&D project, nor is it a proposal for Maker to fund the development of a product. Instead, we are asking Maker to fund the integration and support the operational core unit until such time as it becomes sufficiently profitable to cover its core budget and generate a profit for Maker. This protocol enhances Maker rather than adding any additional burden to the DAO or any of the existing CU.


ETH and BTC are big enough Maker users that they may attract liquid fixed rate markets. For smaller collateral types, would it be possible to aggregate all collateral together that are tied to the same floating rate? For example, if risk decides that some LP tokens (e.g., WBTC/ETH, UNI/ETH, and USDC/ETH are all at 2%) shall follow the same floating rate then can Deco merge these markets into a single fixed rate market?