MakerDAO Core Unit Pod Sessions, 13 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Core Unit Launch Pod Sessions | Session #19: Deco Fixed Rate

Description

For the 19th episode of CULPS, Vamsi Alluri (@Vamsi) will be presenting the Deco Fixed Rate Core Unit, whose purpose is to bring fixed rate vaults to Maker using the Deco fixed rate protocol:

MIP39c2-SP23: Adding the Deco Fixed Rate Core Unit: https://forum.makerdao.com/t/mip39c2-sp23-adding-the-deco-fixed-rate-core-unit/10224
MIP40c2-SP35: Deco Fixed Rate Core Unit Budget: https://forum.makerdao.com/t/mip40c3-sp35-deco-fixed-rate-core-unit-budget/10225
MIP40c3-SP36: Deco Fixed Rate Core Unit MKR Budget: https://forum.makerdao.com/t/mip40c3-sp36-deco-fixed-rate-core-unit-mkr-budget/10226
MIP41c4-SP24: Facilitator Onboarding, Deco Fixed Rate Core Unit: https://forum.makerdao.com/t/mip41c4-sp24-facilitator-onboarding-deco-fixed-rate-core-unit/10227

A

Hi everyone uh welcome to another co-unit launchpad session. My name is juan, I'm the facilitator of uh scs, one of the core units at maker and I'm here with a bunch of people interested in making a way or another.

A

Today we have a session number 19, so we're here with the the deco fixed rate solution and they are going to be explaining a bit more uh what decoys and their proposal in the forum so vamps. If you want to take it away.

B

Thanks mom, hey everyone thanks for joining, uh so today it's gonna uh basically, so we have like I mean I.

B

I obviously encourage everyone to go check the four mips that we pasted they're a bit long, but I think uh they should give you like uh uh the entire context around like deco, where we are coming from what uh what is it that we hope to achieve like uh like, with make both like from the technical solution perspective like our integration proposal, as well as like uh the core unit like which we, uh which we would like to set up and then drive this uh integration proposal like for for growth, so quick overview about me, I'm sure, like I've, met every every one of you at some point.

B

uh My experience at maker, uh like I was a member of the integrations engineering team as a senior engineer for about three years from 18 to 21 until the foundation dissolved and.

B

Yeah and uh I've done some interesting work at maker. I'd like to say, like things like, I don't know, started the developer guides repo wrote some wrote various like control level developer guides to explain all the complex jargon on the maker side and then simplifying it and then like helping developers, understand makeup better and expand their expand. The ideas on like what they can achieve, like with with the makeup protocol.

B

One. Some one interesting uh work item that that I'm proud of is the emergency shutdown impact analysis. It's a guide that I'd encourage like anyone uh interested in like integrating with maker right, mostly at the smart contract level, but also like any integration to quick quickly. Take a look to see um to basically make sure how like like to not only understand emergency shut down, but also like make sure how, like your users, can be kept safe if, when or if, like emergency shutdown ever gets like triggered in the like.

B

In the makeup protocol, like it analyzes the impact and then it filters it down into a set of recommendations on how like an integration, can deal with the emergency shutdown in a safe manner.

B

um One thing like uh that actually yeah, another thing that I'm I'm proud of is like I've been around maker like since pretty much the uh the first white paper was published and I've seen the evolution of the protocol like the smart contracts, the white paper uh pretty much like since the beginning, like uh I guess right from I don't know if everybody knows but roon actually wrote smart contracts in 2015. You didn't just like put out a dive proposal uh so like starting from that I'd.

B

Consider that a prototype too, that I guess protocy multicollateral dye and then all the minor liquids and turns in between as well. So that's like me at maker um experience outside maker, I worked in a similar role at sap, focused on like an enterprise analytics product for about three years, and I also have a masters in cs.

B

So uh so the topic of the date deco. This is our like, uh I guess I'd say. A big pitch like deco is a native solution like uh that we are proposing for maker, and so that's why it's like an integration proposal as well as a core unit. That's coming on board to manage to manage it on behalf of maker.

B

So the big idea here is that compared to everything else maker, uh sorry deco is the one. That's like tokenizing the stability fee into it. It's creating a token and uh we'd say the big. The very big advantage for that is market rate discovery, so governance maker governance has always been in a position where, like maker, governance had to set a rate, and then the wall donors like choose to react to it or not.

B

I think this gives like maker an opportunity to flip the script and ask waltoners to reveal the private information that they have about, like the rate outlook about what they think is uh other rates going to be over the next, like not three months six months by forcing them to purchase the rates like by possibly competing with each other in, like uh various formats like could be, auctions could be like other cl mechanisms, but overall, like I, I think, there's an opportunity to flip the script for the first time and uh the other thing is it's a native solution so, like our goal, is to turn convert like maker into a full-fledged like fixed rate protocol and without any limitations like any collateral type, any term any any any any user type any integration.

B

So, overall, like uh our goal, is to like make maker the fixed rate protocol and with yeah.

C

