MakerDAO Focus On, 26 Aug 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Focus On #03 | Focus On Deco

Description

Focus On is a MakerDAO original series, where we talk with Core Units about their progress and deep dive into the details.

This time @Vamsi (MakerDAO Forum) will join us to discuss:

- Integrating the Deco Protocol with Maker, which will enable the creation of Fixed Rate Vaults.
- All the specifics that you want to know about the deal
- Any other questions you might have!

A

Hi, everyone welcome to another session um from makoda. My name is juan, I'm the facilitator of the sustainable ecosystem scaling core unit, and today we will focus on the the decoy or deco protocol, which are bringing an interesting solution to change.

A

Well, variable fees for for fixed fees, so I don't want to to take anyone's thunder. I see that bumps is already sharing screen so yeah, as always. If you want to intervene or ask any questions, feel free um and yeah without further ado. If you want to introduce yourself for those that don't know the legends hey.

B

Everyone uh again excited to be here and basically be presenting this proposal good background. I've been in I've been like around maker, for I don't know a really long time. I've uh been part of the community. I've worked at the foundation as uh in the integrations team since, like 2018 until a couple months back and yeah, let's get started.

B

Just trying to set my screen up.

B

You aren't supposed to see that yet so, basically like yeah today, we uh I'm here to present deco and specifically the integration that we're proposing, like with uh the makeup with maker, to achieve like what what I'm calling it fix rate walls right like um like, as everybody knows, like maker, currently like the uh the walls that we do are like variable rate. So the stability changes when maker governance basically sets them and wall donors just continuously like pay that stability fees over time and uh what what so there have been like.

B

Multiple attempts act like creating fixed rate protocols, but basically what fixed rate protocol or fixed rate vault means that a vault owner locks into a fixed rate up front for a certain duration and then at the uh like, basically like they're, uh they're shielded or at lea, at least like that, so that becomes the rate that they end up paying uh for using like for borrowing like for that for that duration.

B

So this is. uh This proposal has a couple layers, so I I think, as we go through this presentation right, I I'd recommend like you, relate the concepts or the components back to a certain layer, so that uh so that you can like you can like. I guess, like make a little bit more sense, uh so we have the maker layer like let's call it the base asset or where that's where the dye stable coin lives. That's where the walls live.

B

That's where the variable stability uh fee stability fees are the the layer above that it's a yield token layer. It's basically a special yield token that we're proposing um we've kinda. I mean we've been thinking about fixed rates for a long time, and we had this like aha moment a couple months back actually and then we're like like what, if we just tokenized the stability free rate itself and created a yield token out of it, would that help and then we had like deco on our hands.

B

So we played with a few concepts and then we realized there's a neat integration that could happen and basically the outcome of that integration is like. We think maker becomes the effect straight lending protocol like it is a lending protocol. It's a variable rate landing protocol if we have to like call it that, but the outcome is basically like the outcome that we saw was like maker itself becoming a fixed straight lending protocol, and but by that I mean like in terms of like how the feature is right.

B

The feature is uh has to be like native or behave like almost as if it were a native feature. So that's the yield token layer we'll dive into that, like what we call these like free tokens or free yield tokens, and then finally, we have the deco layer and I'll explain like uh why you see like two different tokens there, but that's that's the third layer.

B

So definitely I don't know how many of you have seen this meme before I'll. Give you a moment but there'll be something like the movie inception, so we'll we'll dive down like these layers, like one by one and then understand the whole proposal.

B

But the big thing that I want you to like focus on is just the claim free token claim fee token, like that's labeled there that forms the basis of the entire user experience. So um we've heard some feedback that this is like. This looks like too complicated, or it's like it looks too complex. So that's why I wanted to like highlight this, uh especially because walt doerner's maker, to a certain extent um you like all they uh have to deal with, is these claim free ether, tokens those form the basis of the entire user experience.

B

Everything else is like supporting infrastructure. That's like mostly set up once, or at least like for each collateral type, and then it basically is used continuously.

B

So, let's dive into the user experience part to see like how how this might work so, like I said, like the claim fee token forms the basis of the user experience. So the first step is those being issued, so the issuance is always going to be like under the control of maker, so maker decides when how much and for what duration it wants to issue claim free tokens.

B

Sure there could be demand from like walt doerners right, but it it's going to be up to maker to issue them and satisfy that demand.

B

Yeah, so sorry, so, basically yeah so um claim free tokens are issued by maker and maker. Like will set the terms. So uh it's. This is basically a mouthful. If you read the entire thing, explain the components here. So the first thing is a balance. So a balance is basically a number. It's a fungible number. The reason it's fungible like one way to think about it is like you could have like, for example, created something that just works for like one world and exactly like what that vault has right.

B

