►
Description
Know Your MIP #04: Keg Streaming Payments Module
@prose11: Going over the non-technical elements of Keg Payments MIP - MIPX: Streaming Payments via the Keg
@hexonaut: Explaining the technical details of MIP34 - Keg Streaming Payments Module
Agenda and Discussion:
https://forum.makerdao.com/t/know-your-mip-04-keg-streaming-payments-module-friday-february-5th-18-00-utc/6237
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
Starting
again
welcome
everyone,
we
are
doing
the
know.
Your
mip
number,
four,
that's
focused
on
the
keg,
so
we're
gonna
start
with
the
wonderful
peyton
who
is
going
to
give
us
the
non-technical
mip
overview,
and
so
that
will
kind
of
fill
in
at
a
high
level
for
for
everyone,
and
then
we'll
also
dig
into
the
technicals
with
sam,
who
also
submitted
a
technical
mip.
That
is
now
an
rfc
right.
A
C
A
C
C
C
It
is
sam
set
it
up,
so
it
can
actually
pull
from
two
distinct
funding
sources.
One
is
kind
of
our
our
general
spending
right,
the
the
surplus
buffer.
Typically,
when
people
propose
new
projects,
implementations
anything
like
that,
it's
generally
funded
through
the
surplus
buffer,
especially
as
we
move
away
from
foundation
funding
like
that'll
kind
of
be
the
main
go-to,
but
it's
also
built
in
a
way
that
can
redirect
funds
that
were
otherwise
going
to
the
flapper,
which
is
the
our
surplus
auction
method.
C
So
the
the
two
mips,
I'm
pretty
sure
mine
still
doesn't
have
a
number.
So
it's
still
listed
as
like
mipx
funding
for
the
keg
and
then
sam
smith.
I
believe
that
one's
34.
is
that
right,
yeah
34.
awesome.
I
don't
know
why
I
didn't
put
the
numbers
in
sorry
but
we'll
we
can
link
those
in
the
chat
here
so
kind
of
overview-wise
on
on
why
you'd
want
to
utilize
the
keg,
because
I
mean
right
now
you
can
just
code
payments
into
the
executive
spell
right.
C
We
could
say:
hey:
we
want
to
pay
this
many
people,
let's
vote
on
it
and
then
we'll
send
it
out
once
once
that
vote
passes,
a
number
of
the
things
we're
doing
are
reoccurring.
Right,
like
we
might
say,
hey,
we
need,
I
don't
know,
ten
thousand
die
for
this
cause
right
now
and
another
month,
we'll
probably
need
10
or
maybe
15
000.
It's
it's
hard
to
say.
C
C
But
basically,
that
would
be
one
that
we
might
want
to
utilize
funding
otherwise
going
to
the
flapper,
because,
basically,
those
are
those
are
kind
of
our
profits
right.
It's
it's
money
that
the
surplus
buffer
is
is
full
and
we're
directing
money
into
buy
and
burn.
This
would
allow
us
to
carve
out
a
little
bit
for
governance
rewards.
C
This
is
one
that
would
utilize
the
surplus
buffer
right,
just
a
set
amount
of
funding
like
say,
hey,
we're
applying
for
this
amount
of
funds
per
quarter
for
this
core
unit.
Currently,
I
know
we
have
risk
governance,
a
few
other
ones
that
have
been
posted,
but
basically
they're.
A
lot
of
them
are
looking
at
the
neighborhood
of
like
65
70
000
die
a
month
so
having
the
ability
to
just
say
all
right.
Governance
approves
this.
C
The
community
wants
to
fund
this
project,
let's
turn
on
the
spout
and
and
keep
them
funded
until
we
either
decide
they're,
not
using
the
money
right
or
they
say,
they're
going
to
need
even
more
so
it
really
does
kind
of
cut
down
on
that
common
complaint
in
the
forum.
You
know,
I
think
we
saw
this
when
sam
put
on
a
signal
request
for
the
initial
hundred
thousand
died
to
be
used
for
the
the
multi-sig
and
interim
multi-sig
wallet.
You
know
some
of
the
comments
on
there
was
like
hey.
C
The
keg
is
a
great
way
to
to
kind
of
solve
that
problem
so
definitely
want
to
give
people
a
chance
to
like
read
the
non-technical
myth.
There's
a
lot
of
stuff
in
there
that
that
might
help
further
explain,
but
basically
I
tried
to
break
it
out
in
a
way
that
just
made
sure
you
needed
to
know
and
understand
these
three.
C
These
three
key
terms
when,
when
applying
for
it,
like
I
said,
sam's
gonna,
go
over
the
actual
contract
implications
after
this,
but
by
just
breaking
it
down
into
flight
rate
and
flow.
This
will
make
it.
So,
even
if
you're
not
familiar
with
smart
contracts,
you
can
understand
what
these
three
are
and
you
could
apply
for
keg
funding
for
a
specific
source.
C
C
C
Obviously,
some
math
there,
if
you're,
if
you're
doing
allocations
per
year,
but
not
too
hard
to
break
down
the
other
key
term,
is
called
flow
and
that's
basically
going
to
be
when
you're
applying
for
an
allocation
of
funds
that
that
are
essentially
profits.
Right
that
are
essentially
otherwise
going
to
the
buy
and
burn
mechanics
flow,
takes
a
certain
percentage
of
that
and
and
sets
it
aside.
C
So
sam
will
get
into
kind
of
the
technical
ways
it
it
does,
that
there
are
a
few
tricky
spots
and
that
there
can
only
be
one
particular
stream
pulling
from
from
the
flapper
funds
there,
but
basically
we
can
set
it
up.
So
then
that
stream
is
then
split
into
further
streams
and
and
fixes
many
problems
there.
C
D
B
C
D
A
A
B
Yeah
you
you
pretty
much
nailed
it
amy,
so
yeah.
I
view
it
the
same
way
you
shouldn't
you
shouldn't
view
this
as
something
to
go
to
every
individual
contributor,
it's
sort
of
just
a
router
to
pull
funds
out
of
the
maker
protocol
and
give
it
to
this
sort
of
top
level,
core
units
or
gov,
rewards
or
whatever,
and
then
they'll
further
distribute
to
developers
or
whatever,
depending
on
what
the
core
unit
is
taken.
Care
of.
C
Yeah-
and
this
definitely
took
me
a
while
to
like
going
back
and
forth
with
long
basically
asking
like
all
right,
so
what
would
we
you
know
what
would
make
sense
to
allocate
this
for,
and
they
are
things
that
like
are
either
going
to
be
split
up
to
a
bunch
of
people
and
and
particularly
funding
over
time
right.
So
that
would
be
the
other
thing
if
you're,
just
making
a
grant
allocation
of
like
five
thousand
die,
probably
not
a
lot
of
reason
not
to
just
go
through
the
standard
spell
there.
B
I'll
say
even
even
at
the
level
of
individual
grants,
as
amy
said
like
this
should
be
sort
of
a
grants
core
unit
or
something
that's
assessing
this
at
a
at
a
layer
of
abstraction
between
the
keg
or
the
manual
that
suck
that
that
should
be
kind
of
removed
from
the
end
person
who's.
Getting
the
grant
like,
we
should
be
dealing
in
sort
of
larger
amounts
of
capital.
Moving
to
the
big
big
units.
C
C
C
Yeah,
I
would
just
say
that
I
did
like
I
broke
it
down
to
like
three
things.
I
thought
you
need
to
know
in
terms
of
like
terms
within
the
funding
for
applying
like
that
was
my
approach
for
for
crafting
the
the
non-technical
mip.
There
are
a
lot
more
other
codes
and
specifications
and
ways
this
gets
done
in
sam's
contract
that
either
a
I
didn't
understand
or
be
I
felt
like
would
be
too
much
for
for
an
average
person,
maybe
applying
for
a
funding
source
to
have
to
go
through,
but.
B
C
B
B
C
Sorry,
sam
so
yeah
that
was
just
for
applying
for
for
actually
using
the
keg
one
misconception
I
had
that
long
had
to
clear
for
me:
is
that
the
frozen
period
and
the
rfc,
those
those
can
overlap
right.
So,
if
you
aren't
making
any
changes
in
the
last
two
weeks,
it
would
just
be
like
a
six
week
hold
for
for
applying.
C
But
basically
that's
so
you
can
post
your
post
your
proposal
for
funding
to
the
forum
and
have
plenty
of
time
for
people
to
engage
with
it
like
maybe
they
might
say,
hey
this
isn't
ideal
for
the
keg
or
hey
I.
You
know
we
have
concerns
about
this
money,
so
so
it's
basically
to
give
enough
time
for
both
the
community
to
interact
with
the
proposal
and
for
the
mandated
actors
to
to
take
a
look
at
it.
C
E
E
C
Yeah,
so
there
is
going
to
be
some
interlab
there
that
we're
probably
going
to
need
some
some
feedback
feedback
on,
but
basically
like.
If
you
have
a
budget,
ideally
it
would
be
very
you
know
we
should
make
it
very
easy
to
say:
okay,
that
works
for
the
the
keg.
Let's
flip
it
on
and
use
the
keg
for
implementation.
C
But
basically
the
idea
is
that
we
don't
know
how
each
core
unit
is
going
to
propose
their
budgets,
so
making
it
have
to
go
through.
The
keg
would
would
seem
like
possibly
something
that
could
mess
up
a
few
things,
but
for
a
lot
of
things
they
probably
will
want
to
use
the
keg.
So
I
I
don't
know
it
might
make
sense
to
add
a
little
sub
unit
or
note
on
to
the
mip
itself
clarifying
that
if
you
do
request
continual
funding,
it
will
go
to
the
keg.
B
So
you
can
definitely
do
that,
but
I
don't
know
if
you
want
to
do
that
right,
like
wait.
Having
an
executive
where
maker
voters
could
potentially
vote
you
down
month
to
month
is
is
not
really
a
way
to
do
business.
There
has
to
be
kind
of
this
ongoing
trust
and,
like
I
don't
think,
it's
really
conducive
to
have
to
like
do
some
work
and
then,
at
the
end
of
the
month,
submitted
invoice
to
governance
and
have
them
be
like
oh
nope,
we're
not
paying
for
this
like
okay.
D
B
So
that's
kind
of
a
separate
process.
I
mean
if
we
start
sucking
more
out
of
the
surplus
buffer
than
we're
making,
we
will
take
losses
and
if
the
surplus
buffer
runs
dry,
we
will
eventually
have
to
start
minting
maker.
But-
and
you
know
maybe
there's
like
austerity-
you
can
do
to
the
teams
or
something
because
of
the
lack
of
revenue.
But
like
yeah
I
mean
you
can
continue
pulling
funds
out
of
the
surf
plus
buffer
as
much
as
you
want
in
theory,
no
matter
what
we'll
just
start
minting
maker.
C
B
What's
your
question,
amy,
okay,
so
did
you
read
correctly
that
anyone
can
send
money
to
a
keg,
not
just
maker
governance?
Yes,
yes,
so
the
keg
is
essentially
just
a
router
it.
It
just
takes
payments
in
from
whatever
source,
erc20
transfer
and
then
routes
it
to
a
bunch
of
endpoints.
So
really
it's
not
even
the
keg
itself
is
not
really
specific
to
even
maker.
It's
just
generalized
payment
routing
thing.
E
Has
there
been
any
discussion,
so
austerity
came
up,
but
I
thought
that
was
I
smiled
a
bit,
but
it's
actually
it
could
be
a
likely
scenario.
So
if,
if
if
a
budget
is
tied
to
a
core
unit
and
there's
been
some
agreement
on
that
and
then
if
the
surplus
buffer
runs
low
and
some
sort
of
austerity
needs
to
be
applied,
is
there
any
been
any
discussion
on
that
and
how
that
would
happen?.
B
C
Yeah-
and
I
tried
to
keep
that
in
mind
in
terms
of
the
stopping
payments
section
of
the
non-technical
keg,
which
would
standard
have
like
a
delay
but
did
clarify
that,
like
in
an
urgent
or
emergency
situation,
the
facilitators
might
might
deem
that
a
signal
request,
like
with
a
short
duration,
is
an
appropriate
action
to
take
to
pull
the
community.
So
in
theory,
we
could
be
shutting
it
off
pretty
quickly
like
in
a
week
or
two.
If
we
saw
something
coming
up
on
the
time
horizon,.
E
E
C
Yeah
and
ultimately,
I
guess
I'd
want
to
add
that
this
is
just
a
tool
right,
so
we
tried
to
envision
a
lot
of
different
ways.
This
could
play
out
both
positive
and
negative,
but
there
are
undoubtedly
utilizations
that
we
haven't
thought
about
for
it,
yet
so,
hopefully,
by
leaving
it
as
open
as
possible.
That
means
that
any
neat
ideas
for
for
funding
or
otherwise
could
could
come
through
this
and
and
happen
pretty
quickly.
H
B
Yeah,
so
flights
are
basically
just
a
string
that,
like
you,
can
I
tag
basically
where
you're
sending
the
money
to
at
sort
of
a
human
level.
So
it
can
be
something
like
I
don't
know.
Smart
contracts
core
unit,
just
literally
call
it
that
and
then
there's
end
addresses
for
that.
Maybe
it's
just
one
address,
that's
fine
and
they
get
100
of
the
money
flowing
through
that
that
route,
but
yeah
those
are
registered
by
governance
through
the
normal
spell
process.
I
Oh,
what's
the
current
idea
for
the
best
way
to
do
it?
Should
there
be
streams
towards
individual
contributors,
or
should
it
all
just
go
to
one
address
and
then
that
one
address,
whether
it's
controlled
by
a
single
facilitator
or
some
multi-sig,
then
distribute
it
according
to
the
budget
kind
of
at
their
own
discretion?
B
Yeah,
I
mean,
I
think,
it's
probably
easier
to
go
with
stream
the
funds
to
a
multi-sig
or
something
for
the
core
unit
or
some
sort
of
like
high
level
structure
that
can
then
further
send
the
payments
out
to
all
the
contributors
and
stuff
like
that,
and
they
can
use
whatever
payment
mechanism
they
want.
So
the
keg's
not
really
meant
to
be
completely
arbitrary
payment
distribution
to
the
last
person,
it's
sort
of
just
the
very
high
level
routing
tool
for
yeah.
I
And
so,
like
the
other
day,
there
was
a
presentation
from
a
company
called
accountable,
so
they
would
be
a
service
provider
to
core
units
that
wanted
to
offer
like
fiat
payments
and
like
kind
of
a
more
traditional
range
of
benefits
for
their
employees
and
the
idea.
I
think
the
way
that
it
worked
was
that
the
payment
would
go
straight
to
them,
and
then
they
would
do
all
of
that.
I
B
B
I
Okay
got
it
yeah.
I
was
just
thinking
because
I
I
don't
know
if,
like
a
countable
or
another,
similar
company
would
want
like
a
upfront
or
like
some
sort
of
deposit
like
depository
level
like
deposit
for
service.
Basically,
and
that's
what
I'm
kind
of
interested
in,
because
if
it's
streaming,
then
it
might
not
be
ideal
for
that
service
provider.
B
C
And
yeah,
I
guess
I'll,
add
that
the
goal
is
for
for
this
to
be
on
for
the
the
march
governance
cycle.
So
if
you
do
have
any
ideas,
questions
like
things
for
improvement
for,
for
the
mips
at
least
the
non-technical
one
in
particular,
since
that
was
the
one
I
worked
on,
please
please
throw
them
up
in
the
forum
or
feel
free
to
ask
here.
Do
you
want
to
make
that
as
as
good
as
possible
before
we
we
end
up
voting
on
it,
so.
D
D
A
So
operational
support,
like
one
of
the
things
that
we
were
talking
about,
was
collecting
resources,
so
we
are
doing
some.
You
know
due
diligence
before
we
actually
even
suggest
it,
but
at
the
same
time
you
know
everyone
should
do
their
own
due
diligence
for
sure
what
we
can
do
is
provide
a
list
of
options.
I
do
think
it
kind
of
depends
on
what
your
need
is,
so
some
people
might
prefer
opolis
because
they
can
they
work
in
the
u.s
and
they
want
to
be
able
to
move
employer
to
employer.
A
I
think
of
with
dennis's
kind
of
company
accountable.
Theirs
is
more
servicing
the
employer,
so
apple's,
like,
I
think,
of
uplift
as
an
employee,
and
so
we
can
have
like
an
endless.
You
know
resource
list
of
all
these
for
sure,
but
I
I
did
chat
with
them
and
I
it
also
varies
like
what
the
ask
is,
because
they
are
they
on
their
side.
They
will
also
do
a
risk
assessment
so
assessing
whether
because
you're
signing
with
them
themselves,
it's
a
little
bit
sorry
off
topic.
D
A
A
A
B
Yeah,
so
I
guess
the
initial
use
case
I
had
for
that
is
the
dss
gov
rewards.
That
seems
like
a
prime
candidate
for
where
to
route
profits,
but
yeah,
as
you
say,
git
coin
grant
seems
like
another
place
where
we
have
profits
available.
You
know
cycling
back
into
the
whole
ecosystem
a
little
bit.
I
don't
know
really
it's
up
to
governance.
C
I
used
one
kind
of
cool
comment
I
could
add
to
what
I
was.
Writing
is
long
did
use
the
example
of
like
the
strategic
reserves
that
I
tried
to
poorly
walk
through
in
my
presentation,
and
I
just
thought
that
was
like
a
very
neat
use
case
in
that
it
would
allow
us
to
say
all
right,
we're
going
to
take
this
percentage
of
of
profits
of
our
of
our
extra
die
and
we're
going
to
basically
build
a
build
kind
of
an
asset
buffer
to
help
us
keep
through
through
bad
times.
C
C
H
A
G
Well,
yeah,
so
definitely
and
and
sam
sounds
a
part
of
that
conversation
as
well.
We
we're
thinking
of
streaming,
yes,
how
we
model
that,
specifically
to
a
multi-sig,
we
still
have
to
discuss
and
figure
out
that
operational
model,
but
yeah
exactly
what
sam
and
payton
have
talked
through,
as
is
what
we're
thinking
of
at
the.
G
G
I
got
one
I
was
thinking
about
earlier
today
and
samantha
you
and
also
david
touched
on
it
just
now
talking
about
so
the
the
streaming
function
of
the
keg
is
designed
to
stream,
to,
let's
say
a
core
unit
multisig,
for
example,
not
necessarily
to
individuals.
What
would
be
the
complexity,
because
I'm
sure
people
would
in
fact
like
to
be
paid
at
a
streaming
rate
from
a
multi-sig.
G
B
Yeah
so
the
keg's
designed
to
be
sort
of
generalized
coming
out
of
maker,
basically,
but
we
can
totally
plug
it
into,
and
I
think
this
is
totally
the
domain
of
a
third-party
service
where
we
don't
need
to
build
an
entire
payment
routing
system.
These
exist
all
over
the
place.
So
I
think
we
just
tap
into
some
third
party
that
accepts
erc20
transfers.
B
A
C
And
yeah
also,
I
mean
correct
me
if
I'm
wrong
sam,
but
the
it's
not
that
the
the
keg
couldn't
stream
to
individual
addresses.
It's
just
that
for
various
reasons.
You
may
not
want
to
do
that
right
in
case
someone
leaves
or
walks
away
or
that
sort
of
thing,
but
it's
designed
to
just
split
up
between
the
addresses.
So
if
you
did
want
to
pay
people
directly
through
that
there,
you
could
do
that.
It
would
just
be
kind
of
a
judgment
call
and
if,
if
that's
the
best
way
to
distribute
funds
or
not.
B
Yeah,
that
would
be
more
just.
I
view
that
as
too
much
overhead
for
governance,
they
shouldn't
be
dealing
with,
because
every
one
of
these
payment
routes
you
set
up,
you
have
to
go
through
a
spell,
and
governance
should
not
be
dealing
with.
You
know
payment
to
somebody
doing
like
a
thousand
bucks
of
work
on
a
one-off
situation
like
that
shouldn't
be
like
something:
governance
deals.
B
A
B
A
B
C
So
david
had
a
good
question:
chad
he
was
asking
if
the
keg
has
a
bandwidth
for
like
a
max
number
of
streams,
it's
my
understanding
that
you
can
basically
do
as
many
flights
as
you
want
to
the
the
only
limitation
is
on
the
actual
flap
tap
the
the
tapping
of
the
funds
going
to
to
the
flapper.
Otherwise,
if
that's
correct
sam.
B
Yeah,
there's
no
limit
to
the
number
of
routes
you
can
set
up,
but
each
route
does
have
a
limit
on
the
number
of
ways
it
can
split
out.
So,
like
you
want
a
reasonable
number,
like
maybe
one
or
two
or
three
n
targets
per
route.
If
you
I
don't
know
what
the
exact
limit
is.
It'll
hit
the
gas
limit
at
some
point
but
yeah.
Basically,
you
don't
want
to
do
a
single
payment
that
can
fan
out
too
much
it'll
just
cause
too
much
gas.
C
B
C
I
was
gonna
say
same
thing,
I
I
don't
quite
understand
the
code,
but
from
what
I've
looked
at
and
what
everyone
has
talked
to
like
it's.
It's
just
awesome.
It's
just
a
really
great
tool
that
that
truly
gives
the
power
to
to
the
community
to
decide
how
it's
used
and
can
be
used
in
a
number
of
ways
that
just
kind
of
like
ideologically
we
may
want
to
take
advantage
of
that
that
are
to
our
own
benefit
in
terms
of
minimizing
government
governance,
actions
and
stuff.
Like
that.
B
Yeah,
so
the
keg
itself
sits
outside
of
the
maker
protocol,
the
tap
that
which
pulls
from
the
surplus
buffer
at
a
regular
rate
that
one's
pretty
safe.
But
there
is
another
contract
called
the
flap
tap,
which
does
need
to
insert
itself
between
the
surplus
buffer
and
the
flapper
which
require
yeah.
As
I
said
in
the
thing,
it
requires
modifying
some
code-
it's
not
horribly
complex
to
analyze,
but
it
will
require
more
scrutiny
than
the
other
stuff
for
sure
and
yeah.
C
F
C
F
C
A
All
right
well,
thank
you
so
much
peyton
sam!
This
was
really
cool
and
it's
a
crazy
crypto
world
that
we
live
in.
So
it's
yeah.
I
was
just
like
caught
off
guard
when
I
was
just
thinking
about
the
sablier
and
how
we're
just
doing
all
this
so
magic
money
for
sure
all
right.
Well,
thank
you
for
everyone
who
also
came,
and
if
you
have
any
questions
we'll
be
posting.