I was going to ask well so how how are fixed rates set right now, for example, institutional vaults set a fixed rate, um you know, did how did they do that? You know I was under the impression they just took the current stability and negotiated down from there. So so are you saying this would actually provide more information in in these decision-making environments.

B

I have uh so in terms of set okay in terms of setting rate.

B

Let's look at like all four solutions, right, so um institutional walls. So in institutional walls like it's, it's an individual like negotiation, either with like one or group. It's like iv as a as a solution like supports multiple walls, but then it boils down to like a social agreement first like about the origination fee and then second, like the ongoing rate that maker would hold constant maker governance would hold constant for, like certain periods of time, uh either trustlessly or like. uh But overall it involves like a bit of a negotiation.

B

uh Yield has a little bit of like a market market market characteristics to it, because maker gets to set the discount at rich advice, like uh uh yields like a fight eye. So there's a little bit of like a market uh characteristic to it in terms of like make a guess to like adjust this from a high starting point and then see like where it clears where liquidity clears pairwise maker gets has to go in and fund like individual, fixed rate agreements again like there could be like multiple offers and maker choosers.

B

Like what to accept, and in deco it's like the ability to, I guess like sell a token so you can make like starts off an auction at a limit price and then everybody else competes to basically purchase what they think is like uh good enough for them.

B

Yes, yeah, like I said, like both tlm and like uh uh deco, have like market characteristics.

D

But but hold on I'm I'm confused because isn't tlm like through the clm. The rates are set via the purchase price of of fidei series by maker governance, whereas with deco the claim fee token uh price is discovered on the free market. So it isn't the free market setting the rates not maker, actually.

B

Yeah I mean yes.

E

B

E

Like the reason.

B

I said, like I mean tlm still even like, could be repurposed to achieve like a little bit of like market.

B

Basically, like even in tlm like, although it's not like as flexible as deco, I I still would say uh like maker, for example, could start off like could emulate an auction. I would say, and could start off liquid set the yield like really high at 10 percent and then slowly change it to see like at what point like liquidity clears right. So.

D

There's like a like.

B

D

Can I ask a clarifying question really quick vmc yeah.

B

D

So for deco, like the claim fee token, the way that maker would be able to set the rate is by putting some sort of like uh floor limit order on them either through this.

C

D

Mechanism, okay, got it dex like.

B

It like by by creating tokens like you, suddenly expand right. You can like do like social negotiations like one-on-one uh and like growth, core unit, cancel them or like you. Can I don't know auctions or you know, put put them on limit orders. We could also get like super fancy and do something more on demand. It's just a matter of like structuring uh how how how these would get go from like makers, pockets into the pockets of like wall toners. So.

B

So yeah, basically it's like the pictures like new product, new revenue stream, new users, because fixed rates I mean I I don't know how else to make a case for fixed rates, because the real world, like most users, are comfortable with fixed rates.

B

It's just like I mean variable rates, and fixed rates are just like two ways in which uh borrowing happens at like scale, so I mean, if you're, doing like a variable rate like naturally, I think there would be demand for fixed trades too, we'll skip these and then, let's just focus quickly, just a little bit on like claim free tokens and what they are. This is the I, I guess I'd say like the final output of the integration.

B

The way this would work is maker generates these tokens right, like by maker, I mean maker governance. Clicks like issuance, creates these tokens finds a way to like sell them uh at whatever some some mechanism. Let's say an auction wall turners on the market, like will have the opportunity to buy these tokens right and uh these tokens each like these tokens, like the token type, would be basically like uh based on the collateral types, so there's a claim free token for eta claim free token for bitcoin, etc.

B

One mental model that you could use to understand like these tokens is like think about it as like, dsr and chai. Essentially, these free tokens are like uh just like how charles pointed towards dsr a free token is pointed towards, like this replica of a collateral type. They just like our yield. Tokens are tracker rate.

B

uh What's, in a free token, so there's a couple characteristics. You have a balance right. The balance like allows, like I don't know, I mean think about it. As a like. Let's say you enter into an agreement right, it's hard to like negotiate like you, negotiate the terms up front and usually just stays constant until the end, but here by working with a balance, it's up to the wall to owner like when they increase their debt, they can buy a few more claim.

B

Free tokens right to achieve the perfect hedge if they reduce their wallet, they could like sell some on the market, and then they get some of the fees that they paid up front. So in a sense it makes it very flexible and then you have like the actual claim, free token type and then finally issuance and maturity. So those three things are the characteristics.

B

uh The reason maturity is important is basically uh is because, if you've noticed like throughout this entire discussion, we've never mentioned, like I don't know uh anything about a world, so voice stay, independent and after maturity, the war just remains a variable rate. Vault, it's not migrated outside maker. It's not changed inside maker, it's not like it doesn't have to move between collateral types. So so, in that sense it gives it's uh it's possibly the least intrusive solution and.

C

Then so fancy I have a quick question around the yield token. uh I think you know the main concern uh that we've seen uh to date and actually the reason why the uh the vote is not proceeding is because uh people are concerned that these are yield tokens and that yield tokens. You know similar to dsr, you know represent some potential regulatory risk. So is there a way where this could be structured so that these concerns are abated and actually irrelevant to the product.