Instead, we made this fungible, so it's up to the wall toner to decide uh the balance exactly uh should be, should track the amount of debt that a walt has that's. Your vault has like 100 000 in debt, the wall turner. All the wall turner has to do is purchase. 100 000 claim free tokens to offset.

B

If they don't want to offset the entire amount, they could purchase 50 000 if they want to offset it for, like a shorter duration and the tokens are trading like they could purchase a shorter duration.

B

uh It's completely flexible, like having a balance like adds that extra flexibility and like they've reduced the debt on their wallet like part way through they could sell off the excess and then just continue to hold a smaller number without losing the entire edge right. All sorts of things like that could be done so claim. Fee itself has a token type, so it's claim fee and what we mean by that is basically that these tokens are set up for each collateral type so claim fee. They are set up to track the stability fee of ether.

B

If we see wbtc, abc and vrw, who knows so, we set up a a claim free token type for each uh collateral type. If, like I mean it's up to ray it's right, it's all about rates. If uh maker is moving like rates for, like let's say wbtc, the rates are just going to be equal. Always, then maybe you could do like one, but overall, like yeah, claim, feedback and type is linked to basically a collateral type, and then we have the issuance and maturity dates.

B

So issuance and maturity simply track the duration for which this token earns that yield so claim. Is this something I mean we're, calling it a pure yield token.

B

What it means is that from issuance to maturity, it would earn the yield like from whatever rate it's tracking, and it would give that back to the holder and that's it after maturity, it. Basically it's like it's worthless again. uh The tokens basically are burnt and they disappear. So it's like um so yeah.

B

So that's why it's a pure yield token, and that's if this token tracks the stability fee, it's per it's a it can act as a perfect hedge for a wall donors right whose own, like data, is volatile exactly at that rate, uh the stability rate. So that's why it's like they uh they'd be interested in purchasing them to offset that variability.

B

So that's issuance, and uh I mean in the future you could think about on-demand issuance, but what we really are thinking about right now is basically standard terms like once. Every uh every month, like the issuance occurs like for a three month, duration and maker could add more liquidity to the exact same duration. It's not like just because claim fees are claimed.

B

Tokens are being issued today means uh the issuance, uh like date, changes to today and there's like fragmentation and liquidity, so maker picks the standard dates and then can add like as much liquidity as like maker wants to those dates based on demand like every day every week or every month, and once they expire like basically like new uh standard periods are introduced. So the claim tokens are actually issued by maker they're, not yet in circulation or in the market.

B

So since these are tokens, like literally like I mean sky, is the limit on how like maker, wants to sell them or make her? The maker protocol could sell them, but I mean everybody has been talking about emm's. We have like multiple couple different emm's, like specifically designed for fixed rate tokens. All of all of them are options, but one particular I'm just using this opportunity to highlight, like one particular option that I think could be like a compelling uh uh compelling way to sell these tokens.

B

It's basically like using some something like gnosis protocol, v2 and uh maker, like starting auctions of these tokens. So the cool thing about like starting an auction is basically uh so, let's say maker wants me so maker gets to define the rate, the minimum rate that it it wants to get.

B

So, let's say like like the current floating rate is one percent and then, like we had add a bunch of premium to that, because this is a this is makers providing a hedge to wall, donors and then maker, says: okay, like uh the risk team says, like two percent, is going to be like good. This is typically the rate that maker would like normally set right and wall turner's like when it's a deal for them. They just pay that and then that's it.

B

But the interesting thing with doing an auction here is that that's a limit order and then you start an auction for, like let's say I don't know six hours, uh 24 hours now walt owners, who probably would know like the most about the market. If there's anyone in this market that knows about like demand, supply uh leverage, they would know, and if maker can induce a little bit of competition, they could like uh they could participate in like bidding and they could beat that up.

B

So in a way, it's like by using auctions by using the variety of sale mechanisms maker can like force the market to reveal private information, and there's no channel like for waltoners to reveal or a reason for walter knows uh to reveal that information uh yet, but maybe like by inducing a bidding war in an auction like by set making sure that you're not selling too much but you're not selling too little like over time.

B

You could figure out like a way and uh get the market to reveal some information about, like the rates, um just just a thought, I'm not sure if it will exactly play out that way, but there's a nature. uh There's a there's, a there's like a way to use like market mechanisms here as.

A

B

Like we all, we all have the like current options right, but this is like something in addition to that. These are erc20 tokens, so uh basically like yeah.

B

So so that's the auction and then like yeah, let's say a vault owner like purchases them. So this is the other big contribution from us is. We are not asking the vault owner to do anything with their existing world, so they're using d5 saver they're, using like any vault management, they're using a collateral type. Everything just stays, as is they don't have to uh do anything with their existing world.

B

