►
Description
@Derek discusses MIP39c2-SP7, a subproposal for adding a Smart Contracts Core Unit, and related subproposals MIP40c2-SP7 (Modify Smart Contract Core Unit Budget) and MIP41c2-SP7 (Facilitator Onboarding, Smart Contract Core Unit).
Agenda: https://forum.makerdao.com/t/core-unit-launch-pod-sessions-session-3-smart-contracts-core-unit/6946
Governance Forum:
https://forum.makerdao.com/
Disclaimer: These calls and the summaries are produced and hosted by MakerDAO community members. Content produced by the community are not the statements or views of the Maker Foundation.
A
A
Hopefully
we
can
get
into
the
the
talks
with
that.
Just
as
a
very
quick
reminder
we
are
so
the
vesting
topic
was,
I
would
call
it
controversial,
but
was
heated
up
so
today
we'll
try
to
focus
mainly
on
on
the
smart
contracts,
core
unit
implementation
and
not
on
investing
in
general
for
the
for
the
maker
community.
That's
something
that
we
will
discuss
in
the
coming
days.
B
My
name
is
derek
fossman,
so
I'm
putting
myself
forward
as
the
proposed
smart
contract
team
core
unit
facilitator.
I've
worked
side
by
side
with
the
smart
contract
team
on
all
sorts
of
things,
from
instant
access
modules,
documenting
dss
gov.
We
worked
on
migrations,
so
fire
to
die
also
worked
on
chief
1.2.
B
I've
likewise
done
a
lot
of
work
with
the
front
end
team
and
yeah.
So
with
that
today
I
will
be
talking
about
the
smart
contract
team
and
if
I
can
go
to
the
next
slide
there
we
go
okay,
so,
first
of
all
yeah,
let's,
let's
introduce
the
team
on
the
right
side
of
the
screen.
You'll
see,
the
team
is
made
up
of
nine
individuals
from
chris
brian
kurt,
gonzalo
sam
nas,
emilio
tanner
and
myself.
B
So
currently,
nine
people
we're
actually
have
included
five
open
positions
in
the
the
budget.
Mip
and
the
really
cool
news
here
is
that
we've
actually
attracted
some
attention
from
the
industry
and
we're
discussing
with
two
individuals,
a
potential
physician,
some
potential
involvement,
and
I
bring
that
up
because
I
think
it's
really
important
to
have
a
proposition
and
a
ground
to
stand
on
that.
You
know
really
attracts
people
to
the
platform
and
gets
people
involved
and
and
are
really
wanting
to
participate.
So
I
think
that's
really
cool.
B
I
should
have
probably
first
started
off
with
the
background
of
the
team
and
and
the
fact
that
the
comprehensive
understanding,
blockchain
fundamentals,
security,
architecture,
consensus,
algorithms,
formal
modeling
of
verification
and,
of
course,
solidity
and
ethereum
development
experience
that
all
of
these
guys
have
and
that
they
all
bring
to
the
table
and
have
a
lot
of
experience
specifically
with
maker.
So
I'm
sure
you've
all
seen
them
in
the
chats
and
they're
all
familiar
faces
that
you've
seen
so.
B
So
the
first
one,
maintaining
an
open
forum
for
discussion,
like
I
said,
you'll,
see
us
on
the
on
the
the
forum
on
the
rocket
chat,
discussing
everything
maker
related
and
we're
also
unafraid
to
voice
our
concerns.
We,
we
are
all
mkr
holders
and
participate
participants
in
governance,
so
we
are
unafraid
of
voicing
those
concerns
and
really
trying
to
put
forward
what
we
feel
is
best
for
the
protocol,
and
I
think
that
comes
across
in
a
lot
of
our
exchanges
and
discussions
around
what
is
optimal
for
for
development
going
forward.
B
B
I
guess
vertical
is
it
you
could
say
which
underpins
other
aspects
of
growth
and
maintenance,
as
also
other
verticals,
but
we'll
get
into
that
in
in
a
few
slides
time,
so
continuing
along
again
with
the
concept
of
engineering
standards,
engineering
practices,
making
sure
that
we
rely
on
on
industry
standards
when
and
unit
tests
when
deploying
code.
We
also
make
sure
that
this
code
is
modularized
to
keep
our
smart
contracts
simple.
The
attack
surface
is
small.
B
C
C
D
You
tend
to
also
hire
the
like
absolute
top
tier
that
you
can
possibly
find
so
the
the
more
constrained
you
are
rather
than
than
a
sort
of
shotgun
approach
for
talent.
You
end
up
interviewing
people
that
are
engaged
and
enthusiastic
and
also
like
high
skilled
and
and
it
allows
like-
I
don't
know-
for
a
better
selector
right.
Finite
resources
means
you're,
gonna
spend
them
where
it
matters,
and
so,
but
aside
from
that,
I
think
we
can
go
above
14..
D
B
B
We
do
on
the
governance
and
risk
call
that
chris
does
with
regards
to
discussing
the
progress,
achievements,
challenges
and
roadblocks,
one
that
we
haven't
done
before.
We
have
intermittently
done
it
within
the
foundation,
but
I'd
like
to
make
it
more
of
a
formal
process,
and
that
is
setting
quarterly
objectives
and
key
results.
B
B
B
Nicely
sort
of
creates
three
categories
that
I
think
a
lot
of
the
work
we
have
in
our
mandates
fits
within,
and
now
I
want
to
kind
of
dive
into
each
of
these
in
just
a
little
bit
more
detail
so
that
we
can
break
out
what
is
actually
within
these
categories.
So
I'll
start
with
the
maintenance
piece
that
is,
of
course,
the
around
the
execution
and
implementation.
B
So
the
day-to-day
operations
that
you're
familiar
with,
such
as
executive
proposals,
bug
fixes
updates,
expert
consultation
on
system
parameters,
interactions
like
with
the
risk
team
like
with
the
collateral,
onboarding
team,
and
here
the
the
important
piece
is
that
you
know
failure
is
not
an
option.
This
is
where
the
space
grade
code
comes
into
it
and
on
the
other
side,
we
have
growth.
B
Where
you
have
innovation
new
features,
r
d:
this
is
where
we're
talking
about
dss
gov
voting
contracts,
instant
access
modules,
delegation,
incentivization
liquidate,
liquidas
liquidations
and
potentially
down
the
line,
l2
solutions
and
other
l1
blockchains
and
there's
not
a
clear
divide
between
these
two
groups.
There
is
a
phasing
from
one
to
the
other,
such
as
liquidations
will
move
into
the
maintenance
phase
as
it
gets
deployed.
B
So
everything
that
we
push
to
the
protocol
and
again,
there's
no
clear
delineation
between
these
groups
at
the
moment,
even
though
there
is
a
slight
difference
in
the
mindset
for
the
innovation
for
safety
and
security
and
maintenance,
but
all
of
them
require
communic
communication
with
the
community
and
awareness
of
what
those
different
roles
are
and
what
the
outcome
and
what
the
value
of
each
of
these
is
in
terms
of
being
delivered.
So
it's
it's
not
done
in
isolation.
A
Derek
in
terms
of
team
size
it
it
feels
right
or
nice.
I
see
chris
and
brian
almost
suffer
every
week
with
the
amount
of
work
that
they
need
to
do,
and
I
see
all
this
scope,
which
seems
quite
broad,
and
I
don't
know,
potentially
one
could
argue
that
you
could
have
a
specific
team
for
each
of
the
pillars
right.
So
do
you
think
that
this
might
be
an
issue
in
the
future.
B
It
has
come
up
with
the
community,
but
at
the
moment
everything
that
we
deploy
has
to
have
the
rigor
and
testing
around
it
that
this
team
provides
so
in
in
the
future
down
the
line.
Potentially,
yes,
as
we
onboard
more
individuals,
there
is
an
opportunity
to
create
a
safety
team
for
lack
of
a
better
term
or
a
growth
team
that
focuses
specifically
on
layer,
two
solutions
and
r
d
or
the
maintenance
of
of
what
we
put
forward
today.
B
So
to
your
question
around
that
that
yeah
definitely
in
the
future.
I
think,
as
the
protocol
grows,
as
there
are
more
collateral
types
as
there
are
more
collateral
adapters
as
a
result,
then,
yes,
the
focus
will
shift
from
perhaps
more
audits,
less
audits
at
different
points
in
time,
more
more
focus
on
verification
methods,
early
on
and
and
this
will
evolve
over
time,
so
yeah
just
trying
to
illustrate
the
the
work
and
how
that
ties.
In
with
what
I
have
here,
the
team
mandates.
F
If
I
can
jump
in
there,
derrick
yeah
one
ucs,
you
see
chris
and
I
in
the
of
mandated
actors
calls
and
the
governance
meetings
because
we're
the
ones
that
generally
speak
up.
But
I
want
to
assure
you
that,
like
everybody
on
the
team,
it's
working
just
as
hard.
We,
I
think
we
all
do
want
to
get
to
a
place
where
we've
got
the
these
teams-
and
you
know
derek
alluded
to
that,
but
getting
a
dev
to
that
point.
F
B
B
So
I
can.
I
can
jump
into
more
on
that
if,
if
we
want
to
but
there
is,
there
has
been
discussion
that
that
is
different
from
a
developer
role
and
it's
a
very
specific
focus
so
so
yeah
I
mean
it
probably
warrants
a
bit
more
discussion,
looking
at
the
security
roadmap
that
we're
currently
working
on.
So
I
wouldn't
want
to
misrepresent
that
in
any
sort
of
short
statements,
but
I
know
that
curt
and
tanner
are
working
a
lot
on
that
at
the
moment.
So
in
the
coming
weeks
we
should
definitely
have
something
to
to
share.
H
H
Every
choice
you
make
at
the
code
level
also
has
emergent
effects
at
these
higher
levels
of
behavior,
and
so
they
really
are
quite
integrated
and
and
bad
assumptions
about
about
the
economics
or
incentive
structure
can
lead
to
critical
failures
right.
So
these
we
see
this
as
integral
to
safety,
which
is,
as
a
result
integral
to
the
the
core
of
the
engineering
process
itself.
B
So,
yes,
I
just
wanted
to
tie
the
these
concepts
around
maintenance,
grocer
and
safety
to
the
team
mandates
that
we
have
at
the
moment-
and
I
won't
go
into
these
in
all
the
details.
They
are
in
the
mip
and
they're,
also
in
the
powerpoint
notes
that
we'll
share
with
everyone,
but
at
a
higher
level,
walking
through
it.
So
you
know,
security
and
safety
is
about
reviewing
and
vetting
all
internal
external
code,
we're
on
pagerduty
for
immediate
security
response
with
regards
to
the
community
involvement.
B
This
is
about
education,
training,
tooling,
promoting
integrations
with
regards
to
collateral,
onboarding,
so
auditing
tokens,
building,
innovative
collateral
adapters,
making
sure
we
do
technical
assessments.
Protocol
evolution
is
looking
at
having
new
modules,
exploring
other
l1
chains,
exploring
potentially
new
deployments
euro
swiss,
etc.
That
I
know
a
couple
of
the
members
have
posted
on
the
forum,
which
is
really
cool
as
well
as
contract
redesign
research
and
development.
B
So
this
is
very
much
like
tana
was
saying
around
extending
formal
verification
languages
potentially
also
contributing
to
the
ethereum
roadmap,
making
sure
that
we
are
up
to
date
on
ecosystem
changes,
protocol
maintenance,
so
making
sure
we
have
operational
needs
in
place
that
we
adapt
to
immediate
risks
and
on
the
tooling
side,
automation
and
infrastructure.
So
make
sure
we
have
developer
tools
and
we
have
readmes
in
place.
B
So
this
this
mandate
is
very
broad.
Yes
and
we've
mentioned
team
size.
We've
mentioned
the
responsibility
of
the
team,
and
I
I
wanted
to
look
at
this
okay,
this.
This
is
the
the
team
mandate
at
a
higher
level.
But
what
does
this
mean
when
we?
We
look
at
the
backlog
of
work
that
we
have,
and
this
is
not
to
say
well,
there's
a
lot
of
work,
which
is
pretty
obvious.
There
is
some
of
it's
done
some
of
it's
in
process
and
there's
a
lot
of
it
to
do.
B
But
the
key
thing
here,
I
think,
is
making
a
value
assessment
and
prioritizing
that
work.
So
this
is,
of
course,
not
all
about
smart,
smart
contracts.
This
is
about
smart
contracts,
risk
collateral,
onboarding
re
name,
a
name,
a
a
core
unit,
plus
the
community-
we're
all
involved
in
this,
so
basically
just
just
showing
that
how
we
apply
the
theory
and
and
the
mandates
to
what
work
exists
in
here.
B
So
the
importance
of
prioritization
is
something
that
I
wanted
to
convey
by
showing
how
much
is
on
here
and
some
of
it's
within
the
community,
some
of
it's
within
the
team
itself.
With
regards
to
tooling
and
testing,
these
are
not
things
you
see,
but
that's
where
I
want
to
or
sort
of
raise
the
bar
in
terms
of
communication
and
understanding
of
what
we're
working
on
in
these
different
areas,
so
that
there's
a
better
understanding
across
domain
teams
and
the
community,
because
yeah
there's
a
lot
of
work,
but
that's
great.
C
F
I
Well,
I'd
say
it
a
little
bit
more
nuance
than
that
it.
It
depends,
of
course,
heavily
on
the
extent
of
background
of
the
person
you're
bringing
on
like
if
you
hire
someone
who
is,
you
know,
they've
taken
a
boot
camp
or
something
and
smart
contracts,
and
they
know
a
little
bit
yeah,
it's
probably
going
to
take
them.
You
know
at
least
six
months
to
sort
of
be
fully
up
to
speed
on
all
the
protocol
details
and
such
if
you
hire
someone
with
more
background.
I
They
can
be
fully
up
to
speed
sooner
and
as
people
ramp
up
and
come
online,
they
can
get.
You
know
expanded
scope
of
tasks
that
they
can
take
on
and
contribute
to.
So
it's
not
that,
like
somebody
is
totally
useless
for
six
months
and
then
after
six
months
they
flip
online
and
all
of
a
sudden,
they're
useful.
It's
that
you
know
the
the
scope
of
what
they
can
be
entrusted
with
or
tackle
independently
gradually
grows
over
that
time.
I
I
think
it's
worth
calling
out
that
there
is.
I
There
is
a
little
bit
of
a
tax
on
the
team
right
because
you
have
to
spend
time,
mentoring
and
training
and
code
reviewing
and
such.
But
it's
well
worth
it
because
it
pays
off
well
in
the
long
run.
But
that's
also
why
retention
is
very
important,
because
there
is
that
big
investment
in
learning
the
nuances
of
the
protocol
and
being
able
to
get
up
to
speed.
C
B
Just
as
a
little
bit
of
a
summary,
and
with
that
I
wanted
to
get
on
to,
I
think
I
had
one
last
slide,
so
this
is
the
one
that
will
generate
a
bit
of
discussion
so
with
regards
to
team
incentivization,
so
in
met
40,
I
think
you've
you've
all
participated
in
in
comments.
Thank
you,
everyone,
and
in
that
map
we
requested
a
budget
that
includes
team
salaries
as
well
as
an
mkr
bonus.
B
B
So
for
context
there,
the
current
burn
is
34,
000
mkr
and
we're
0.1
per
person
is
995
mpr
over
four
years.
So
in
the
first
year
that's
248
mkr
of
25,
and
the
total
allocation
over
four
years
is
13.
000
mpr,
again
emphasis
there
on
over
four
years,
and
because
this
is
dependent
on
whether
an
individual
remains
in
the
team
and
whether
the
team
remains
voted
in
by
governance
as
a
core
unit.
So
some
the
some
of
the
areas
that
I
just
thought
I
would
raise
for
the
discussion
was.
B
B
B
Compensation
as
a
long-term
incentive
is
best
tied
to
the
success
of
mkr,
not
cash.
This
is
my
view
based
on
what
I've
seen
in
the
industry,
because
dollars
themselves
are
not
aligned
to
the
protocol
success
again.
The
emphasis
over
the
long
term
is
something
that
I
saw.
So
I
wanted
to
capture
that
in
an
absolute
value
of
mkr,
and
I'm
aware
that
that
comes
with
different
different
discussion
points.
B
So,
despite
the
built
up
skill
set,
I
thought
it's
also
worth
mentioning
that
it's
very
unlikely
that
individuals
will
stay
in
a
role
or
such
a
role
for
four
years,
so
we
really
want
to
incentivize
their
ongoing
value.
Add
over
that
time
and
yes,
because
of
the
absolute
mkr
number,
our
team
members
are
exposed
to
both
the
upside
and
the
downside
of
mkr
price
movements.
So
in
doing
so
we're
tying
the
protocol
success
or
downfall
to
the
team
reward
as
as
a
result.
B
It
didn't,
however,
feel
like
we
were
agreed
as
a
community
with
regards
to
being
unified
on
whether
tokens
should
be
minted
or
bought.
What
what
is
the
process
and
mechanism
here
that
still
seem
to
be
up
for
discussion,
and
I'm
not
sure
if
that's
something
we
have
time
to
discuss
here
today
or
tomorrow
is
a
focus
point.
But
I
thought
it
should
be
raised,
and
I
did
say
here
that
yeah,
a
dollar
value
is
less
effective
than
an
mkr
value.
B
So,
oh
yes,
I
left
some
questions
on
here
to
sort
of
spawn
the
discussion.
So
how
do
we
grow
the
team
in
following
years
as
determined
by
protocol
demand,
so
so
yeah,
the
growing
the
team
and,
as
as
you've,
seen
there's
a
lot
of
work
that
work
will
be
relative
to
risk.
So
I
would
imagine
that
empire
vesting
in
future.
B
B
Is
it
feasible
to
build
performance
measures
within
the
team
or
across
teams?
That's
another
question
that
was
coming
up:
it's
difficult
to
do
so,
which
is
why
I've
stayed
close
to
having
an
absolute
mkr
value
to
tie
in
that
appreciation
or
deep
appreciation
over
time
again.
Tying
protocol
success
to
the
team
and
a
recent
question
that
came
up
was
what,
if
we
diverted
a
portion
of
the
burn
towards
incentivization,
that
introduces
some
uncertainty,
but
it's
a
question
that
was
asked.
B
A
B
A
B
Well,
I
think
you
have
to
ask
what
what
is
the
value
of
those
individuals
compared
to
to
the
smart
contract
team?
I
think
with
we're
saying
that
there's
diminishing
returns,
if
you
sort
of
go
beyond
the
number
we've
proposed,
and
I
don't
think
that
it
would
make
sense
to
grow
beyond
that
now,
if
we're
talking
about
other
teams,
those
other
teams
have
different
value
propositions
which
they
will
have
to
substantiate
and
put
forward
that,
I
think,
are
absolutely
warranted
that
that
would
be
something
that
they'll
have
to
put
forward.
A
D
D
A
Sorry
that
was
my
question
I
I
was.
I
was
hearing
a
lot
of
concerns
from
from
a
lot
of
people
saying
like
yeah,
but
I
we
don't
like
minting
we're,
not
fan
of
this
or
we
could
use
this
other
mechanism
and
at
the
end
of
the
day,
I
feel
that
not
everyone
is
going
to
get
point.
One
percent,
and
also
not
everyone-
is
going
to
take
four
years.
So
it
feels
like
it's
something
fair,
but
to
be.
F
F
I
Another
thing
to
consider,
besides
the
the
amortization
over
time
and
the
the
relative
values,
is
that
it
won't
be
like
everyone
who
joins
and
perpetuity
always
gets.
You
know
0.1
percent
right
if
someone
right,
if,
after
a
year,
we
hire-
and
you
know
a
couple-
more
smart
contract
developers-
you
know-
I
think
the
proposal
right
now
that
you
know
they'd
get
proration.
I
E
B
When
I
looked
at
investing
packages
for
silicon
valley
companies
like
facebook
and
others,
I
was
seeing
packages
that
were
ranging
from
two
to
three
years,
and
I
wanted
to
extend
that
because
a
it's
unlikely
people
stay
that
long
but
b.
If
they
do
stay
that
long,
they
really
want
to
keep
them
engaged
and
involved
with
it's
a
an
incentive.
B
B
Because
so
I
mean,
if
we
let
let's
look
shorter
and
longer,
to
sort
of
put
that
number
into
perspective.
If
we
look
shorter,
then
I
really
think,
let's
say
one
year
or
two
year.
I
think
that
I
think
it's
too
short,
because
you're
incentivizing
people
to
get
modules
out
the
door
we
sort
of
cut
corners.
We
we
don't
do
the
formal
verification
which
takes
months
and
and
then
we
sort
of
push
things
out,
because
we
want
to
get
a
reward
right.
So
we
want
to
stop
doing
that.
B
So
two
years
was
kind
of
felt
a
bit
short
even
in
crypto.
I
know,
but
it
didn't
feel
like
we
were
building
up
because
then
you'd,
look
at
okay,
maybe
rewards
should
be
offered
on
a
half
year
basis
or
every.
So
every
two
quarters
offer
a
reward
just
felt
too
short,
so
I
wanted
to
stretch
it
out
because
I
don't
want
team
churn
and
I
want
to
keep
people
engaged
for
a
longer
period
of
time.
Essentially,
it
was
kind
of
where
that
fall
came
from.
B
Yeah,
so
that's
the
one
year
really
which
it's
it's
25
at
the
end
of
the
first
year,
so
248
mkr,
we
we
have
that
same
25
over
the
four
years.
It's
just
how
it
worked
out.
There
has
been
community
discussion
for
well.
Should
you
stagger
it
towards
the
end
of
that,
or
should
you
bring
it
forward?
Typically,
you
bring
the
cliff
forward,
which
is
higher,
but
I
didn't
want
to
introduce
an
incentivization
to
okay
work
a
year
and
then
bail.
B
G
So
I
I
would
actually
say
that,
so
I
think
the
one-year
cliff
makes
sense.
Actually
you
don't
want
people
kind
of
just
bailing
in
less
than
that
time,
but
I'd
maybe
consider
making
these
subsequent
cliffs
more
of
like
a
continuous
scale,
rather
than
like
cliffs,
because,
like
it
kind
of
sucks,
to
be
sort
of
stuck
in
a
job
that
you
don't
like
for
like
an
extra
six
months,
because
you're
like
waiting
for
some
besting
cliff
or
like
vice
versa,
if
you
want
to,
if
you
do
decide
to
leave,
it
feels
kind
of
bad.
G
If
you're,
like
you
know,
if
you
leave
after
six
months,
then
you
get
like
none
of
the
best
thing
right
like
I,
don't
love
the
idea
of
like
golden
handcuffs
right
in
general,
especially
like
past
the
first
year
like
sure
in
the
first
year,
maybe
someone's
not
you
know,
someone
maybe
takes
the
piss,
but
like
once,
you've
had
someone
for
a
year.
I
feel
like
you
should
maybe
just
do
away
with
cliffs.
B
B
G
So
I
would
just
say
that
so
after
the
first
year,
there's
like
a
cliff
of
like
20.25
and
then
it's
just
like
a
continuous
like
line
up
to
four
years
right
so
like.
If
you
say
like
one
year
and
one
week,
then
you
get
one
week's
extra
maker
of
the
vesting
set.
Then
you
say
next
six
months
you
get
six
months
first
right
rather
than
yeah.
So
like
a
streaming
like
kind
of
streaming
vesting,
rather
than
like
cliffs
after
the
first
year,
is
what
I'm
saying.
B
Yeah
yeah,
okay,
I
I
think
that's
fine
and
I
know
with
brian
we
spoke
about
this-
that
that
would
be
possible
to
introduce.
So
I
can
possibly
I
can
definitely
add
some
more
detail
around
what
that
may
look
like
as
a
post
beyond
one
year
but
yeah
okay.
That
makes
sense.
Let
me
think
about
that,
a
bit
more
and
I'll
get
back
to
you
so.
F
But
the
team
would
need
to
go
over
that
it's
technically
feasible
in
the
current
paradigm,
something
like
sablier,
which
got
mentioned
in
the
sidebar.
That
would
involve
having
the
maker
up
front
so
yeah
like.
If,
if
the
goal
was
to
mint,
then
they
would
have
to
be
minted
up
front
and
then
put
into
the
stable
your
stream,
and
I
think,
there's
only
like
a
one-year
limit,
maybe
in
simulator.
So
there's
that
issue
as
well.
B
A
D
J
Can
maybe
mint,
if,
like
the
minting,
cannot
be
unlocked
until
the
until
we've
burned
a
certain
amount,
but
I'm
generally
very
anti-mint.
After
seeing
what
happened
with
wi-fi
and
like
they
correctly,
they
had
voted
to
burn
their
their
keys
to
mint
and
then
never
burned
them.
And
then
there
was
a
whole
discussion
about
minting
some
wi-fi
to
compensate
their
devs
and
do
all
sorts
of
necessary
things.
J
There
was
a
lot
of
pushback,
but
then
everyone
sort
of
was
like
well,
we
commit
for
ourselves
and
then
they
all
you
know,
voted
to
to
allow
a
mint
and
then
the
whole
distribution
got
all
screwed
up,
and
I
just
see
it.
I
think
like
having
that
button,
like
the
printer
button,
just
there
it's
very
tempting
and
can
just
lead
to
just
unintended
consequences
that
I
think
are
dangerous
and
I
think,
if
we're
gonna
allow
minting
like
we
need
to
have
very,
very
strict,
like
codified.
J
I
don't
know
how
to
be
codified
but
codified,
like
limits
on
how
it
could
be
minted.
So
if
it
may
forever
might
actually
be
sensible.
If
we
want
to,
I
mean
yeah,
I
I
I
really
am.
I'm
much
more
pro
like
taking
it
from
the
burn
if,
if
we
need
to
mint
ahead
of
time,
but
it
could
only
be
unlocked
like
once,
we've
burned
enough-
maybe
that's!
J
Okay,
I
don't
know
how
the
mechanics
would
work
but
yeah,
I'm
very
in
favor
of
like
hefty
compensation
packages
for
the
devs,
and
I
think
that,
like
significant
amounts
of
maker
should
be
allocated
for
them
to
to
retain
talent.
But
you
know
I'm
very
cautious
about
traveling
down
the
the
minting
path.
I
think
that
it's
a
very
slippery
slope
that
can
lead
to
unintended
problems.
E
F
Yeah
yeah,
so
one
of
the
concerns
that
we
had
about
that
is
just
the
the
fact
that
we
we
actually
aren't
renting
right
now,
right
we're
making
a
lot
of
money,
but
every
time
we
we
get
to
the
point
where
we're
burning.
We
we
raise
the
surplus
buffer,
which,
admittedly,
we
all
agree
we
need
to
do,
but
then
just
relying
on
on
actual
burns
to
start
reallocating
governance
weight
is
maybe
not
the
best
solution.
Now
now
the
system
is
already
like
configured
to
mint.
F
J
Yeah,
so
that
main
thing
I'm
fully
for
and
like
you
know
that
that
should
be
like
one
of
the
like
very
strict
cases
where
we
are
allowed
to
meant
to
bail
out
the
system
when
we're
under
collateralized,
and
we
did
that
you
know
by
thursday
and
that's
the
case
where
we
have
to
admit
right.
That's
a
very
like
concrete
example
of
what
it
being
necessary
right,
but
the
other
other
cases
for
minting
are
not
like
necessary,
necessarily
clear
that
we,
we
should
go
down
that
path.
J
Yeah,
I'm
for
minting
can
hear
me
yeah,
I'm
for
minting
for
bailing
out
the
protocol,
I'm
anti-minting
for
attracting
more
talent
and
all
those
you
know
other,
like
growth
sort
of
initiatives,
because
I
I
think
that
is
a
silvery
slope.
The
amazing
to
bail
out
the
system
is
like
a
necessary
feature
of
maker
but
main
thing
to
incentivize
it
can.
J
G
So
I'm
gonna
say
a
couple
of
things
here,
like
one.
We
can't
like
there's
basically
no
way
we
can
kind
of
lock
governance
out
of
minting
rights
likes
that
governance
kind
of
has
power
over
the
whole
thing.
It's
really
difficult
to
remove
that
power
like
in
a
way
that
governance
can't
undo.
In
fact,
it
might
just
be
impossible
other
than
just
like
actually
burning
it
and
making
it
permanent
right
like
so
so.
The
question
I
would
ask
is
like
consider
this
a
situation
where,
like
you
know,
some
some
bad
thing
happens
in
the
market.
G
Right
like
the
seventh
offer
gets
drained,
we
must
make
it
to
recapitalize
and
then,
at
the
end
of
the
month,
we
need
to
pay
core
units
because,
like
in
that
situation,
we
are
minting
maker
to
pay
core
units,
because
otherwise
the
entire
protocol
collapses
right,
because
there's
gonna
be
no
one
working
for
it
yeah.
So.
F
E
F
I
think
our
burner
like
we
can't
really
intercept
the
the
maker.
That's
going
into
that.
So
if
we
were
to
take
say
a
buy
back
and
distribute
principle,
we
would
either
be
like
taking
that
to
markets
and
probably
getting
front
run
by
everybody
that
that
sees
us
talking
about
it
and
going
there
or
we
would
say,
burn
five
maker
in
a
in
an
auction
and
then
we
would
immediately
invent
it
again
out
the
other
side
to
distribute,
so
that
could
be
able
to
enter.
D
Yeah,
so
so
the
only
downside
so
the
I
think
the
trade-off
right
of
between
like
mint
and
because
again
it's
not
a
downside.
It's
like
depends
on
your
perspective.
I
guess
right
so
with
the
mint.
You
are
very
competitive
for
compensation
right,
so
we
can.
We
can
essentially
say
to
somebody
you're
getting
this
absolute
amount
of
mkr
and
you're
you're
sort
of
incentive
aligned
with
that
amount
of
mkr.
It's
like
if
you
perform
poorly
over
that
number
of
years.
D
Your
mkr
goes
to
zero
and
if
you
perform
really
well
at
my
10x
and
all
of
us
wanted
the
10x
right
so
so,
you're
really
well
goal
aligned
and
your
mkr
doesn't
doesn't
change
based
on
the
performance
of
the
protocol.
If
we
siphon
off
of
of
the
burn,
then
you
know
in
four
years
like
we
may
just
be
getting
like
this,
like
pittance
of
a
trickle
like
one.
What
we
like
to
call
a
conti
of
mkr
right,
like
one
way
of
mkr
ends.
I
D
Being
your
your
distribution,
so
you
so
that's
the
sort
of
trade-off
right
is
and
then
how
competitive
is
that
against,
and
I
agree,
maybe
the
the
wi-fi
direction
is
was
not
great,
but
how
competitive
against
is
that
against,
like
a
series
of
protocols
that
are
just
willing
to
mint
tokens
to
compensate
devs
right?
So
that's.
I
think
what
we
need
to
take
under
consideration.
A
I
want
to
add
something
to
that
chris,
potentially
using
the
burning
function
is
going
to
so
you're
incentivizing
people
to
burn
a
lot,
so
maybe
they
will
say:
okay,
we
should
not
research
l2.
We
should
onboard
more
tokens
because
that's
what's
burning
more
so
we'll
receive
our
maker
compared
to
potentially
growing
it
more
in
the
long
term
and
suffer
from
the
from
the
vesting
during
those
months.
I
don't
know
if
we
want
that.
J
D
We
were
thinking
every
year
that
you
would
probably
reassess
what
the
compensation
or
the
like
incentive
compensation
portion
of
the
package
would
look
like
and
then,
if
not
a
tenth
of
a
percent,
it's
you
know
it's
less
and
less
and
less.
You
know
over
time,
but
hopefully
in
monetary
terms,
that's
still
like
enough
to
incentivize
people
to
join
that's
kind
of
how
you
go
now
right.
If
you're
just
a
series
a
to
a
series
c,
you
get
a
lot
right
up
front.
J
Actually,
one
of
the
questions,
the
foundation
treasury-
I
don't
know
if
this
is
open
for
people
to
discuss,
but
I
believe
there's
some
maker
left
in
there,
maybe
even
a
decent
chunk.
What
are
you
know?
What
are
the
plans
for
that
once
the
foundation
dissolves,
and
can
that
maker
be
used
as
an
incentive
for
you
know
developers?
E
B
I
I
think
you're
right
there
I
mean
we
can
all
see
on
etherscan
what
that
amount
is.
I
just
can't
remember
exactly,
but
I
I
mean
yes,
that
is
there.
I
don't
know
what
the
foundation's
going
to
do
with
that
they
they
will
have
to
reply
on
that
topic,
but
I
think
we
should,
regardless
of
that,
we
should
act
as
if
that
doesn't
exist,
because
what
we're
doing
is
longer
term
than
that
amount
of
mkr,
and
this
should
be,
you
know,
a
model
that
works
beyond
you
know.
G
E
E
J
Yeah
as
long
as
we're
not
inflating
with
the
with
the
minting
and
and
not
not
like
minting
more
than
we
are
burning
in
revenue
over
time.
Somehow,
and
if
we,
if
we
do
burn
the
entire
treasury,
then
I
mean
I
don't
see
why
we,
we
can't
mint
up
until
that
amount
and
you'd
reserve
that
for
similar
things
that
the
treasury
was
doing
with
it
before,
which
would
be
like.
F
Yeah,
I
don't
know
what
the
the
foundation's
intention
is,
and
I
can't
speak
on
behalf
of
the
foundation
with
regard
to
that,
like
from
our
perspective
like
if
the
foundation
were
to
donate
or
burn
some
amount
of
that
you
know,
I
think
we'd
be
fine
taking
that
out
of
this,
but,
as
derek
said
right
like
what
happens
in
the
future,
when,
when
that's
gone,
how
do
we?
How
do
we
continue
to
operate.
D
You
just
adjust
the
tenth
of
a
percent
number
downward
over
the
years
and
you
make
it
look
attractive
over
the
course
of
a
four-year
period,
and
I
think
that
we'll
be
able
to
move
forward
in
perpetuity
that
way.
Yeah
I
mean
there's
also
the
lots
of
companies.
Don't
just
give
you
one
grand
right,
like
you
end
up
with
like
grants,
and
then
you
kind
of
keep
that
rolling
and
that's
your
golden
handcuffs
right.
Nobody
wants
to
leave
because
they
lose
their
grants
so.
G
That
that's
actually
kind
of
interesting
when
we're
running
our
time,
so
apologies,
but
that's
kind
of
another
interesting
point
right
like
it's
assuming
you
have
like.
You
know
the
kind
of
100
of
future
science
like
makeup
protocols
where
they
want
to
be
right.
They
just
like
decide
that
this
is
it
and
then
like
after
four
years.
We
then
stop
rewarding
them,
even
though,
if
they're
planning
to
stay
for
like
ten
years,
I.
J
Commented
about,
but
I
think
that,
like
you
know
like
I'm,
I'm
not
opposed
to
like
a
vesting
schedule
that
could
be
like
endless.
I
guess
kind
of
like
the
grants
thing
you
mentioned
where,
like
you
know,
maybe
it
goes
on
some
admissions
curve
of
some
kind.
Where,
like
you
get,
you
know
less
each
year
you
know
adjusted
the
adjusted
down
but
like
something
to
continue
working
for
you
know
as
time
moves
forward.
C
Yeah
this
has
to
do
with
with
the
coordination
you
said
on
these
slides.
You
coordinated
with
the
other
groups.
Is
this
in
some
way
coordinated
with
the
oracle's
team,
because
after
you,
there
will
be
an
oracle
score
unit?
I
guess
and
me
as
a
community
member.
What
I?
What
I
really
don't
want
is
for
you
to
get
packaged,
abc
something
and
then
the
oracle
teams
come
out
with
their
proposal
and
what
they,
what
they
propose,
tops
everything
you
got
and
that's
not
gonna
be
optimal.
B
Oh
well,
so
we've
we've
discussed
it
at
a
high
level.
I
mean
everyone
is
aware,
and
everyone's
looking
at
this
team
to
sort
of
start
the
discussion
on
what
does
this
look
like
going
forward?
I
I
don't,
have
a
model
for
what
the
framework
overall
looks
like
so
in.
In
short,
I
mean
that
discussion
still
has
to
happen.
We
we
know
that
the
oracle's
team
are
going
to
have
a
very
high
cost,
due
to
maintaining
the
oracles
going
forward
so
yeah.
G
That
comes
along
and
says
like
we
want
more
or
we
want
less
and
then
like
one
year
one
year
and
a
half
down
the
line,
they're
feeling
either
or
someone
is
feeling
dissatisfied
with
the
amount
of
investing
they're
getting
in
comparison
to
some
to
others,
some
other
core
team
and
to
some
extent
right.
That's
that's
going
to
be
unavoidable
but,
like
I
feel
like,
maybe
if
we
have
some
sort
of
more
global
or
like
sort
of
kind
of
system
or
like
setup
that
kind
of
covers
multiple
teams,
maybe
that's
beneficial
yeah.
F
G
B
A
So
there's
a
frozen
period
of
two
weeks
in
which
you
shouldn't
make
any
changes
to
the
content.
You
can
kind
of
like
clarify
it
or
make
it
and
before
that,
the
whole
thing
should
be
one
month
so
not
before,
but
it
could
overlap.
It
should
be
one
month
in
rfc,
so
potentially
you
could
formally
submit
it
one
month
after
the
rfc
submission.
G
I'd
like
the
the
regular
budget,
passing
it's
kind
of
tricky,
because
I
I
you
know,
I
don't
know
how
long
it's
going
to
take
the
dow
to
figure
out
some
more
global
thing.
So
and
obviously
I
don't
want
to
kind
of
string
you
guys
along
or
like
that
artistic
you
guys
along
so
yeah.
I
don't
know,
there's
some
options.
We
maybe
need
to
discuss
yeah.
I
don't
know
what
makes
no
sense
off
the
top.
E
A
H
A
H
H
Okay,
that
that
one
yeah
so
the
yeah
I
work
closely
with
the
token
engineering
community,
which
is
kind
of
an
emerging
discipline
that
combines
game
theory
and
mechanism,
design
and
economics
and
systems
engineering
principles.
Cyber
physical
systems
to
design
more
robust
protocols
because
of
the
fact
that,
especially
with
all
of
these
composability
issues,
there's
a
lot
of
emergent
behaviors
and
dynamics
in
the
network.
H
D
One
word
to
bring
up:
oh
you
guys
cut
out
of
me
nice
yeah,
it's
you
know.
Basically,
I
I
just
wanted
to
make
sure
it
was
sort
of
clear
to
everybody
that
we're
our
team
is
hoping
to
act
autonomously
when
it
comes
to
sort
of
hiring
and
firing
and
we're
hoping
to
you
know,
sort
of
allow
people
a
bit
of
an
anonymity
shield
on
their
like
personal
finances
and
and
whatnot,
and
so
we're
hoping
that,
like
this
sort
of
team,
satisfaction
and
dissatisfaction,
can
be
expressed.
D
D
I
I
actually
didn't
get
this
far
in
the
discussion,
but
I
I
you
know,
I
wasn't
sure
if
people
were
like
starting
to
dig
down
and
and
like
look
into
individuals
on
the
team
and
that
that
makes
my
heart
my
job
really
hard
to
do,
trying
to
like
find
people
and
sell
them
on
this
idea
of
you
know
working
for
a
dow.
I
don't
think
anybody
wants
to
be
under
the
microscope
of
like
an
entire
dao
when
their
compensation
is
either
for
safety
reasons
or
other
reasons.
D
H
E
B
So,
with
regards
to
the
the
technical
side
of
it
chris
and
others
I'll,
let
you
guys
answer
that,
but
with
regards
to
the
prioritization
of
that
work,
I
think
this
is
where
we
start
having
a
really
really
interesting
discussion
with
the
community
going
here
are
all
the
things:
let's,
let's
line
them
up.
Let's
talk
about
the
value:
let's
see
what
opportunity
is
it
going
to
give
us
as
a
protocol,
and
what
does
that
mean
for
dye?
B
What
does
that
mean
for
protocol
security?
What
does
that
mean
for
runoff
risks
to
other
parts
of
the
protocol
and
and
then
stand
them
all
up
and
see
what
makes
the
most
sense
so
so
yeah?
In
short,
I
think
that's
a
really
interesting
prioritization
exercise
that
I
can't
wait
to
get
into,
but
it'll
have
to
stand
up
against
everything
else.
We
have
on
the
board
from
a
technical
perspective
chris
and
brian
others
I'll.
Let
you
guys
take
that
bit.
D
Yeah,
I
I
mean
I
can
I
can
say
like
from
a
technical
perspective,
like
almost
everybody
on
the
team,
probably
learned
solidity
sometime
in
the
last
three
years.
I
think
good
engineers
are
adaptable
and
and
can
learn
different
languages.
I
myself
started
out
in
c
doing
kernel
programming,
I've
gone
through
c
c,
plus
plus,
like
you
know,
all
the
way
up
into
the
higher
level
languages.
D
At
this
point
I
probably
know
more
programming
languages
than
I
don't
know,
programming
languages,
so
you
know
we
will
have
to
like
learn
these
things
as
they
come
up.
The
downside
right
now
is
obviously
like
when
we're
super
flat
out
and
working
very
hard
on
on
these
projects.
There's
almost
no
time
for
like
r
d
and
learning
new
things,
and
and
that's
the
situation
we
want
to
move
our
dev
team
away
from.
I
Yeah,
I
mean
I'll
just
say
I
think
you
know
adaptability
and
the
ability
to
keep
learning
new
things
is.
You
know
one
of
the
hallmark
requirements
for
being
a
competent
dev
at
all,
because
if
you
don't
keep
learning
everything
in
software
moves
so
fast,
you
just
get
left
behind
anyway.
So
you
know,
continuous
learning
and
improvement
is
like
a
core
part
of
the
software
engineer.
Skill
set.
A
A
That's
good
big
thanks
to
the
rest
of
the
smart
contracts
team
for
coming
and
answering
all
our
questions
and
yeah
this
friday.
We
have
sebastian
dario
doing
real
world
finance,
that's
going
well,
it's
actually!
The
vote
is
happening
right
now.
I
believe
it
finishes
on
monday
next
wednesday
we'll
have
seth
that
will
present
content
production,
so
very
interesting.
Core
units
presentations
coming
up
so
yeah
keep
tuned
and
let's
keep
the
discussion
going
in
the
forum.