B

Yeah, like the reason we mentioned that we started off, we stopped the proposal at the most base level like we stopped it at the tokenization level, because we felt like that. Everybody understand the various possibilities.

B

And then, uh but there's no reason for maker to actually sell like maker, gets to decide what the product is right. If the product has to be fixed, just like how like wild sarah product, we could create a cdp manager that integrates this behind the scenes. So, in the end like when somebody wants to open a world, they would just open an entire fixed straight world. They wouldn't be exposed to the token they're, not really purchasing a token.

B

Like I mean they don't have to purchase the uh the uh the token. The token need not be the product at all like we can wrap it into uh something like the cdp manager, that's already being used and push it like completely behind the scenes.

C

So so, in terms of the growth strategy, um my understanding is that you've already spoken to uh to both growth uh and oasis. Do you want to talk a little bit about uh about your talk, your conversations with oasis and then maybe I'll talk a little bit about growth.

B

Yeah we we spoke to oasis it's. I are like big pictures like uh integrations.

B

I don't know, maybe like that's because of background, but uh it's like having having something that that can be built upon in a seamless like scalable way, I think, would uh expand the number of possibilities in the future, and uh so we spoke to.

B

We spoke to the oasis team and they they like, they seemed like uh they were like super uh uh super interested, pretty supportive and uh like they felt like something like this would help them basically integrate better and offer like, like, I said, offer the experience ultimately like if uh users are or would want fixed rate walls they may most likely will not be interested in the actual claim free token. So we need various venues to integrate it behind the scenes and they see uh the tokenization.

B

The tokenized like claim fee uh as a way to like achieve a more seamless, fixed rate integration for like oasis users,.

C

Awesome I mean so um one of the concerns uh right now, with institutional vaults, uh after speaking with nadia, is that we we currently have a floor, a floor for the die debt that that qualifies an institutional vault and it's it's 200 million, and so right now there actually isn't a means to have a scalable on-ramp, and so you know, I think, nadia actually suggested that you know she was open to potentially implementing uh deco to turn institutional vaults over to them, uh but also to use it as a way to on-ramp smaller users, so so that they can have uh scalable means.

C

uh Do you think that this could meet that requirement.

B

Yeah absolutely so, um like it's a it's a it's a product that scales across like user types, so there's no, uh it doesn't impose like uh don't, there's no reason to impose limitations on like uh on the on the size of the user.

B

So obviously different users like need different uh could probably have like different needs, but here like and the big reason deco is able to achieve, that is by decoupling the fixed rate part which is like just having to deal with the rate and the variability of the rate into a token and like leaving the vault experience like as is and not having to like make any changes to that. So the nature of the solution helps basically target like uh different uh different user types.

D

Yeah at the very beginning of that whole conversation, there was a question of whether the fee token is a yield token and if there's regulatory risk I kind of like missed your answer. There.

B

D

B

Answer is: uh there's no reason for governance to actually sell the token itself like it could be wrapped into an entire fixed-rate. Vault experience like everybody's familiar with the cdp manager, contract right, so cdp manager is like a contract that, um like right now, like most wallet owners like open their cdp, open their wallets like through the cdp manager contract. It adds like a little bit more.

B

um I would say functionality over, like just the native I'd say um over like the white smart contract, so basically like a cdp manager is like think about it as a vault manager right, like most users today use vault manager to open their walls and manage it. It's a part of the maker protocol. Similarly, we could have a fixed rate, cdp manager or a fixed state, vault manager, so that way users are not interacting with the yield token.

B

So far like what I've seen is everybody thinking that the only way for deco to serve users is to sell these tokens on the market and selling the token on the market like constitutes like some sort of promise? uh At least that's the uh uh that that has been like the concern expressed. So what we are saying is that when you wrap it into like uh vault manager, smart contract, the claim token never goes into the hands of users, so it would be like cdp manager and fixed rate cdp manager.

B

So it's exactly like what maker offers today.

D

So but at the beginning you talked about the the claim fee tokens having rate discovery in a free market. Where does that happen? If you abstract it all away in the cdp manager and like you're, saying.

B

So that that's the plug-and-play part right, so basically, it's like.

B

So I mean regulations and what is right or what is wrong. It's like it's a complex topic. Ultimately, it's like these. These tokens right. These are essentially like. Let's say, maker, has a pool of claim free tokens maker sets. All all maker has to do is like set some parameters on like what it on click on on the sale process. The concern has been that there could be users. Users could purchase these tokens and not have a wall to open, so essentially they're speculators right.

B

But if these tokens are held by somebody who also has a vault, then it's basically uh it's it's almost like it's. It's the fixed rate voltage they're, not speculating on the uh on the actual rate and they're not exposed to the gains or losses.

B

So all they're doing is they're achieving like a fixed rate on I'd, say a stability fee. So in that sense it's like it's, not the the cdp manager contract is not putting limitations on how the token can be hold. It's just that this thing is never tokenized right, but you could you could sell it, but then you could.

B