They have the tokens and uh so that's a purchase. So that's one transaction, a minimum of like a second transaction which is basically like the collect to collect the yield that they want. So we probably like develop a ui, probably something as simple as this for version one. It would have a collect button.

B

It would display, like the claim tokens that they have, that are that a wall toner has the yield that it has earned and uh that yield would actually be like the same additional debt that their vault currently has, because uh it's a regular vault and a regular like stability fee is being applied to it and uh we could either like just hit color like develop, something that they collect the die and then it's up to do what they want to do with it or we could automate that to like collect it and then just pay it back a payback payback debt and bring it back to the fixed amount.

B

On their thing, I think, having like both numbers separately, I think it will work out because the compounding is the same. It's the exact same stability, fee uh um uh stability, fee rate that it would be tied to so I'm not sure. Yet we could. We are planning to run some numbers, but I think they would exactly compound at the same rate. So after maturity, uh they would exactly have enough to offset everything uh that was increased, the num, the additional debt that they have on their world.

B

um So basically, our three steps maker issues- the tokens uh like finds a way to sell them to wall towners, waltoners, purchase them and execute a collect transaction towards the end to offset the uh the the the the the yield on their world and uh that's.

A

Basically, a quick question before just just to test my understanding. If the let's say I purchased this claim uh token and the stability fee doesn't change, then the yield would be zero. Is that correct.

B

So the stability fee doesn't change would just mean that no, so the yield won't be zero like what whatever the stability fee is, whether it changes or not, it would still be applied to the regular vault and the token that they've purchased like would yield the same amount.

B

It just would so happen that the purchase price, or that the um wall turner paid to purchase the claim fee tokens and the yield that they received from it would exactly match, because the variable rate and the fixed rate that they uh got in the purchase process would basically match, but uh they would still like the regular rate would still apply on their world. Whatever the rate is and it it would be paid out of their likely mp. Tokens.

A

C

There's a question on the chat about the uh uh you know upon issuance, can vault owners purchase, claim tokens and then can claim tokens be liquid on secondary markets for anybody.

B

It's up to like yeah they're, designed to be erc20 tokens, so they can be liquid if maker wants. It doesn't see that as a problem like see, uh sita's like like not just like wall toners but like anybody else like uh using it if maker is comfortable maker, is getting like some information out of it maker. There are a list of benefits that maker gets from just selling them.

B

If that becomes a problem, we'll have to find a way to like uh restrict them to be used like along with vaults, but they can be like yeah. If restrictions are not placed, they can be traded.

C

Okay, but like uh initially only the vault owner can purchase them or it can be anybody.

B

Can be anyone if you're not doing like something like a proof of or having a world as part of that sale process like if you're, not asking like the purchase, the buyer, to prove that they have a vault and only then like letting them purchase?

B

We could. But the thing with makeup protocol is like in in the in in the territory of flash loans. Most of these like so, uh restrictions could be bypassed easily, so anybody could purchase these like clean free tokens.

B

Then yeah, so I guess like yeah. Basically like again, the point that I wanted to make here was like user experience is just centered around one token, and users need not like worry about the complexity of like the infrastructure that set up and if you're calling it complex. uh I think it's simple.

B

So we have that and then like now, we'll step step down into the other layers. So I'm assuming everybody on this call like is well aware of, like the maker layer right walls date, stability fees, so we'll skip the base layer and then we'll step into the yield token.

B

So a quick refresher on how like yield tokens work so like so you have like so a yield. Token is basically a regular erc20. We can think about them as a regular rc20 token right. You have a yield token balance.

B

You can transfer them around, but almost like all yield protocols or yield tokens come with, like some form of a deposit function and some form of a withdrawal function could be like compound with you, deposit, your diet to get c die and you withdraw c die back to die, could be unisoft where you supply liquidity into a pool. That's the deposit, you get lp shares and then you redeem. The lp shares back for, like the uh whatever your road. So more shield protocols come with like a deposit step deposit and withdraw functions.

B

So throughout the process, like usually the balance that a user gets stays constant right, it's not that their balance is changing, but they still earn more yield. The reason uh that works out is because every single yield token holder shares a constant like multiplier, so you have a static balance and you have like a multiplier that gets updated as yield accrues for the entire protocol. So we see here somebody has deposited 100 into chai.

B

They receive 95.323 chai like let's say the multiplier is 1.05, so it's still 100 die but 95.23 times 1.05, so they have like 95.23 chart. They just hold it for a year two years and let's say dsr uh was 20 at withdrawal time. Their 95.2 to 3 choice stays the same, but the multiplier would have increased. So that means they're now able to take out, like 120 die from the yield protocol. So that's how that's, basically, how like yield tokens in general work.

B

The multiplier is slightly different based on the protocol. Sometimes it's calculated as a share of reserves. The total reserves that a protocol owns, but it's like it's something that you can. You can think about it in the terms of a multiplier that increases constantly and.

