Maker

Transcript

hello everyone I'm here to talk about maker I'm gonna give a short talk before I start it's very likely that not everyone here has heard of maker so I'll just explain maker the contract system whose function is going to be to create the dice table coin and the associated credit system and the properties of the die that make it awesome is that well it's initially pegged to the SDR but it's deflationary it's collateralized in excess so there is more value locked up backing that died all times than there are about the total value of the die and it's eventually trust free which means that it uses the

most current trust free mechanisms available to get data feeds and to do the the pegging mechanics that is available about the time so this talk is not going to be about the actual stable flowing mechanics because that is not appropriate for a 15 minutes talk and did we have a great white paper dedicated to exactly that so instead today we're going to talk about what the what the white paper doesn't go into which is how the actual contract system is designed so what are the different components and then I'm gonna go also going to mention how we can go through go about deploying this contract system

over time and start getting some utility out of it even before the whole thing is complete so first I'm gonna introduce basically what the version 0 of the maker contract system is going to look like so this is an authority contract and this is basically a command and control pattern that we use throughout the maker system basically every single contract I didn't draw arrows because there would be too many they all point to this one they have a reference and every single protective function you use a modifier that basically asked okay is this caller allowed to call me at this entry point and the authority says yes or no and the authority is

bootstrapped with one some other contract that already has permission to call the set can call function on the authority so basically it has an implicit owner at the start so the components here so yeah that's the authority this is the maker asset platform is what this stands for it's a conceptual grouping of the registry of assets which all share the same interface and semantics that we need to be able to use them in the in the collateral that mechanism so here you can see how we also separate the data and the controller and this is extremely useful because for example right now

these controllers are the simplest possible asset controlling that there is a space have a single transfer function and a single event that it fires on that transfer but but we're quickly converging on some sort of more reasonable access standards and ones that are more powerful and actually let you programmatically do things with with your assets so we might want to swap out the behavior the controller but then keep keep all the balances in place and so what this means is that the correct way to actually interact with a maker system is to use what's called a maker user mixin contract which it's just a bunch of internal functions and modifiers which help you traverse the maker systems so for example you would inherit from the the maker user contract

it doesn't add any overhead unless you actually use for example get assets and then the the maker these are the you know it's a library we publish and it has all the details about how to actually look up in the registry of the controller okay so this is what the initial version look might look like so now let's look at what the final version might look like so the first thing you might notice is the mistake that I made that I only noticed like one minute ago obviously this contract system is not an off chain service this is all still just some our contracts but each of these is is now a cluster so we've zoomed this map is what you just saw and I exposed the assets feel as little contract so you can see how MKR and I in

particular wired up directly to the CDP engine which is the collateralized debt position engine which you should read the white paper to understand what that is but it's basically a bit of a fundamental building block that creates and destroys the dye so this this is an example basically you'll notice the second thing is that there's no more nexus in this picture so in the previous slide I said that Nexus was like the implicit owner of the maker authority but some somewhere along the line this this is going to be transferred first to MK our stakeholder the the stakeholder vote directly but then at some point they're going to also think realize that it's wise to put this intermediate governance contract between themselves and admin

rights which is basically the ability to modify the authority's permissions and so but basically the idea here is that this is an example of how adapt can start out highly centralized and very trustful and then over time you can basically update it to lock it lock down some of its behavior and then any you know why I think we can call maker trustless even though there's still a governing body that sort of has two sets high level monetary policy is because there's this governance contract where or MKR folders to provably restrict their own powers and the most popular example for that is the time-delayed

admin action so if the MKR holders are going to do some administrative action on the system everyone has maybe a week at near the start and then maybe it can be up to a year if the system is running and it's very stable for a long time so I think I have enough time to basically just actually describe how these system parts interact so the you know here these are all simply registry entries the nkr this talks to the governance to try to cause changes to the system that might affect who the feed providers are it might affect more basic stuff like in the contract permission wiring and it

also might affect just move the monetary policy inside the CDP engine and then the CVP engine has unique permissions to spend money out of the vault which is the it's basically where the insurance pool is of collected died and then it's also where assets that might have been emergency bailed out they go there before they're auctioned off okay so I also wants to go ahead and show this part which is that another really important component of the maker system is that there are several incentivize actions that have to happen quickly and reliably and so you know we say like okay the theory is if it's profitable

then you we should expect it to happen automatically but in but we want to actually make sure this happens so Nexus is creating a I guess the software a stack for basically a single node which will try to make as much money as possible off of aetherium because it will be aware of all the different incentivized actions that I can take for example the margin calls or the the more accurate is the collateral redemption in the CDP's that's an example of something that needs to happen automatically but it's actually profitable for the person to use so this is an example oh yeah another another great example is like how you know the alarm clock app also has incentivized actions so there's no

you know we would bundle that into in civic keeper stack as well and so yes so all this is great but this this is a really this is a really long way off and I always hate to tell people these really conservative estimates for when they die as described in the white paper is going to be launched but I'm really happy to announce that we have identified a strategy for making a series of dye releases which are increasingly trustless as time goes on so the the first mechanism you might have to trust us completely and we might even do whitelisting just to avoid any call

with that but then as we as we can make it more and more trust less than even if the exact mechanisms changes as long as you make the stay the right guarantees and as long as you basically have enough money to back to buffer the buy back from one type into the other you can basically do this transition behind the scenes and anyone who uses a die in a smart contract they don't even have to be aware that this transition is happening so this is exciting because it basically there are a lot of people who they just they want a stable point but they they just want like a small amount they just want to do a simple proof of concept and it's not going to be an app

that is gonna be holding a ton of money and it doesn't requires trust and so I'm happy to announce that this is possible and astute viewers would have noticed that in the version 0 there is a die a balanced database and a diet controller and so that version 0 is going to be happening tonight so we're having a second of our maker meetup and a deploy party it's going to be a king's arm pub but we're going to meet outside here at 4:15 and then go over there for 30 so you're all welcome to join us we're going to deploy the MK our controller and balance database and the die control arm balance database and all the

associated and all the other stuff you saw on the first version there there's not actually going to be die created unfortunately but you can start writing your contracts as if it is created and the MK r is going to issue and made liquid so anyone here that might have participated on a private sales you actually have your asset is liquid on Shane tonight so that's the end of my talk I hope to see you guys at the Meetup and thank you so much for listening you