Basically, I mean we have this proxy right ds proxy, like allows you uh users to batch a group of transactions, so there would never be a state where somebody purchases the claim free token and, like just holds it independently, like when they purchase it. It automatically gets attached to a wall and there's no way to like separate it back again. They would have to like hold that debt until the end of the maturity date and then, like uh the token, just essentially expires, and uh they would be left with a regular work.

B

So in that sense it's it's all about placing restrictions uh we have to like just think through everything right think through, like what restrictions like maker would want to place to uh to make sure. Like I don't know,.

C

Yeah, I think that there's um there's a couple of other uh benefits right to the tokenized design, and I think that the main thing is that uh it scales right. So, if we're looking at at the next era of maker and we're looking at at a need to grow rapidly, to bring more ethan to bring in more collateral types, uh the tokenized design allows allows it to scale and allows maker governance to manage it effectively.

C

B

Like what one way to think about it is like I mean uh smart contract structure agreements right like it's easy to think about. Like okay start a smart contract structuring, like I don't know, a certain agreement could be, borrowing could be lending. We've seen this play out before, where we've had like iterations of like landing.

B

Borrowing like I guess, like dharma, where it was more peer-to-peer, even peer-to-peer away like what's the difference between maker and like uh earlier version of dharma, like both facilitated loans, both facilitated, like I, don't know, borrowing like law collateral, you take a loan, it's just that with maker we have tokenized the loan process. Essentially, you can think about die as like the tokenized output of a loan right.

B

So so, in that sense, like maker was more scalable because, like uh the stock, the borrowing process was the end result of the borrowing process was die, which is tokenized. This can be like sold in various markets like purchase, bought like it just opens up a whole realm of possibilities, dharma and the peer-to-peer environment. There was one to one like a peer-to-peer thing.

B

The agreement existed, but it was never tokenized, so um I I guess one way to think about it. Is that, like what tokenization could uh the possibilities tokenization could unlock are like, like are going to like basically help in scale, so most fixed rate solutions basically have stopped at these, like, I guess, agreement style, smart contracts, there's no tokenization element. There. Deco has the tokenization element and we'd say like that that that would help like expand possibilities.

C

But I did want to note. um I think one thing that that was often overlooked in this proposal was: um is your current collaboration with uh with pe in uh in the sandbox project, and I think that one one thing that most uh most voters aren't aware of is that by funding uh deco in this proposal, uh deco is actually going to be the first uh external integration.

C

That's that's written into the core maker, smart contracts, and so what part part of what is going to come out of this is the first processing procedures in collaboration with pe and ses, to enable parallel smart contract development, which um I think there are probably some other people like calls that can speak to this. But this is, you know my understanding, a pretty significant uh blocker and also be a significant feature that we added. Can you talk a little bit, maybe about uh about how what you've looked at today?

C

I don't know, I think I see kurt here. I don't know if he has anything to say.

F

I mean, I don't think I have a ton to add to what's already been said, um but you know I'll just echo the sentiment that you know. I think deco is a great. You know test bed for getting external integrations that are fairly deep and touch fairly core parts of the protocol. You know done by an external party, um you know from an economic perspective right, it's it's one of the.

F

I haven't seen all the other fixed rate proposals in detail, but you know it's a really strong proposal because it leverages maker's ability, as the unique issuer of die to just really provide deep liquidity to the market, and it's just you know, I mean I'll, give full disclosure here, I'm actually like an advisor to a different, fixed rate protocol um called sense right. So I even have a conflict of interest, but like the best proposal for fixed rates in maker, I've seen is deco.

F

So, like I'm, I'm telling you to use the you know go with the thing that I'm not an advisor for, because I think it's you know better for maker here and yeah. You know like vomc. Is you know a maker og? He knows the protocol super well, so I can't think of someone. I'd rather be working with um to do something. That's gonna, it's probably gonna need you know, there's probably gonna be at least one contract that needs permissions on the vat here from the technical side.

F

So that's that's a that's like the highest um risk. You can get and you know you know I wouldn't want you know some unknown person just like developing something like that, but you know so I think it's perfect that we've got someone who knows the protocol super. Well, um I I think it's like something the market will really like and yeah. I we certainly don't want protocol engineering to be a forever bottleneck on, like smart contract development. So you know this. This seems like the perfect.

F

You know first step to you know getting a more scalable, basically like engineering um organization uh going so that there I that's my sound bite.

B

If folks want to quickly explore like uh pros cons, not pros cons but basically like I, I have like a couple slides. I can quickly go with them, but yeah.

G

So I would like to um um actually so um that's ruined here. I don't know if it just shows that but um and so full disclosure following kurt's uh example, I'm an investor in element which is tiny sign investor, basically pointless compared to my care holdings but um um yeah. So that's sort of my folded, skills, closure friend and then I still think I mean I'm a huge fan of this approach.

G

uh Just obviously like the the entire kind of uh you know the the intention of like building something specifically for maker and then bring into the community. That's like that is that's just awesome. In fact, it's like it's not only about the product itself. It's like a stamp of approval for the entire core unit framework and all this chaos and craziness we've gone through to try to set up all this stuff. But basically I really want to talk about like the pricing of this and because I think it's it's I mean I was just.