C

There's a there's, a great question that chapman planet x. He asks what happens. If I forget about my claim fee tokens. Do they lose all value.

B

So if you forget your claim free ether tokens, basically, uh what happens is for claim fee ether the die that it the the die that claims needs to get is always like held by deco. So, let's say like between issuance and maturity, about, like 50 divers on that 50 die will stay locked in inside, like deco, for the user to claim like until even after emergency shut down, they would still have it.

B

They would be able to like take it out as die and.

B

We'll get into the decor protocol part and I'll. Show you like how that accounting works and decode super simple and how it's like doing that. But nothing really happens. The dye. That's earned just stays there, so this is like yeah just continuation of like what I was saying. Example yield tokens like everything right: everything from chai c dai, uni swap so one. So the the other example here, like you, took somebody deposits 100 die during the deposit step, you're divided by the common number, and then you get 100 c dive.

B

Five percent a year later, you multiply your c die by the current multiplier number times. 1.05 you get 105 die. If somebody is depositing at that time, the multiplier is already 1.05, so it would like 100 die deposit divided by 1.05. They would only get 95.23 c die. So that's how it works for the rest of the presentation.

B

I'm gonna assume a multiplier of one just to make like the numbers a bit more clear, but the numbers track- and you know, even even when you see like, if even like, basically the numbers track and we'll just assume, like the multiplier of one, to make, make things like slightly simple at issuance, so that is basically like yield tokens and generally like how they work so a fee token. We're calling it a token actually need not be a token but think about it as a pot contract.

B

It's uh nothing. Fancy is going on. It's like a port or a chai token right. Basically, and all it does, is uh the uh the rate function inside. Basically, the drip function tracks the stability fee of a collateral type so which means that a hundred die deposit into the fee to fee uh yield. Token, specifically, let's say the fee yield token, with the stability fee of like five percent right in our on average. After multiple changes for a year would be uh would become, like 105 die like at withdrawal time.

B

So it's basically like what I mean whatever. What I want to uh uh uh tell here is that free token is almost like chai or pot. It just tracks the stability fee. Obviously,.

B

We've we basically like limited um so that's free token and then finally we're at the deco layer like let's, let's dive into this, then I'll explain a little bit more so in a on the deco layer. So now we have the free token there's a 100 deposit that uh that basically, like maker puts in and then like generates the fee tokens.

B

We don't want those free tokens to just circulate and circulate like indefinitely right. We don't want them to ever like go into the hands of users so which is where deco comes in. So deco is the one that slaps a maturity date on them and after like adding a maturity date, it splits it into like two components: called zero and claim at issuance.

B

So for a 100 deposit like deco, receives let's say a 100 die. It creates two tokens. Zero like 100, goes into the free token and then, like deco, receives the free tokens, but overall, like deco is like uh receives 100 die. It creates two tokens like zero fee and claim fee attaches a maturity date.

B

Now these are the promises that it will make right. So nobody knows what the yield is going to be for a year. They have expectations of what the stability fees are uh going to be over a year, but nobody knows for sure it might as well be zero and, like the the actual rate of zero or the yield itself, is zero, which means that then what deco would do is basically it would take the original deposit and give it entirely to the zero holder.

B

So the claim free token holder gets nothing, there's no yield, they get nothing. So you can see that even in an extreme scenario where there is no yield, there's no solvency issue here, because deco holds on to the entire uh deposit up front, like all the obligations that it has in the future it holds on on it receives them at issuance like at the initial deposit.

B

So that's the no yield scenario. Obviously there's going to be some yield, everybody expects the the stability fee to be something so, which means the claim fee. uh If there is a certain um certain yield, like let's say, 20 die in yield. What deco would do at settlement is give the zero fee holder.

B

The 100 die back, so that's why it's a zero coupon bond, like deposit 100, die or like uh deco, can tell up front like how much a zero fee holder gets exactly so so they know for sure like exactly what they would get at maturity.

B

So that's the zero fee part all the excess yield. Basically, the the one. The part that's unknown like up front, goes to the claim fee holder, so deco handles that settlement. Basically and deco keeps track of these historical, like yield values so which me, which it uses at settlement time and uh passes on, like just the yield part to claim fee and the rest to the the original deposit, basically back to like the zero fee uh token.

B

So now we can see why, like uh walt owners like, might be interested in just the yield component right it exactly offsets the variable rate on their world, so they'd be willing to pay like a purchase price upfront to get their hands on this token and then use that like to offset like whatever the yield ends up being so that is.

B

uh That's basically uh like what's happening like we um we're proposing like a fee token, uh whose assurance is under the control of maker, locking it into deco to generate these two tokens and then like uh trying to sell clean free tokens to wall toners.

