►
Description
EIP-173: https://eips.ethereum.org/EIPS/eip-173
Last call PR: https://github.com/ethereum/EIPs/pull/2832
Follow Nick Mudge at Github & Twitter @mudgen
Contact Ethereum Cat Herders
Discord: https://discord.gg/sgdnxZe
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders/PM
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
If you are planning to submit a proposal, we highly recommend reading EIP-1 and watching our first episode on "Writing an EIP" with Matt Garnett (@lightclient).
A
A
Its
review
period
has
ended
recently
and
there
is
an
open
for
request.
If
you
go
to
eib
github
repo,
you
can
find
it
there.
It's
2832
link
will
be
provided
in
the
description
below
to
provide
an
overview
of
the
protocol
and,
let
us
know
the
real
world
implementation
we
have
nick
march
today.
Some
of
you
may
know
him
by
the
name
of
martin
he's
getting
a
handle.
A
B
B
It
made
sense
to
make
that
into
a
standard
so
that
it
was
defined
and
people
could
could
expect
it
and
people
creating
user
interfaces
or
other
things
that
dealt
with
contracts
could
could
use
it
and
rely
on
it,
and
so
that
that
was
actually
mail.
Quite
a
while
ago,
I
I
see
a
I
found
a
post
on
the
internet
by
dan
finlay,
who
originally
proposed
the
idea
that
that
there
be
a
a
standard
for
for
owning
contracts
and
he
wrote
about
it
and
then
later
in
2018.
A
That's
pretty
interesting,
like
I
see
the
history
says
that
it
took
about
almost
about
four
years,
so
one
more
thing
I
missed
out
to
introduce
william,
he
is
also
from
catalyst,
team
and
yeah.
We
would
like
to
know
more
about
this
protocol,
since
we
see
that
it
took
about
four
years
to
you
know
get
across
here.
How
do
you
think
like?
Why
did
it
take
so
long.
B
All
right
so
you're
asking
me
why
it
took
so
long
yeah.
You
know,
I
think
it's
mostly
took
so
long
because
the
the
writers
of
the
standard
which
is
really
meet
myself
and
dan.
We
just
didn't,
keep
working
on
it
or
pushing
on
it
or
doing
anything
about
it
for
a
long
time.
It
doesn't
take
years
for
an
eip
to
move
from
draft
to
final.
B
You
know
unless
the
authors
of
it
have
dropped
it
or
you
know,
haven't
done
anything
about
it
a
long
time,
and
so
we
that's
that's
the
case
for
us.
We
just
got
involved
with
other
things,
and
you
know,
and
then,
but
not
that
long
ago
I
thought
it
would
you
know
it?
Would
it
made
sense
to
let's
just
push
it
through
to
final,
because
it's
this
pattern
is
being
used.
B
Many
places
anywhere
open,
zeppelin
contracts
are
being
used
where
they,
where
ownable
is
being
used,
it's
being
used.
So
so,
why
not
make
it
final
and
there's
a
lot
of
eips
that
are
in
draft
status?
And
so
I
think
it's
good
for
the
eips
in
general
to
have
like
completed
eips
that
are
in
final
status
and
I
think
that's
good
for
the
ethereum
community
to
have
that.
So
I
thought
well,
I
had
a
little
bit
of
time,
so
I
thought
I'd
push
it
through
and
so
that's
what's
happened
recently.
A
That's
really
commendable.
Actually,
one
of
the
ideas
behind
starting
this
series
is
also,
though,
that,
like
we
see,
hundreds
of
eips
are
pending
in
draft
status,
we
would
want
them
either
to
be
final,
get
into
the
state
of
final
or
if
they
are
no
more
of
use,
we
can
actually
mention
it
as
supersede
or
close
the
pull
request.
So
that's
really
nice
of
you
to
actually
come
back
and
start
pushing
it
through.
C
Yeah
is
there
some
need
that
you
saw
now
that
made
you
really
come
back
and
say
like
we
really
need
to
get
a
vulnerable
ownable
unit
wow.
I
tripped
over
myself
there
an
ownable
interface
standard
out
there,
or
is
it
always
just
sort
of
been
the
same
need,
and
you
finally
got
time
back
around
to
it
now.
B
Yeah,
I
think
it's
it's
been
the
the
the
same
need
as
as
always-
and
you
know
there
wasn't
really
anything
new.
I
just
thought
you
know
it
would
be
good
to
finalize
it.
You
know,
or
you
know,
I
don't
think
it
makes
for
this
standard.
It's
used
so
much.
You
know,
I
think
open
zeppelin's
contracts
are
used
a
lot
and,
and
so
it
makes
sense
to
remove
it
so
so
yeah.
I
just.
B
I
think
that
for
at
least
one,
what
I've
seen
on
ethereum
that
as
far
as
standards
go
like,
sometimes
people
will
use
patterns
and
contracts
and
there
might
not
be
like
an
official
standard
written
for
it,
but
it's
just
a
pattern
that
gets
adopted,
and
so
it's
like
a
standard
whether
or
not
it's
written
or
in
final
stat.
You
know
these.
B
These
real
standards
are
there
there's
their
standard
because
people
are
are
are
are
doing
it,
but
I
think
it's
a
good
thing
to
have
official
standards,
so
people
can
be
certain
about
the
right
ways
to
do
things
and
and
and
and
also
to
to
give
them
make
them
more
confident
that
things
aren't
going
to
change
on
them.
That,
like
you,
know
how
to
do
something,
isn't
going
to
be
different
later
and
and
trip
them
up
in
some
way.
C
I'm
actually
really
glad
that
you
brought
it
up
that
way.
I
think
you
have
answered
the
next
question
I
was
going
to
ask,
but
I
might
I
might
ask
it
anyway,
maybe
just
to
get
the
other
half,
which
is
that
there
is
a
pattern
that
we
see
very
often
in
smart
contract
development
of
just
using
a
modifier
for
only
owner
or
something
of
that
sort
is
there?
Do
you
see
an
advantage
of
using
the
interface
as
opposed
to
using
that
sort
of
common
development
development
pattern?.
B
C
Definitely
I
I
suppose
I
mean
do
you
intend
for
people
to
have
to
taking
a
look
at
the
eip.
It
could
be
that
I
misunderstood
myself.
I
was
under
the
impression
that
we
were
looking
for
with
interface,
is
to
come
up
with
an
ownable
interface
and
then
have
contracts
inherit
that
that
they'll
make
themselves,
and
I
guess
the
same
way
that
we
probably
use
it
opens
up
one
contract
and
then
say,
like
you
know,
my
contract
is
ownable.
B
I
see
people
inheriting
and
just
or
just
writing
it
and
I've
seen
I've
seen
both
ways
so
yeah
I
it's
also
you
know
even
adding
a
modifier
like
an
optional
modifier
or
even
mentioning
that
into
in
the
standard
that
it's
common
for
people
to
use
a
modifier.
Okay,
maybe
that
maybe
there's
something
to
add
there.
C
Okay,
I
understand
that
that
actually
helps
me
understand
it
a
bit
better
than
I
had
before.
I
thought
that
you
were
specifically
going
for
interface
like
the
the
sort
of
inheritable
interface
kind
of
kind
of
pattern.
That's
interesting!
I'm
thinking,
maybe,
depending
on
what
you
think
puja.
Maybe
we
should
actually
zoom
out
for
a
second
and
even
talk
about
why
contracts
need
to
be
ownable.
A
B
Oh
yeah
sure
so
in
the
in
the
in
the
comments
and
discussion
for
this
for
the
standard,
so
another
developer
nick
had
suggested
well,
you
could
use
ens
for
owning
contracts,
and
so
so
so
I
looked
at
that
and
considered
that
and
other
people
did
too,
and
you
know,
but
I
think
I
just
felt
like
adding
enos.
You
know
some
people
might
not
be
using
that
ens
and
you
know
it
at
the
time
the
standard
was
being
written,
the
ownable
con.
B
You
know
the
ownable
contracting
pattern
was
already
being
used,
so
just
so
it
just
it
just
and
it's
it's
more
simple.
So
so
these
various
reasons
decide
not
to
use
ens
yeah,
but
also,
I
think,
for
this
standard
eip173
is
that
it's
so
simple
that
you
can
build
other
kind
of
ownership
patterns
on
top
of
it.
B
So
there's
probably
a
way.
You
know
that
you
can
implement
eip173
but
still
use
ens
for
for
owning
contracts
tied
into
it.
You
can,
can
you
can
you
add
voting
schemes
for
you
know
for
for
having
control
of
a
contract
on
top
of
eip
173..
So
I
think,
there's
a
lot
of
things
that
there's
a
lot
of
flexibility
with
with
how
it
is
how
simple
it
is,
but
you
can
build
on
top
of
it
to
to
cause
the
control
and
ownership
of
it
to
to
be
different
in
different
ways.
C
Just
to
just
to
make
sure
that
that
I'm
understanding
you
clearly
when
you
talk
about
ens
integration,
you
mean
just
to
be
able
to
be
able
to
put
in,
like
you
know,
a
foo
dot
f,
instead
of,
instead
of
actually
putting
in
the
whole
hexadecimal
address.
Or
are
you
talking
about
leveraging
the
system
on
a
deeper
level.
B
You
know
I
I
have
to.
I
haven't
tried
integrating
ens.
I
mean
I
think
I
looked
at
it
a
while
ago,
but
I
don't
I
don't
really
remember
very
much
about
it,
so
I
don't
have
a
good
answer
for
that
right
now.
I
I
just
feel
pretty
confident
that
there
could
be
some
integration
with
ens
with
it,
and
I
know
that's
very
vague,
but
I'd
have
to
look
no.
C
I
don't
mean
to
put
you
on
the
spot.
Also.
Definitely
what
you're
saying
is
also
true
that
if
you
just
have
the
basic
standard,
the
basic
pattern
for
how
to
make
something
ownable,
if
somebody
does
want
to
make
an
ens
integration
on
top
of
that,
then
for
sure
that
could
be
sort
of
another
layer
on
top
of
what
you've
already
built.
C
It's
there,
it's
it's
in
the
eip.
Also,
so
I
mean
it's
also,
it's
definitely
an
interesting
model
for
how
you
can
represent
like
sort
of
make
a
tokenized
representation
of
owning
a
contract.
But
again
I
mean
I,
it
would
seem
to
me
from
vip
to
what
you're
striving
for
and
definitely
from
what
you're.
What
you're
talking
about
now
is
the
most
simple
way
to
represent
ownership
of
a
contract
and
at
that
point
trying
to
get
fancier
with
it
as
interesting
as
implementations.
A
B
Yeah,
I
think
that
I
was
familiar
with,
opens
up
zeppelin's
ownable,
and
then
I
saw
dan
finlay's
post
about
you
know,
making
it
into
a
standard,
and
he
wrote
a
bit
about
that,
and
I
just
made
sense
to
me
to
do
that
and
I
wanted
to
be
a
standards
writer
and
it
seemed
like
an
easy
one
to
do
and
low-hanging
fruit.
Something
that
would
be
would
be
easy
to
you
do
and
that
would
be
valuable.
A
B
A
So,
while,
while
writing
this
standard,
I
know
that
you
have
also
been
coming
up
with
another
protocol
that
we
may
be
having
as
like
a
separate
episode
on
that,
because
I
know
that
that
has
a
lot
to
for
a
community
to
take
on.
So
I
was
just
trying
to
understand
what
would
be
your
experience
as
an
you
know,
a
protocol
writer
or
as
an
erc.
D
B
I
I
well
I
I
found
that
it
to
be
like
very
interesting
work
to
write.
You
know
eip
a
standard.
I
found
that
people
were,
they
were
very.
They
were
appreciative
to
have
someone
basically
develop
ways
to
achieve
things
that
people
could
could
use,
and
so
people
like
it,
the
challenges
are,
I
mean
one
of
the
things
the
challenge
I
had
was
like
was
sometimes
like,
depending
on
the
standard.
Sometimes
they
can
take
a
lot
of
time.
B
Like
another
standard
I
did
was
eip
998,
which
is
this
composable
non-fungible
token
standard,
and
it's
kind
of
has
a
a
a
lot
to
it
and
it
can
take
like
for
that
one.
It
took
a
long
time
to
develop
it
to
get
it
right
to
get
a
reference
implementation
to
to
to
test
it
to
get
feedback
from
people,
and
you
know
and
and
then
getting
you
know
some
adoption.
B
So
I
I
think
that
the
challenge
would
be
you
know
it
taking
time
and
also
like,
like
I,
I've
had
I'm
a
developer,
but
I
need
to
work
and
and
make
money,
and
so
like
my
experience
that
make
developing
standards
was
not
you,
you
might
not
get
paid
and
I
haven't
been
paid
so
like.
If
I,
if
I
was
paid,
then
I
I
feel
better
about
spending
a
lot
of
time
on
it,
because
then
I
could
pay
my
bill,
so
I
was
doing
it.
B
So
it's
so
funny.
You
know.
Technically
it
wasn't.
You
know,
and
it's
you
know
the
the
eip
editors.
You
know
the
people
that
you
know
allow
you
to
submit
an
eip.
They
they're
they're.
You
know
they
watch
what
you
do
make
sure
you
do
it
right,
but
they're
very
ex.
You
know
they
accept.
You
know
things
that
are
reasonable.
They
accept
so
it's
not
hard
to
if
you,
if
you
have
an
idea,
something
that
could
help.
B
A
So
yeah
I
mean
I
mean
it's
my
personal
thought
that
if
it
is
coming
from
a
developer
who
has
actually
implemented
or
know
more
in
detail,
if
they
are
writing
these
protocols,
they
can
do
more
justice
than
people
actually
who
are
seeing
it
from
far
distance.
So
it
makes
sense,
but
I
can
certainly
understand
your
point
of
you
know
investing
a
lot
of
time
in
writing
these
standards.
A
I
would
like
to
particularly
know
about
it.
You
know
I
was
reading
through
that.
I
find
that
everything
is
going
good,
I'm
no
expert
in
aip,
creating
or
writing,
but
I
feel
like
overall
it
looks
good,
but
but
still
we
are
looking
for
some
more
reviews
and
you
know
to
get
it
into
the
next
day.
So
if
you
have
any
like
what
would
be
your
suggestion
to
you,
know
kind
of
improve
and
make
these
process
easier
for
developers
to
who
wants
to
actually
write
protocols?
A
B
All
right
cool,
I
I
think
part
part
of
it-
is
getting
people
to
to
read
like
a
new
standard
and
to
give
useful
feedback,
and
so
I
think
what
you're
doing
or
you're
you
know,
you're
generating
interest
and
getting
people
to
participate,
makes
it
easier
for
people
to
write
eips
or
get
them
through
to
completed
end.
So
I
appreciate
what
you're
doing
I
think
you
know.
I
think
what
you're
doing
it
helps
with
that
yeah,
just
just
to
say
that.
B
Yeah
sure
so
it
does
depend
on
on
like
what
standard,
because
some
of
them
are
bigger
and
more
complicated
than
others
like
one.
Seven
three
is
not
very,
not
very,
not
very
complicated,
and
it's
already
you
know,
implemented
and
tested,
so
173
is
not
never
which
it
doesn't.
So
I
didn't
spend
very
much
time
on
173.
I
don't
know
how
much
but,
like
you
know,
some
some
amount
of
hours
on
it,
but
others
like
the
composable
non-fungible
token
standard
spent.
B
Like
you
know,
weeks
weeks
of
of
of
figuring
things
out
and
testing
and
implementing
and
answering
people's
questions,
the
diamond
standard
is
another
one
that
I've
spent.
You
know
weeks
of
work
on
I
mean
I,
you
know,
I
don't
have
a
very
good
idea
of
estimate
all
the
time
because
I
hadn't
hadn't
paid
attention
to
it,
but
I
just
know
it
could
be
weeks
or
months.
Spending
or
you
know,
on
on
bigger
standards
and
for
smaller
ones
could
be.
B
It
could
be
hours,
I
mean,
there's
you
know
erc20,
it's.
You
know
it's
more
complicated
than
than
173,
but
it's
it's
not
that
complicated,
but
it
was
new.
So
it's
probably
that's,
probably
a
medium
one.
I
mean
at
the
time
it
was.
It
was
developed.
It
was
you
know
new.
I
don't
know
I
just
I
just
thought
of
that,
one
that
once
but
that's
not
very
complicated
either
but
yeah.
So
I
think
it's
interesting
here
see
I.
B
I
watched
the
development
of
of
erc
721
a
non-fungible
token
standard,
which
is
has
a
decent
amount
of
complexity,
and
that
one
was
a
pretty
good
group
effort
like
there
was
a
lot
of
feedback
on
that
one
when
it
was
being
developed
and
that
one
took
some.
You
know
I
don't
know
some
weeks
and
maybe
a
couple
months
of
a
lot
of
continuous
attention.
C
B
B
Seven:
twenty
one
there's
just
some
there's
something:
there's
an
issue
for
discussion
and
there's
so
many
comments
like
I
don't
know,
maybe
a
thousand
comments
or
something
or
maybe
less
than
that,
but
but
hundreds
and
so
and
I'm
sure,
there's
a
people
talking
about
it
on
in
other
in
other
places.
But
for
me,
like
erc
998,
which
is
the
composable
non-fungible
token
one.
I
got
feedback
from
from
from
an
issue
on
the
repository
the
eip
repository,
but
also
there
was
on
discord.
B
A
Yeah
just
to
add
here
like,
for
I
mean
like
this,
this
particular
eip
is
a
like
pretty
old
two
years
back,
but
recently
what
we
have
started
is
like
encouraging
people
to
create
a
post
at
forum
of
fellowship
of
ethere
magician
and
move
the
discussion
over
there.
It's
actually
help
helpful
for
developers
to
have
it
in
your
central
place
and
they
can
give
their
feedback
asynchronously,
and
that
is
a
really
helpful
instead
of
making
it
in
you
know,
github
repository
and
keeping
it
in
form
of
issue.
A
B
A
To
me
I
mean
this
looks
very
cool
and
I
know
that
you
have
already
crossed
the
date
of
review
and
we
have
seen
review
feedbacks.
If
I,
if
I
remember
correctly,
most
of
the
suggestions
has
been
implemented
and
I
I'm
not
sure
like.
Maybe
a
couple
of
few
would
be
left
on
there.
So
did
you
hear
back
from
anybody
to
you
know
how
to
proceed
further
or
you're
just
waiting
on
like
somebody
should
come
up
and
help
you
out
with
pushing
it.
I'm
just
trying
to
understand
how.
B
Authors,
authors,
but
you
know
editors
had
some
concerns
and
some
some
thoughts
on
the
latest
revision
of
173
most.
You
know
mostly
kind
of
like
technical
things
like
like
more
like,
like
how
it's
edited,
or
it's
kind
of
or
like
what
headings
it's
using
so
and
I
and
and
I
just
and
I
I
dropped
it
a
little
bit.
I
just
need
to
get
back
to
it
and
put
and
just
fix
a
few
things
and
and
then
get
it
done
so
yeah.
A
B
I
can
say
that
if,
if
one
of
these
stalls
like
an
eip
stalls,
it's
probably
the
the
author
of
the
eip's
sort
of
fault-
they're,
not
following
it
through
so
like
right
now,
173
is
a
bit
stuck
because
I
kind
of
got
pulled
off
onto
working
on
other
things.
So
I
I
want
to
get
it
done,
so
I
I'll
get
back
back
on
it.
It
probably
doesn't
take
that
much
more
to
push
it
through,
but
yeah.
A
Yeah
we
have
seen
this
thing
like
generally,
what
happens
in
eip
is
started
and,
after
some
time,
author
either
lose
interest,
or
they
have
some
other
thing
to
do
so.
In
that
case,
we
recommend
somebody
who
is
like
interested
to
move
in
that
protocol
forward
come
up
as
a
champion
for
that
and
with
the
help
of
that
champion,
we
are
trying
to
transition
it
through
different
states,
and
the
current
effort
is
towards
you
know,
pushing
every
eep
to
the
right
place.
A
If
it
is,
it
has
to
be
finalized,
let
it
be
there
and
if
it
has
to
be
like
superseded
or
closed
just
to
clean
up
the
repository
to
be,
you
know,
more
usable,
that's
great.
I
think
that's
great
right
so
with
that.
I
think
we
at
the
end
of
the
session
today,
as
I
mentioned
earlier,
though,
I'm
not
the
expert,
but
I
really
hope
that
this
thing
should
move
ahead
after
the
release
of
this
video.
A
I
hope
that
it
should
get
to
the
state
of
final
as
soon
as
possible
for
those
who
are
new
and
are
planning
to
create
a
proposal
for
ethereum
chain.
We
highly
recommend
reading
eip1
and
watching
one
of
our
previous
episodes
like
creating
a
writing
and
evil
that
we
recorded
with
matt
like
kleinter,
and
with
that
I
would
like
to
thank
you
nick
and
thank
you,
everyone
for
joining
us
today,
nick.
I
hope
to
see
you
again
discussing
about
the
new
protocol,
the
two
five
eight
two,
five,
three,
five,
that's
diamond
standard.