G

I was having a conversation with vmc and and.

G

E

And since then, I've been thinking a lot about.

G

The uh like there's, this kind of tension or like there's this I mean there's, there's both the the proposal as it's as it's. It's proposed right now with like these fixed payments, essentially as well as this kind of performance payment. But what I'm really also sort of struggling with is basically the concept of like competition between the different proposals and this concept of like an official maker, fixed rates designation in a sense and what that means in terms of yeah, basically favorizing one project over the other and anyway, I think so.

G

I think all of those dynamics um important to consider I just want. I just would like you to talk in that direction.

C

Yeah, that's that's a really good point. I mean, I guess you know I liked um you know a couple: what is it like? A month back you? You made a note on what you thought fixed rates. You know how how it should operate, and one comment that that I saw you make was that um yeah.

C

You were concerned that you know a native solution is the best potentially, but it's far away and pe doesn't have the time to do it um and that we should really be looking at using all the solutions on the table and what does each solution afford and where is it best applied right and these other third market? These third party- and uh you know other solutions- um provide the ability to expand the funnel, um but they also you know, require maker to provide the liquidity.

C

It's unclear how it would do that in some senses and uh and it's leaving money on the table, and so I think you know in instances where there are already users uh that want fixed rates. You know it makes sense for maker to have a you know. Have a core unit have a native feature. That's deploying those and that's actively working. You know in concert with growth um and and risk to to really manage that process, um but that we should be looking at deploying all opportunities.

C

You know to grow maker, because that is really. You know what we need right now to stay competitive, um and so you know what we the way we structure this deal. Cost wise is that um you know part of the challenge is that a bunch of work has been done and we wanted to you know, and we prioritize make.

C

We want to bring it to maker first, and so the way the deal was structured is that uh there is a fee share, but that the cost uh or the revenue share goes to first compensate the core unit.

C

So the the protocol doesn't see any incentive until it's a a net positive cost center uh for maker, and we thought that that would be the easiest way for maker to to proceed, um though we acknowledge that there are certain risks where you know, for example, risk could determine that they only want a 15, fixed rate volume for some reason or 20 and and the protocol would actually never see any incentive, it would simply be a core unit um and so yeah. I really think that uh your observations are.

C

You know, 100, correct um and that's why we proceeded in this way, um because maker really needs a native feature, uh but it also needs to leave other options in the table to you. You know to expand its funnel, um but you know at the same time. We don't want to forego this opportunity.

C

You know as as maker holders it's like uh you know. We need to get going on this now, so we can have the ability to to get the product market fit instead of deferring and then not having this feature in the next 12 to 18 months. You know and risk falling behind, so you know that's my obviously you know somewhat biased opinion, but.

G

But you just really could just quickly um uh like go through the exact costs over like the fixed cost of the code, and I remember we talked about something like the plan is like three years or something and then there's this fee share and just the details.

C

Yeah yeah, so it's it's a it's a five uh fte at about 140k a month um and the way it works is that uh when fees, when claim fees, uh tokens are sold, uh 15 would go to a deco wallet, um and that would then uh the draw down for the korean expenses would come from that. First and any any core unit.

C

Expenses that aren't covered maker would cover, and um you know in the event that that the money that was made by deco exceeded the core unit cost it would roll over to the next month and only once uh deco creates a full buffer for the entire core unit cost of three years. Would they be able to then take any additional incentive?

C

um You know, and and in order to make this more palatable for maker holders, we actually took a relatively small mkr comp relative to the standard pe and ces, and we took you know a fixed term, no repricing, no renewal, um and so that you know the the objective here is to create a business and a product line.

C

You know working with growth working with maker and at the end of three years um you know give maker the opportunity you know if they see it as being successful, want to grow it to then just acquire uh the residual revenue stream so that it basically creates a liquidity event at the end of three years, um and you know the way it's structured is that it's a fully deferred uh compensation, that's contingent on performance.

C

You know because there's two ways to really structure this deal. You know we worked with ses and we met with some of the other delegates. You know, there's there's the way where uh maker, simply you know, puts down some mkr or die and they they purchase the product feature and then they integrate it.

C

And then you know, potentially we operate the core unit, but the challenge there is that it's hard to anticipate the future value of the product and to value the past work, and so in order to make it uh easier compensation, you know incentive compensation would only be provided to the product if it becomes wildly successful- and uh you know in some of the projections the core unit breaks even at about uh 467 million tvl at 2.6 percent.

C

So if institutional vaults become a thing and they move over to deco and we're able to grow that product line a little bit, the core unit would be a net positive cost center. And you know at that point um you know the protocol would receive. You know approximately 200 to 400k of incentive um and so yeah. That's that's how the deal is structured um and you know we posted that.

C

uh You know we did the first proposal two months ago and then the most recent proposal about a month ago and the main feedback we got um you know was from a couple of the delegates, and you know one delegate just wanted thought it was a better deal to purchase it outright, um and you know those discussions you know uh should be had.

C

And I'm not not sure if that clarified ruined, but if they're, if you have.