B

The question is where, where is this hundred die coming from like uh this, this required 100, deposit, actual deposit and that deposit needs to be held in becca for the entire duration of the like, from issuance to settlement, which could be like three months six months after that? Definitely is not coming from wall to earners, because the wall turners want to spend the their diet. Debt like on, like I, don't know, buying a car like paying off their uh their other debt, using it to buy more.

B

So somebody else has to supply that 100 die that that is like the problem that we've solved like we could have basically like one way in which we could have like taken. The suicide like we could have just assumed like there would be a buyer for those tokens and then, when there's a buyer it would uh uh it like. The wall.

B

Donors would take the opposite side and they would they would receive a receiver fixed rate uh uh hedge, like a a variable rate hedge, but instead of making that assumption, like we basically like looked at all like fixed rate protocols- and I mean, if you I haven't like done a deep, deep dive. But almost everybody is facing, like liquidity issues, they're just not able to convince somebody like a die or a stable coin or a yield.

B

Token holder, who's receiving like variable yield, they're, just not able to convince them to convert them into like zero coupon bonds and on a fixed savings rate, they're at least not able to do it at scale like at maker scale. We want like 100 like at, like I know: 100 million 200 million 300 million like an uh zero coupon bond like zero coupon like liquidity.

B

So, instead of trying to like find like a buyer- and I don't know- have an uncertain user experience, what we did was we find we found a way to basically like push push it back into maker as collateral to basically uh offset the uh the die that was used for issuance as like debt.

B

The reason we're able to do that is because it's like, as we've seen the dies accounted for upfront and like zero, would be able to give the uh the exact amount of die back uh after maturity to basically let pay back that debt. So this is a like if you're like looking at this picture, please look at the loop on the left-hand side. You're starting off with a flash loan of 10 million die you're, depositing it into the spot contract right.

B

That's your initial deposit and it's giving you 9 million feet there, because that's the yield. Token mechanics it's 9 million feet, but it tracks like 10 million in notional amount, so that doesn't change, which means like when deco issues like zero and claim it would issue like 10 million zero feet and 10 million claim fee.

B

So 10 million claim fee goes out into an auction, a 10 million zero fee, we're proposing an adapter and a single like zero volt. So it gets deposited as collateral to generate the 10 million die to pay back that flash loan, so that issuance is complete in one transaction, one step and uh after maturity deco. Basically, like pushes the die back into uh into the world the die that it receives right, zero converts to die exactly at the same number pays off the debt. uh The claim fee becomes worthless. Everything like gets removed.

B

If emergency shutdown gets triggered, we have a. We have something called close. It doesn't matter like what maturity surround circulation. The da is already in the deco protocol. Don't have to wait for like some. Some other lending uh like, for instance, like other lending protocols, might have to wait for other borrowers to pay back their loans right to get that liquidity to pay back this debt. This is all accounted for like within, uh within and under the control of maker itself. So it's just like.

B

If emergency shutdown gets triggered, the die is just used to account for the date and then the data is removed, or I.

C

Mean yeah, is it so is? Is it fair to say that the problem that you that you solve with this design uh is that you don't require um you don't require demand for for the zero portion and basically and that, yes, so other fixed rate protocols require uh die liquidity? So any of these third party providers are still going to require maker to provide the die to take the opposite side, but there's no easy way to generate it, and they also have additional protocol yeah.

B

This is all like closed loop inside maker, but the other way I mean maker could provide liquidity right to external protocols that are doing fixed straight lending, but the issues that come with that that is, like makers, to compete with other liquidity providers and, like there's uncertainty in terms of the rate that maker would receive it's not defined upfront or maybe it could be defined, but it's external risk.

B

This is all this is like just accounting, I would say, and the reason is it's like we could probably like find a way to like remove the zeros entirely, but currently like. This is like uh the design that we've come up with. One side effect it could have is like basically like an increase in die supply uh and uh yeah. It's overall, it's like yeah. So, basically, when claim fee get issued, everything else is accounted for upfront like using debt.

B

If there is demand in the market for zeros at some point right and if maker wants to incentivize that I don't know we're calling it like selective dsr, where those who want to lock up their die for a certain maturity like they probably they're telling maker hey, we want to be like die holders for a certain duration, like that's uh the maturity transformation. So if they're willing to do that, make a maker could sell, sell zeros for a discount.

B

I don't think that demand is there right now, so they just can't just stay log click until maturity, but if it ever like happens, they could be like prematurely unlocked from the adapter and the debt can be settled like from the sale proceeds off like the zero itself.

B

We just like, don't put that in the proposal, but if it's, if there's actual demand for zeros, like that, can't click, um we could like ease it, but for user experience like with this as a starting point, claim free issuance and claim fee sales like are not limited by like what happens on the zero liquidity side, we've disconnected those two, at least in time. Like may not happen at the same time and they've kind of made them look independent of each other, so.

