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