G

Yeah so just yeah like I literally forgot the numbers right, but you said something like five full time. It sounds like it's about two million, a bit more than two million for the three years.

C

G

It's a bit under two million yeah, but that's kind of, but these basically the point is the way you're you're. What you're operating is that this is sort of the cost, so you're sort of offering this at cost. I said this is like the salaries and then yeah.

B

But none of that money like uh uh like shows up as profit anywhere it's like spend to hire the people again exclusively to work on the integration like on maker, so uh yeah.

B

So that's why it's like so leaving the core unit aside, like that's a constant either like for the for bringing the design feature like uh the development either like it's an upfront payment which we kind of felt like would be hard to calculate or uh cut hard to evaluate like without a track record versus like uh giving us the opportunity to all to like grow, show like how show that it's valuable and only be paid like after like three years. So it's like it's really up to late maker.

B

We we we honestly like had no, there hasn't been a precedence for something like this, so we just learned towards the direction where we wanted to like show a track record and then like get paid after. But if uh I mean that that's that's really, the only reason for the complexity of like the 15 percent and the buyout laws and everything it's like it's essentially, we can't it's like. We felt like we couldn't make a decision like jointly to assign a value to this like up front, but yeah.

E

Yeah, what's the and what's all right, what's.

G

The mki amount in total, it's it's 500.

E

For billion per year, yeah for five five yeah.

G

So uh let me just calculate that so.

C

I mean you know if you, if you relate the value to uh to the pe ad count uh or the recent ces, it's you know, for the technical vet count, it is still significantly under. I think, if you run the rates at ces roughly it comes out to be 800 between seven and eight.

B

And out of the five head count like there's one like smart contract engineer too. So that's like really.

G

Yeah and so okay, but so, and so basically the cash is kind of the salary. That's like doing the work. The mkr represents that's kind of bonus. Essentially, so that's sort of this value that you're providing to the maker and then sharing in that in a sense.

C

The mtr yeah as exclusively as sorry from the mkr's exclusively to to hire and retain the talent right, so it's no different than any other core unit.

G

And then, and then basically, because because the way I'm sort of going is that the point is that eventually, this turns into a self-sustainable thing if it's not like, there's two options: there's some of the communist option, where maker sort of buys it out and and runs it as this native thing that is sort of the official maker, fixed rates, official status, kind of and and that's where maker sort of goes for economies of scale in a sense, just pays for it all. Does it all focus everything on this approach and the.

E

Other option is.

G

More, like you know what you call a free market or something right where basically you you kind of like you, took the risk in creating this proposal and and um bring it to governance. But then now you will have completely de-risked like you, will fully de-risk sort of the actual work or the next three years of building and integrating and setting it up and then from there.

G

It's like you this. What has that? What has then been set up is like uh basically, um a fixed rate protocol that has sort of a team attached to it. That is getting a profit share and their goal will then just be to try to integrate that everywhere, spread it everywhere sort of grow, it maintain it. So they can keep getting that profit share over time and there's type of there's basically two. I think that's kind of like like the thing I want to get to what is that in the longer term.

G

So even after these three years, even when this profit share thing is in place, there's basically there's there's sort of an implicit additional, almost like a negotiation that has to occur or that that's a part of this or some kind of expectation as part of it, which is, I mean, first of all, it's something like deco protocols.

G

Integration into uh front ends around the ecosystem, to the extent that maker can influence that, and if we assume that maker just cannot influence that at all, then actually, this doesn't matter right, so oasis they'll integrate whatever they want to integrate. It's a private company now device savable, integrate whatever, basically, whatever gives them the cheapest rate in a sense, um and then this whatever, who they think is like their reliable powder. So this stuff, in fact they might integrate multiple and do kind of a um an aggregator thing across it.

G

But then, but that's where sort of the other thing comes in right, which is how much of maker's stability appetite is funneled into this thing, because that is both kind of like a really like there's. Just like I mean first of all, this directly impacts um the performance fee that you get and it also it is some there's some kind of connection between that and the marketplace. You create sort of on the other side of people who are buying into it right, because mega wants to dump it's kind of it's it's fixed.

G

They want to lock in its fixed rates into the markets, the different markets. It can do it with yeah based on their liquidity, essentially uh and their well, that equity and where they get where it gets the best prices anyway. So morning I mean yeah, so I'm wondering what do you think of that? First of all,.

B

So so worst case, uh like worst care, not worst case like from a profit like profitability. Slash standpoint decker is just like used uh uh like, I guess, like. Let's say, if maker like, there are like a group of solutions like all offering like make the opportunity to enter like their own versions of electric spirits, and then they call it place of mind, along with, like institutional walls and deco plays. A minor role.

B

Right helps like discover, like uh the market rates uh ads, adds a bit more like data, so that everything else can be priced at an optimum level. So in that sense, essentially like the like, the only thing that would uh uh that would uh be is like you're managing a core unit and uh we get the the coordinate compensation and then like really nothing else.

B