B

Then uh we've had some questions right, they're, like oh you're, like everything, is like accounted from the stability fee from the surplus buffer. So it's like is maker like tying its hands by showing fixed rate data and would losses be offset. The fixed rates got issued at like two percent, but then maker increases rates to three percent is maker, going to pay more out of the surplus buffer uh to offset like losses. But what I want to say is like there are no losses, but it's also.

B

It also depends on the framing and uh like the reason I say there are. No losses is maker has to start treating these two as like two different buckets, fixed rate that bucket and a variable rate debt bucket, because the fixed rate debt bucket works on its own cadence, like monthly issuances, whatever surplus. uh The revenue that that's received from there is like received like up front and then that's like completely like that. That's accounted for in that way, variable rate variable rate is constant, like when the variable rate has changed.

B

The debt that falls under that bucket would just like um basically would pay that rate continuously. So two different buckets there is nothing uh that needs to be offset like revenues from variable rate bucket need are not used to offset any gains or losses like uh on the on the fixed rate debt bucket. This is basically like.

B

That's why I said like we: do you want maker to become the fixed rate lending protocol, and this is why like when it does become, that, like there would be like two buckets of debt and the fixed rate lending side and the variable rate landing side and both would have like their own calculations. In terms of like how revenues received accounted for like what? How much like demand there is like what to sell, what price to sell, etc and.

B

Yeah, I think I can you can like take some questions, but I mean I've made all these points.

B

um Market rate discovery, like the ability for market rate discovery, become a fixed rate protocol without external dependencies, new users, new revenue stream, novel product for growth, core unit like and then improve alternate retention and discourage vault migration, I know, could be as a feature. The other reason could be. Like I don't know, vault owners like could get a better rate.

B

Maybe they move out, but, like you lock them in upfront right, you could lock them in a front for a certain duration and there's always like the rates are short-term right now, but the wall there are like certain wall donors who are like long-term wall toners. They intend to stick around. We don't know they haven't expressed the duration that they want to stick around inside the protocol inside maker, but we know that there are like long-term wall donors. There are short-term wall, toners like why?

B

Don't we like offer a way for wall to long-term world donors to lock in using uh uh like claim free tokens, and that way the short term worldwide may be like there's an opportunity to like move rates more aggressively right. This is like some of the concepts that were discussed in the past, having like an instant access module that changes the rates like uh at a much faster cadence.

B

So maybe we will be able to aggressively change rates on the uh fixed rate on the variable rate bucket, if we know for sure that the fixed rate, the long term while turners won't be pissed off because uh they've they've like hedged it for for the duration that they intend to be around, and I mean the only other uh request is like consider. This proposal, like from multiple vantage points, there's not like one.

B

I don't think there's one vantage point where click makes absolute sense uh and there's the safety of the maker protocol user experience the risk to wall toners in terms of like having to use a new new collateral type versus just staying with the collateral type, with the vault management infrastructure that they're using not having to like move back and forth emergency shutdown. And then the flexibility of integrations that come with like having to deal with like a. I guess like something like a token right, yeah our ability to.

B

um Basically, integrate with others I'll just put this slide on, but basically yeah you can. This is the this is the big, complicated diagram we just put like in our proposal, but I hope, like this presentation, was able to explain like what's happening so step. One was the issuance part step. Two was the auction and like the user's wallet, basically purchasing this and then sending dye into the surplus buffer directly and step. Three is like the basically collecting yield and offsetting whatever, like variable rate, that was added to their voltage.

A

C

Yeah, I guess uh it's kind of our our ability to to issue these claims is kind of capped by, like our available debt within a particular hill um yeah.

B

Yeah, it would be a it can only be a I mean so in terms of like you could think about it. Two ways right, if you think it's only going to be like existing, if you're like it's only going to be like existing wall, toners that'll avail. This feature then sure it's like it's capped by a percentage off like current date.

B

But then, if you're thinking about this as like, the ability to change new growth or find new users would be able to, like I mean end of the day, that would be like total debt, uh expansion and fixed rate is always going to be a fraction of it, but it's it's still like. We could like uh go after, like new territories for growth.

C

So what would happen if a bunch of vault owners like closed like say we issue a million and and claim, and then uh everybody flees to a new protocol and suddenly we have less than a million uh they're.

B

Outstanding, so this the surplus buffer is accounted for, like the die in there is like basically there's no way for them to take that back. So, in a sense, like I mean it's like basically, like makers still make her getting like a a warning right, but it's like it's not losing the stability fees, maybe like we have like I mean if that scenario ever happens, there's still revenue that it has, like makers, collected up front that can that can use to correct that issue.