So if, if uh because this adds like this gives like maker, the opportunity to, I guess like have a feature that maker controls like there's an opportunity for me to like push more volume through deco, because, like uh naturally like this is this is where the walls don't move anywhere.

B

This is where, like, uh for example, like one big thing, is like surplus collection right most other solutions like yield and pairwise surplus collection, like happens like at the end of the term deco, gets like uh uh books, the revenue slash profit like at the beginning of the term right at the sale, institutional vault, it's a mix like origination fee at the start and ongoing until the end of the term.

B

So there's like all these advantages and we naturally see even in a competitive environment, with more volume going through deco and when that happens like uh we naturally would have like uh this extra incentive we'd actually see some profits out of the 15 share, but uh overall, like yeah, it's like it's, there is, I mean it. It becomes as native as like governance really wants it to be. There is uh other than that.

B

I don't think we really have like any hooks in the system that essentially, that lock maker into this and nothing else, like you, said, user interfaces would aggregate and would just pick like whatever uh works for the users the best so.

C

E

C

So so in in a way, gecko bears the risk of external dependencies in terms of pushing volume to it. So it may or may not see an incentive right, but at minimum maker will have a core unit. That's working for the benefit of maker, that's delivering fixed rates. So the reason.

B

We went uh yeah the reason we went with this model. Is it's an interesting model like from us right, like most people just do a startup, and I guess, like I, don't know, get some liquidity from maker and not worry about all these features. The reason we went with the native approach is just like the scale of maker like broon, like you, said, the communist model, where essentially maker, is the aggregator off like everything like we love. We love that, like future, as in we want to see like maker as like the.

B

The source of like most of this liquidity rate, rather than it getting like fragmented into like a bunch of like other solutions, so that's an end goal that we we're, like, I guess comfortable with so and so in that sense, like we thought like hey, why don't we just bring it like as a native thing, and then we structure, like our incentives on the back end behind maker, rather than I guess like deciding whether we want to compete with maker this month because, like we have like low liquidity in our whatever uh to suffer to fund our like loans and then like maybe next month, we try to switch back to a cooperation mode.

B

So rather than that, like we just stay behind, our incentives are behind the makeup protocol.

B

We don't have to like worry about, I guess competing one month and then cooperating the next month.

B

That's like one of the uh reasons why we went to it. It does look complex, but the big thing is that it we are trying to. I guess, like align like align with maker, it's just like maker, the scale, the scale at which maker operates and borrowing right even compared to other landing protocols.

B

It's like it's really big and uh most fixed rate solutions like have been like running into like liquidity issues, so naturally they're coming back to maker, so we're like um I mean we could have probably done something like that.

B

But then we were like I mean if everybody wants to come back to meeker, why don't we like, I guess, jump ahead of them in a certain way and that's the thing, but again, even with this proposal like it's like the compensation part like can be up front or after, like there's no reason it has to be one way and we are like totally open to like modifying these right. Like I said, there's no precedent has been set like for something like this somebody bringing a product to maker and integrating it and managing it.

B

So, uh naturally, if like governance prefers like a certain way right, a delegate has expressed that like yeah, this is too complex after three years. I don't want to sit with you and negotiate like what the value of like 15 would be if uh scaling that by I don't know 10 products. It just becomes like too much of a headache for maker 2, so naturally, like I guess, governance could prefer like just purchasing it up front. We they're totally open to that essentially like um it's just like what governance prefers.

B

At the end of the day,.

G

What happens if uh maker voters decide to sort of uh off board the coordinate like basically you're? Not, I don't know.

E

G

Unhappy with the with the progress.

B

Yeah, that's the that's the that's the risk we are taking, as in like, we feel like uh we're, taking risk, basically on our own execution, our own ability to basically set up the integration and then like basically grow it like, like, like I said, like there's. No cash here.

E

It's literally.

B

Smart contracts and it's like the.

E

Reason like I guess.

B

Like uh yeah, all those risks are there on our side like there is it's there. It's just the nature of like working with a larger protocol. Right, like we, like I mean like deco, is like a feature. Decor is like a uh like. A like, like a small thing maker, is like a larger box. Larger number of users, larger number of integrations, larger, like market share, larger mine share. So in that sense like that risk is always there, but uh yeah.

C

That'd be to be very concrete. uh Brunette. The downside to maker would be that, uh because we're using continuous funding model maker would commit to uh funding the core unit for one quarter as it unwinds and beyond that there would be no uh no additional.

C

You know risk for maker and and the upside is. If maker does fund this in the next quarter, um we will be able to make significant progress on the original or the first iteration of the sandbox contracts and getting this integrated. So you know in a way um maker funding this uh at this time is, you know, universally a benefit uh when you look at the cost benefit against the risks, at least in my opinion,.

A

Nice so yeah, thanks for all the all the questions, uh roon and well paper just left, but also some good questions on the chat. I don't know if there's anything uh anything else we want to explore.

A

We already had a call a couple weeks ago, it's on the on the youtube channel explaining how this works in a more technical way. So I guess we covered enough all the the different possibilities.

A

I know roon, if you or or anyone else, uh have any any doubts or any concerns about how this could be moved forward by maker governance.