B

The second thing is it's: the wall toners are not like penalized by maker; they don't have to be penalized if they want to close it early they're exposed to the market rate. They have to sell that claim free token to somebody else in the market, and at that point they could make a gain or a loss, but it's it's like it's based on market conditions and uh that that's like yeah, there's, no there's no need to like incorporate like a a penalty like within the design, because it's just like decided with a market.

C

Awesome that makes sense. Thank you uh hi mom say I'm thinking from um a a user interaction perspective. Would it be possible to hide the uh the claim?

C

Fee is a token to simply hide it yeah, so the so the user don't see it because, uh with your design is possible to to secure a fixed rate, for let's say twenty percent or fifty percent or eighty percent for for the volts. But for simplicity's sake we could hide the entire token and then simply have a check box. You want fixed rate and then it costs so and so much up front yeah, because people might tear their hair out. If they're gonna, you know, claim tokens and get paid.

B

It's a maker already uses this thing called a cdp manager, contract right, so it's so there's the actual riot and then there's a cdp manager that adds additional functionality to wall. Toners uh creates like a cdp id and then attach functionality. So we'd have to do something like that similar. So we would create a cdp manager, like probably call it like fixed rate, vault manager.

B

That would handle like the interactions with the claim, tokens, offsetting yields and everything, and uh so, as a user like, if they use that to uh open a world behind the scenes that could basically uh like wrap the interactions. The only reason I've spoken about tokens is to just show the flexibility right. I mean when I say a token, like somebody who's listening to this call is like a a trader.

B

They can understand that somebody is an integrator, they could probably say they could figure out a way in which, like they could like integrate it into their experience, but it can be wrapped. That's that's why, like smart contracts are like so helpful right, you can always add restrictions.

C

All right, thank you, yeah, so I I kind of want to ask a little bit about the you know: auctioning of the fee tokens, so it seems to me that that's kind of the key step and that that's where the risk would really arise for maker, because really the the risk maker is taking on here, is the interest rate fluctuation risk. There's some you you, you collect the equivalent of some fixed rate up front um and then you're committing to pay that out um to you, know, fund the the fee tokens later on. So.

A

C

Do you ensure those auctions are are competitive? You know in the booth strapping phase I can imagine it might be necessary, for example, that maker now directly participates. You know other otherwise, if it's just the single person who's looking to hedge out their risk and they're, the only one who bids right they can just did some insanely low amount right. So you've got to think carefully about that. I think so.

B

Which is where I think the limit price comes in so in the auction like maker, could define a limit or limit limit limit price rate like a limit order and uh if, if it has to sell it, has to sell like above that or there would basically be no sale and when there's no sale, the assurance can be like basically like just uh reverted back and then the tokens can be removed from circulation. So that that's one um sorry I missed like there's there's another like uh point. You made right in this thing.

C

Yeah, I I mean, I think, being able to set a minimum price in the auctions. I think takes takes care of most of it, um because that can you know maker can decide like what's the yeah? What's the cheapest fixed rate uh that.

B

C

Be willing to offer uh yeah.

A

C

A particular ilk and set that in the auction and then if the market gives better that's great and if not, hopefully we set that well.

B

Yeah and until now like, basically, we only had the opportunity to set it and then so. The market discovery part is additional, but I mean worst case if it's like. Basically, if it's, I don't know somebody if it's a wall tone or it could be like a big wall toner, this can be uh so how the claim fee token, if it still has a token finds its hands into the right wall to owners, is, is basically up to our creativity, like one example is like uh the growth core unit is doing business development.

B

There's an upfront cost to like onboarding somebody as a world user right. They have to understand, like everything, about makers set up the world set of the infrastructure, making sure that it's like uh it'll never get liquidated all that. What if like, we get uh uh growth core unit had a bunch of these tokens right and they offer, like. I don't know, a six month, promo code to use a world, so they just give it for free.

B

They claim free tokens and then that entices, like somebody to open a world like on the main like or on a main collateral type, and they just get like free stability fees for six months and then after that, they're just a user right, they're now a sticky user. So it's like it opens up like uh I think it I can they can. They can be like a wide variety of creative solutions into how the the actual like furious tokens can find their way to like wall donors.

B

So how this will interact with our peg scale? I am. I wish I had like uh more answers.

B

I've I've mostly been thinking about this as like, uh um adding like a completely new new uh lending category to maker, like fixed rate lending, and uh it's like I mean. I think these are problems, basically, that we have to solve it's basically, I mean this is about like growth right. We don't do it.

B

Somebody else would do it rather like we do it and we figure out like the problems, but the good thing is like none of this has to be like scale, it's all under the control off maker to the largest extent possible and could start off with experiments and then slowly uh ramp it up based on like what works. What doesn't work.

B

That's also true should be new supplies are good for pig. That's yeah, that's yeah.

C

uh Vomsi, I'm thinking the is it the 100 necessary to integrate this with the maker protocol? uh Is it not possible to do a a more of a stand-alone development of this.

B

We could I um so two parts to that answer like one the the issues that we think that come with a standalone development is stability. Fees are set by muker, so are there folks who'd want to bet on it or what kind of incentives would it create for governance? To like, let's say, governance is firmly in control of the rate folks like make bets on that rates, but then governance could basically, like I don't know, take one side of the bet and then set the rate in a way where it pays off for them.

B

So it creates all these like incentives where uh I don't think a market could form like a robust market could form at scale that uh um yeah. That's not like worried about like maker governance in the first place like specific to like maker stability fees, and the second thing is like liquidity of zeros.

B

If die, holders are willing to hold like uh zero coupon die if there's demand for that, we could like push out like some of the complexity out from maker. So that's why it's built like it's built with that collateral type, but the moment there's demand for that.

B

It can be pushed out, make or need not take like the risk of it like um there's no risk but need not keep zeros on maker books for a long time so um yeah it can be done, but it's just that it's it's like yeah, who wants to bet on stability. That's said by landmaker governance.

C

Yeah all right, but that would basically be like, uh like the real world, where people bet on uh stability, piece.

B

Yeah, the other thing is, it could still be done. Like that's a that's a second, that's a that's that that could still be done on its own. This was uh basically this is like here maker and walt donors already have an existing relationship.

B

It's just like leveling up that relationship to this, like fixed rate uh to fix trades maker, is still like, as one of the counterparties gets like a list of whole list of benefits collecting like stability fees, upfront retaining users, so there's benefits to maker for entering into this relationship. This benefit to world tournaments. So when we see like a synergistic relationship like that, why not fill that gap?

B

If there's a need for a external market that could still be done like there's no reason for this to be like the only thing, so the deco instance is customized and deployed. We could deploy like five instances we could deploy like one for dsr, for example, if there's demand for that, we could deploy. I don't know like it's too early to comment, but there are like, like it's all about maturity, right maturity, uh maturity dates, pop up like in many scenarios.

B

There goes basically a protocol that can slap a maturity date on in wherever, like it's needed and then handle like issuance and settlement after maturity. So there's no reason for it to be like one single lick instance.

C

All right, thank you.

B

Yeah, please look at the proposal like we have. I can just have if I have a minute. A second can basically.

B

So we have like some technical talks. I know I've received some comments. Saying like this is like yeah. Why? Why are these dogs like uh like these are like written, not only perspective off like maker of this integration? It's just written from the perspective where, like hey, if you have a problem about like you're dealing with yield tokens, if you're dealing with maturities deco could be customized to solve your needs. So that's the docs. But then we have a maker fixed wall section.

B

Here we describe like how we intend to modify like some functions within deco to achieve like the goals that we described, how like side issuance and settlement, how we modify that emergency shutdown. So we have, like some dogs, have a really long white paper, but you don't have to recreate everything just interested in smart contracts. You pick that section because maybe like do a quick browse and if you ever want to reach us out publicly, you can comment on the post or send us an email at click, intro, deco.money and we'll be happy to answer.

B

Like any questions that you have.

C

Actually, one really quick question before we end here um for this integration: how much would be controlled by maker governance versus deco governance, or is there some sharing of power there.

B

No there's like for this, like yeah everything that we saw. There's no deco governance. I I think, like fur maker, or at least at maker scale right, don't want to introduce any new risks. So that's why, like deco, is designed as instances so when we deploy that instance, there are a couple like only only governance functions. It's under like a pause proxy, like basically completely under the control of maker. What we would do is like our hope is like.

B

Basically, our goal is to we'll do that proposal like maybe like in a bit but we're trying to propose a core unit, and we basically help like write portion of the spells that need to be executed by governance, but uh mostly it's all. It's all. Under the control of maker governance, by issuance like settlement settlement actually like make a governance need not step in for settlement settlement is automatic once the maturity data set. So it's only really assurance that governance needs to control and everything in deco related to issuance is under maker.

C

A

Nice are there any last questions we're at the top of the hour, so.

A

All right so yeah, thank you vampire for coming and making this a bit clearer. I think we're all quite interested by the by the technology behind it um and uh yeah. I think it was quite clarifying um I apologize again for for the technical challenges that we faced and for bloomberging your your call.

A

Hopefully it didn't damage this too much and yeah right now. We have another uh call it's up on the on the forum for real-world assets. So if you, if anyone wants to keep joining us there, you can- and if I see anything else, you would like to say before we close this call.

B

Oh good thanks. Everyone for joining.

A

Right thanks, everyone for coming.