A

Maybe david or pros uh yeah.

D

I I could talk a little like very, very briefly about like, what's going on in my mind, so right now, there's three different solutions that have engaged with maker uh community right and then there's even a couple, more solutions that haven't right like sense, finance or element.finance, uh but of course uh taking the three solutions that are on the table and comparing them like. This call was extremely helpful. I got a lot of things from this call that I didn't get from my reading through the forums. So so thank you, vamcy.

D

Thank you, andrew uh and generally speaking, yeah like I want to learn more about pairwise and tlm, like the biggest thing for me, is that business development incentive like having uh this native uh having the team native and having like a proper incentive structure to really build this line of business, I think, is extremely important. So if we were to not go with deco, for example, and go with pairwise or tlm or really focus there, how do we do the same thing there is. Is it that we give growth this initiative? No right like it?

D

Would they need their own core units? So these are the questions that are floating in my mind for like what's the best path for maker from a business standpoint uh and so far, deco has the incentives and everything kind of right. I really like where it's going um and so yeah yeah. That's. Those are my thoughts at the moment.

A

I had a couple of conversations with the with the pe team and I don't know if this is something that you're adding on your table for comparing the projects. But what I heard- and I might be wrong on this one, but I think that this solution would include the least effort from the pe team, which seems to be the bottleneck at the moment in terms of speed in terms of bandwidth in terms of scaling fast. So that's something that should be considered as well.

D

Yeah, that's a very good point for for tlm, for example, it's on the it's on the pe team and also for pairwise, uh like they they're it still isn't fleshed out, but they're also thinking you know, they're gonna rely on the pe team and maybe provide one developer themselves uh or two at most, but but that's kind of just you know that hasn't been fleshed out by their team yet but yeah. I totally see your point juan and I agree.

A

Great so yeah we're approaching the top of the hour. I don't know if we have any other red team questions. uh I think we we were relatively thorough, um maybe vampy or yeah. Do you guys want to say something before closing the call.

C

Yeah, I see frank on here: does he have any any thoughts or opinion um just want to check in all the delegates.

E

Yeah, for me, uh I'm really excited also that pe is um well actually the incubation of the sandbox.

E

um You know I really interested to see how that's going to work and help any future incubation uh teams um and in getting back to kurt's point. You know uh this is something that uh bamsey is bringing to the table right. The fact that he has worked with a lot of these uh protocol engineering team members in the past and and there's the connection there um and they have a good working relationship. So me personally uh for flip flop, flap delegate, I'm meeting um very heavily on deco food disclosure.

A

Nice. Thank you frank. I.

D

Do have a quick, really quick question before you close it off uh for the cross team effort, so I was thinking about this, uh although deco doesn't need pe in the same way that the others might wouldn't deco still need to engage pe during solution design, coordination, science, like isn't there kind of like no matter what gonna be some overlapping coordination that happen, that has to happen, or am I thinking about it wrong.

A

I mean this is something that we will need to solve as a doubt right when you start decentralizing things and you get redundancy, you potentially want people reviewing the code that goes live by a bunch of different people at this stage. P probably has a monopoly on this, so we would want them to to review, and- and it's not that we want to answer them and I think.

B

One uh yeah one, one concrete output that we've been discussing with the csp is like leaving deco a site like using deco as like a test case, but we designed the intermediary contract or the interfaces like that sandbox risk of like external smart contracts. So that way, maybe in this instance like maybe uh like so designing that sandbox like would basically help like uh the future integration site that want to. I guess, like not at the liquidity level, but maybe like want to. Similarly like natively, bring a feature to maker.

B

They could like reuse, the same interface and then uh like, essentially that sandbox like uh in router's works caps. The risk of like losses on the maker site versus, I guess uh another example could be like giving like white dots at full. Access of red dots up to deco would mean like something wrong. Something goes bad on the deco side and we suck like I don't know.

B

100 billion die or something it's like just a crazy uh loss rate versus the sandbox contract that we basically uh uh figure out is like thinking about the various ways in which, like we can cap risk and in that way, even the worst possible, like hack or at the uh integration level, would still like cap the risk on like uh make a site, so that contract has like there's no no such contract yet, and it will be like, like, I guess like in our future discussions like, will basically hash out hash that out and uh see if it works for deco and then, if it does like then, like kurt mentioned, deco is going to touch like a few parts within the makeup protocol.

B

So in that sense, like every other integration would naturally do the same right. So they could apply like the learnings and then give give everybody else, a template that they could easily follow. So that, like you're, not repeating this again and again and naturally over time, it reduces the load on like pe and the amount of due diligence. They have to do on each integration right, while still continuing to keep makers safe.

A

Yeah, nice to see that we will see a live version of or potentially a live version of the sandbox. uh Looking forward to that, I think it will be crucial in scaling maker, um so yeah the discussions we keep them on forum.maker.com for anyone watching uh vmc. What's the best way to reach you? If, if there are any questions or comments info.

B

At deco.money nice send and send us an email.

A

So, thank you guys for for coming. As always, it was great having you and see you on thanks thanks. Everyone.