►
From YouTube: PEEPanEIP#71: EIP-1202: Voting Standard
Description
Topics covered
-----------------------------
0:51 - EIP intro
1:23 - Guest’s introduction
3:10 - Presentation
3:45 - ERC Interface
4:06 - Interface overall
5:18 - Interface - Core part
11:00 - Interface - Metadata part
13:14 - Interface - Status part
15:55 - Highlight - Design decisions
19:58 - Q- have you thought about using a bytes32 ?
28:07 - Q- Why do we need an EIP for this?
33:22 - Why did you choose to do it on Ethereum?
35:41 - Implementations
42:32 - Notable prior art
43:58 - How can you help?
47:18 - Parting words
47:35 - Questions
48:00 - Are the votes saved on chain or off chain?
49:18 - How does the options array work?
51:18 - Can it be used to day to day approach?
54:49 - Can you share arguments to support or not support EIP-165?
58:10 - How long the implementation may take ?
1:00:00 - Security consideration
1:03:15 - Expected timeline to Review status
1:05:05 - Author’s feedback
Resources:
-----------------
Slides - https://docs.google.com/presentation/d/1pNrb3aLrClE64TUM4VWk1IM3kRQl-XOtNidtSVK_2AY/edit?resourcekey=0-JGtrUhxfv2Nf5jKL41QnQw#slide=id.g12cbe0c938f_1_82
EIP - https://eips.ethereum.org/EIPS/eip-1202
Discussion - https://github.com/ethereum/EIPs/issues/1202
Follow at Twitter
-----------------------------------------------
Zainan Victor Zhou @ZainanZhou | Pooja Ranjan @poojaranjan19
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
ERC Playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqXee9EMQDIEz2CslTnsW0K
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/EthCatHerders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/
A
On-Chain
voting
is
one
of
the
simplest
projects.
Anyone
could
imagine
on
blockchain
technology
since
early
days
of
development
voting
has
been
considered
to
be
an
important
use
case
for
blockchain
with
evolving
dows.
Needless
to
say,
the
community
has
realized
the
importance
of
voting
yet
ethereum
eip's
repository
does
not
have
any
standard.
A
Today
we
are
going
to
talk
about
a
proposed
ethereum
voting
standard.
Welcome
to
p
penny
episode.
71
I
am
puja
and
with
me,
is
a
very
special
guest
and
the
co-author
of
proposal.
1202
voting
standard
with
the
job
eip
1202
voting
standard
is
a
standard
track.
Erc
proposal
that
was
proposed
in
july
2018
and
currently
is
in
draft
status
to
learn
more
about
the
proposal.
Let's
welcome
victor,
thank
you
for
joining
us
victor.
A
B
B
and
so
in
17
it
was
like
there
was
a
big
hike
in
the
activity
of
issuing
ethereum,
erc
20
and
everything-
and
I
was
I
feel
this
is
a
very
interesting-
not
just
technical
improvement,
but
also
social
movement-
that
everyone
can
sort
of
own
the
digital
assets.
My
interest
has
always
been
how
these
digital
assets
can
be
used
to
motivate
people
to
contribute
and
also
to
improve
the
governance
and
looking
at
it.
B
Voting
has
been
discussed
a
lot
in
different
places
being
used
to
make
her
down
prior
to
many
things,
but
it
seems
weird
that
to
me
that
voting
standard
didn't
exist
yet
so
I
think
it's
I'll
discuss
more
about
why.
I
think
there
should
be
a
standard
for
voting,
but
that's
pretty
much.
My
journey
of
of
this
yeah.
A
B
Right,
yeah
thanks
porja
and
thanks
the
ethereum
cap
herders
for
invitation
and
really
happy
to
talk
with
about
this
proposal
with
all
of
you
and
look
forward
to
your
feedback.
As
you
know,
it's
currently
in
the
draft
status
and
many
things
still
unsettle.
I
have
some.
I
actually
have
some
design
decisions
that
I'm
proposing
here
for
you
to
give
feedback
and
also
for
audience
and
at
the
end
of
the
I
will
mention
the
the
prior
art
and
then
the
help
we
needed
at
the
end
of
this
presentation
for
you.
B
So
first
of
all
I
work
with
the
few
contributors
and
then
our
our
design
was
that
we
will
design
a
interface.
That's
that
has
three
different
subs
sets.
The
first
is
the
core
that
is
required
for
all
the
voting
standards
to
comply
with
there's
and
there's
also
a
metadata
ones,
and
also
that
one,
that's
okay.
B
The
metadata
version
is
trying
to
describe
the
internet,
describe
the
voting
standards,
for
example
the
issues
and
and
everything
just
like
the
nft
there's
a
part
that
controls
the
the
transfer
the
the
accounting
side,
but
also
there's
the
part
that
describes
the
what
nft
is.
So
that's
that
this
is
the
counterpart
of
the
erc2721
metadata
and
particularly,
there
is
a
status
sense
in
the
voting
standard.
So
we
also
include
an
interface
that
is
drc,
1202
status
and
I'll
go
through
them.
Each
individually.
B
To
begin
with
the
core
side,
we
call
it
core
because
we
it's
required
for
all
voting
standards
and
we
also
intentionally
keep
it
simple
as
simple
as
possible.
There's
some
design
decision
that
we
made
that
is
reflected
in
this
core
part.
I
would
just.
I
will
also
further
discuss
later
the
first.
Of
course
you
need
to
be
able
to
vote.
We
have
this.
B
B
So
a
typical
vote
take
these
two
inputs.
It
assumes
there's
an
issue
that
you're
voting
on
a
single
issue
and
also
assumes
the
multi
there's
multiple
options
that
you
might
be
casting,
and
in
particular
this
we
choose
to
use
a
array
to
store
this
option
id
because
we
assume
that
sometimes
these
can
be
ordered
and
so
by
make
designing
the
votes
in
a
take.
That
takes
a
single
input
of
issue
and
multiple
input
of
all
of
options.
B
We
allow
you
to
vote
on
one
issue
at
a
time,
but
for
multiple
options,
and
this
is
different
from
many
prior
art
that
we
see,
which
sometimes
assume
that
a
single
input
of
options
and
also
because
we
choose
option
id
as
a
unint.
It
can
represent
many
things
rather
than
the
boolean.
So
this
is
how
we
see
this.
I
I
also
see
a
lot
of
our
audience
here
today
which
come
from,
I
assume,
if
you
even
can't
hurt.
B
B
On
one
side,
we
give
the
two
inputs
that
is
issue
id,
and
the
limit
which
gives
us
allows
the
client
who
interact
with
this
contract
to
query
for
the
current
top
options,
regardless,
whether
of
the
whether
the
vote
has
complete
or
has
complete
or
not,
we
assume
that
status
can
change
over
time
can
be
revoked
and
and
other
things.
So
this
top
options
is
just
a
view
method.
B
In
order
for
the
queries
to
see
the
result
of
the
result
of
the
of
one
vote
of
one
issue
and
to
accommodate
for
multiple
inputs,
multiple
outputs,
each
situation,
we
also
design
it
in
a
way
that
it
returns
an
array
of
of
in?
U
ends
which
is
the
in
the
order
of
in
the
in
the
order
of
of
the
priority,
the
results
of
other
people's
votes.
B
Then
you
can
have
a
limit
of
three
and
then
it
will
tell
you
the
current
winning
three
of
the
of
the
candidates.
So
that's
the
that's
why
we
designed
the
top
options.
This
way,
we
intentionally
decouple
this
from
the
status
and
also
we
intentionally
give
it
the
flexibility
of
querying
the
results
of
of
multiple
outputs
and
the
third
one.
So
the
third
part
is
the
on
votes
results.
B
I
can
see
there's
some
of
the
reason
that
people
won't
will
want
the
vote
to
be
payable,
some
not,
but
I'm
not
yet
sure
which
one
is
the
better
way.
So
if
you
happen
to
have
an
opinion,
I
love
to
hear
about
this,
like
do
you
think
people
should
be
able
to
vote
payable
or
with
additional
data,
that's
something
that
is
up
to
debate
and
for
discussion,
this
design
decisions,
so
that
is
left
out
and
still
working
progress,
and
so
the
metadata
here
is
the
second
part.
B
Of
course
you
want
to
be
able
to
let
people
know
what
er
voting
is
about
what
options
are
about
and
if
it's
totally
possible
that
people
want
to
store
it
off-chain
without
a
storage,
decentralized
storage,
for
example,
the
nft
721
or
1155,
currently
supports
at
7.
12
21
supports
two
ways:
right
one
is
you
can
provide
the
name
and
then
you
can
provide
ui
as
an
image.
B
Similarly,
I
think
1155
particularly
requires
the
or
or
primarily
assumes
the
ui
to
be
point
to
a
json
schema,
and
so
here
the
metadata
is
here
to
provide
kind
of
basic
support
for
illustrating
what
the
issues
are,
what
the
options
are,
but
we
also
give
give
people
the
options
to
point
it
to
an
uri
and
the
the
json
schema
have
not
been
fully
decided.
Yet
we
also
haven't
decide
whether
it
makes
sense
to
eat,
enumerate
it
through
the
different
proposals
or
different
standing
proposals.
B
I
guess
there's
possible,
there's
many
ways
to
filter
and
it
iterate
through
the
entire
list
of
proposals,
so
that
has
not
been
designed
yet
unsure
whether
that
is
needed
at
all
or
not.
So
if
you
have
suggestions
on
that,
that
would
be
cool
too
yeah.
So
that's
the
metadata
part.
Do
you
have
any
questions
comments.
A
B
That
sounds
good
yeah.
The
other
one
is
stats
status
of
the
rc1202
for
each
individual
issue,
so
each
of
them
will
have
a
issue
id
and
then
we'll
check
if
the.
If
the
the
voting
is
open
or
not.
Here
we
choose
to
kind
of
reduce
the
complexity
and
also
flexibility
only
set
the
the
different
the
two
allowed
to
status.
One
is
open,
one
is
not,
and
so
what
people
can
do
is
if
you
want
to
set
the
status
of
voting
to
be
open.
B
You
can
like
the
owner,
for
example,
or
access
control
roles
can
set
it
to
be
open
and
then
usually
people
assume
that's
the
first
time
an
issue
is
created,
it
will
be
open
or
it
will
have
some
sort
of
a
block.
I
block
number
within
the
block
number,
it
will
be
open
or
closed
and
then
we
can
people
can
subscribe
to
the
on
status
change
for
the
closing
time
and
inquiry
results
at
that
time.
B
The
top
option
should
be
able
to
give
you
or
the
this
standard
assumes
that
top
options
will
will
behave
as
if
it
will
give
you
the
right
results
at
the
end
of
the
when
the
status
close
close
down
and
also
we
will
give
people
an
interface
to
query
what
vote
did
the
voter
casts?
So
this
is
what
the
method
vote
off
does,
so
you
give
it
an
issue
id
and
a
voter.
B
It
will
return
you
to
read
the
result,
and
particularly
this
hasn't
remained
open
to
both
cases
right
what
happens
if
a
person
votes
in
vote
twice
in
the
same
issue?
Should
that
second
time
overrides
the
first
cast
or
should
the
second
time
be
rejected
or
the
second
time,
let's
assume
it's
a
weighted
vote
to
be
accepted
as
additional
weight,
and
so
these
are
all
open
and
we
assume
there's
many
parts
that
need
to
become
extended
or
be
to
considered
in
extensions.
B
We
also
know
that
any
decision
we
make
and
large
can
vastly
reduce
the
flexibility
of
this
center.
So
that's
the
what
makes
the
standard
really
a
head
scratching
trip
for
me
because
like
when,
whenever
you
choose
one
side,
you're
closing
the
door
for
the
other
side.
So
this
is
the
main
parts
of
the
of
the
of
the
status
and
then
so
I
list
the
a
bunch
of
decision
design
decisions
that
we
made
so
far
and
which
includes
both
what
we
want
to
be
opinionated
about,
and
then
we
we
want
to
be
opinion.
B
Less
of
so.
The
vote
casting
and
tally
should
be,
but
not
required
to
be
on
chain.
So
it's
a
should
one,
but
not
must
one,
and
it
also
supports
multi
options
rather
than
only
yes.
No.
We
believe
that,
as
we
move
more
and
more
onto
the
the
dow
and
to
to
vote
using
voting
to
get
human
consensus,
we
will
have
more
and
more
different
questions
in
different
past
and
different
ways.
Yes,
and
no
binary
ones
is
not
the
only
thing
that
we
will
see.
B
So
we
that's
why
we
intend
to
to
choose
the
multi-option
multi-input
multi-output
for
in
order
to
support
multi-options,
and
we
also
support
on-chain
metadata.
We
assume
that
if
we
have
a
very
good
decentralized
storage
in
the
future,
then
maybe
that's
not
super
important,
but
for
now
at
least
it's
I
think
it's
important
supporting
setting
and
reading
status
of
a
proposed
issue
is
also
somewhat
it.
B
That
is
that's
what
we're
leaning
towards,
but
we
have
not
like
fully
decided
yet
now
we
intentionally
to
be
opinion-less
about
is
like
how
roles
are
created.
What
roles
are
voting?
What
roles
are
vote
allowed
to
vote?
How
issues
are
created?
How
metadata
are
structured?
How
weight
weights
of
the
vote
are
calculated,
how
winning
options
are
determined
like
rank
choice
and
like,
and
a
bunch
of
others
can
be
decided
in
in
various
different
ways,
so
we
want
to
avoid
getting
into
that.
B
C
B
Quadratic,
I'm
not
looking
into
it
and
then
also.
I
know
that
in
in
blockchain,
if
creating
us
and
a
wallet
address
is,
is
permissionless.
It's
actually
opens
up
some
ways
to
cheat.
If
you
are
calculating
the
quadruple
voting,
and
so
that's
what
we
in
opinion
less
about
and
trying
to
open
the
door
for
innovations
and
and
competition
there.
So
how
are
issues
locked
activated
enabled
is
also
what
we
are
opinionless.
B
We
assume
that
there
will
be
other
follow-ups
or
extensions
coming
up
to
the
sides,
particularly
whether
it's
on-chain
execution,
who
will
be,
will
pull
the
trigger
and
all
these
are
going
to
be,
I
think,
should
maybe
they
should
be
standardized
or
not,
but
we
are
at
least
for
the
core
side.
We
are
staying
opinionless
about
about
this,
so
that
is
the
decisions
I
want
to
pause
here
and
then
see.
If
people
have
questions
comments,
this
is
probably
a
lot
of
choice
to
make.
D
B
D
B
B
D
I
think
the
common
approach
right
now
is
that
you
don't
actually
store
the
text
on
chain.
What
you
do
is
you
just
upload
the
text
to
something
like
ipfs
yeah,
the
place
where
people
see
that
the
most
clearly
is
an
nfts
in
most
nfts.
The
image
of
that
nft
like
art.
Nfts
is
not
stored
on
chain,
usually
it's
stored.
D
In
the
best
of
cases
it's
stored
on
a
decentralized
file,
storage
like
something
like
ipfs
or
our
weave.
So
then
the
uri
becomes
a
pointer
to
ipfs
or
our
weave
and
both
of
those
are
32
bytes.
So
you
could
fit
that
into
32
bytes.
It
happens
in
both
721
and
1.55.
The
uri
fields,
the
string
not
by
32,
but
the
pointer
itself
is
a
32
by
is
a
32
byte
pointer.
D
So
what
you
could
do
for
something
that's
supposed
to
be
a
longer
text
is
just
assume
immediately
that
people
are
not
going
to
store
the
text
on
chain
and
instead
have
the
just
have
that
store
of
bytes,
32
pointer
to
let's
say
ipfs
and
have
the
function
of
that
pointer,
like
the
pointer,
will
be
stored
on
chain,
but
to
actually
get
the
text.
It's
assumed
that
ipfs
would
be
queried.
B
B
It's
very
valuable
yeah
I
I
do
want
to
make
it
clear
that
one
of
the
parts
of
this
proposal
is
trying
to
at
least
allow
people
to
put
some
of
the
text
on
chain,
because
we
think
that
it
it
for
one
side.
If
some,
if
a
voting
is
important
for
a
community,
for
example
dao,
then
we
like
it
more
a
reliable
way
is
needed
for
people
to
agree
on
which
texts
are
like
which
options
which
option
represent
what
what's
results
and
so
on.
It's.
B
It
opens
up,
of
course,
each
time
we
direct
it
to
ipfs
or
offchain
storage,
we
open
up
to
the
possibility
of
more
security
vulnerabilities,
so
that
is
one
thing
that
I'm
trying
to
trade
off
between
the
efficiency
versus,
but
I
totally
agree
with
you
seeing
how
erc
721
and
1155
does.
I
think
it's
totally
reasonable
to
assume
that
people
will
and
some
people
will
choose
to
to
use
the
ipf
is
to
to
reduce
the
cost.
B
So
one
thing
is
that
I
would
anticipate
the
I
erc
one
six,
one,
eight
sorry
165
the
interface
identification
we
will
by
splitting
them
up
in
three.
We
will
be
able
to
support
three
different
interface.
So
that's
some
of
the
options,
some
of
the
votes
or
issues
or
voting
standards
will
implementation
will
support
only
the
core
and
divide
large
parts
outside
and
some
were
not.
The
question
you
mentioned,
like
the
n721,
the
the
url.
B
Sorry,
the
tokens,
images
and
and
descriptions
were
stored
in
ipfs
is
one
of
the
example
that
it
didn't
leverage
the
massive
metadata.
Instead,
it
used
the
json
schema.
It
follows
the
json
schema
that
designed-
and
here
maybe
I
think,
a
trade-off
that
people
can
make
is
to
just
like
the
just
like
the
coin.
B
C
B
C
B
B
So
these
are
decisions
that
need
to
be
made
together
and
currently
there's
not
a
good
way
for
people
to
to
to
vote
in
a
in
a
standard
and
what
you
can
see.
I
would
envision
in
the
future.
You
will
not
need
just
to
go
to
the
uni
swap
web
d,
app
to
vote
or
go
to
the
maker
down
the
app
to
vote
or
go
to
argon
web
to
vote.
Maybe
you
can
also
vote
on
metamask
if
mathematic,
if
there's
a
standard,
that
the
voting
follows
and
metamasks
adopt
them.
B
And
let's
say,
if
you
have
other
places
where
people
can
vote
in
various
of
different
community
decisions,
maybe
there
will
be
curations
of
decisions
need
to
be
made
and
pro
and
they
will
show
have
an
interface
that
shows
those
issues
being
proposed.
And
then,
if
you
happen
to
own
the
governance
token
of
one
of
them
or
multiple
of
them,
then
they
would
they.
B
You
can
have
a
centralized
convenience
interface
to
to
place
to
start
voting
so
having
a
standard
really
is
allowing
human
being
to
on
not
only
guest
consensus,
but
also
for
machines
and
different
contracts
to
interrupt
to
interrupt
to
interpret
the
the
the
voting
in
a
standardized
way
without
a
standard
standard
standard
it.
We
really
don't
have
a
good
way
to
for
interoperability.
B
Let's
assume
there
will
be
doubt
of
dials
right
and
then
some
of
the
decisions
will
be
made
in
a
small
group
and
then
their
result
will
cast
a
vote
on
the
larger
group
and
that
needs
interoperability
as
well.
So
these
are
the
things
that
I'm
having
in
my
mind
that
can
be
adopting
this
voting
standard.
B
Imagine
one
day
that
you
don't
need
to
go
to
various
places.
You
just
have
a
place
to
to
look
at
where
all
the
on-chain
issues
are
waiting
for
your
decisions,
and
you
can
vote
on
them.
Just
like
nft
will
show
up
on
some
of
the
wallets,
and
people
will
also
compete
for
building
the
best
interface
to
display
and
query
and
serve
the
the
voting
and
yeah.
That's
what
it's
in
my
mind
does
that
answer
your
question.
B
B
I
know
that
we
already
see
some
voting
happening
in
prior
arts,
but
without
standardization
they
we
lack
interoperability
between
smart
contracts,
between
the
apps
or
between
questions.
Right,
imagine,
you're,
a
question
builder
or
bridge
builder
building.
If
there's
a
standard
building
one
voting
question
solutions
means
that
they
can
support
multiple
different
ones,
but
without
a
standard
you
have
to
build
for
each
individual
ones.
So
that's
what
I
see
why
there
is
need
for
a
eip
in
this
area.
B
Coin
that
that's
a
very
good
question,
I'm
I
actually
need
to
I
I'm
so.
First
of
all,
I
haven't
think
much
deeper
of
alternative.
I
I
know
that,
for
example,
the
argon
has
its
own-
if
I
understand
correctly,
has
its
own
chain
separate
chain
for
voting
and
for
what
I,
my
more
of
intuitive
sense,
is
that
ethereum
has
been
so.
B
Has
proven
its
reliability
and
has
proven
its
usability
and
utility
amount
in
various
various,
the
apps
and
and
applications
building
on
ethereum
for
one
is
safer.
It
has
been
proven
through
the
value
locked
in
the
in
the
chain.
It's
safe
and
also
it
increases.
The
cover
increases
the
reach
that
it
can
be
used
immediately
in
various
applications.
B
Right,
if
you,
if
we
aim
at
interoperability
and
on
day
one,
we
don't
have
many
good
ways
and
to
use
it
at
all,
then
it's
not
so
much
value
of
bringing
that
interoperability
right
on
the.
Alternatively,
if
we
do
this
on
ethereum,
which
already
have
many
ditch
the
app
you
can
imagine,
interoperability
play
a
big
role
there
right,
for
example,
three
people
can
vote
on
chain
to
decide
whether
they
will
move
some
of
the
liquidity
pool
out
or
inside,
and
that's
an
immediate
use
cases
if
it's
viewed
on
ethereum.
B
Yeah,
okay,
I
see
that
puja
is
called
making
the
time
check
so
the
if
we
want
to
go
through
the
implementation.
The
one
of
there
is
two
type
that
I'm
working
with
the
third
type.
Probably
is
not
what
I
would
discuss
today,
but
the
first
one
is
the
single
input,
single
output,
ones
that
allow
multiple
options.
It's
a
multiple
single
choice,
so
we'll
store
the.
B
We
will
have
a
a
mapping
between
issues
to
the
voter
address
to
the
to
the
option
id
and
then
we'll
also
have
the
issues
to
voter
address,
to
the
option,
to
the
option
id
for
the
for
the
votes,
that's
being
casted
and
also
we'll
have
the
vote
count
that
is
stored.
This
is
like
nothing
is
optimized
for
for
efficiency,
for
the
cost
of
gas
or
anything
it's
just
demonstrating
that
this
works.
B
So
when
you
vote
will
validate
it's
a
it,
it's
an
existing
issue
that
is
has
been
created,
and
then
we
will
also
validate
that
options
false
under
the
the
list
of
the
option
limit.
For
example,
in
this
particular
case,
we
have
an
option
id
and
then
so,
when
you,
when
we
validate
the
option
id,
the
new
options
will
be
captured
and
the
open
up
the
old
options
will
be.
B
So
we
will
just
do
a
very
basic.
We
will.
We
will
just
do
a
very
basic
founding
for
the
the
most
voted
options
and
then
we'll
we
will
output
the
most
voted
options
and
metadata
is
just
dummy
ones.
So
I
will
skip
this
part,
but
I
would
envision
the
I
would
envision.
That's
the
new,
the
real
use
cases.
People
will
use
this
metadata
a
lot
and
for
the
setting
status
here.
B
We
will
just
assume
that
people,
the
the
own,
the
admin
or
the
owner
will
set
the
status
for
the
open
up
for
a
vote,
and
then
it
will
also
it's
of
in
this
particular
case,
we'll
set
it
to
be
not
setable
and
will
always
be
open
for
for
voting,
so
it
effectively
become
a
pool
of
opinions,
and
also
people
can
change
what
they
believe,
what
what
their
votes
are.
So
this
is
this
is
the
one
of
the
example
of
the
single
input
single
output.
B
So
the
multiple
output
input,
multiple
output
is
similar
and
we
are
storing
the
voted
results
and
then
we
are
also
storing
the
the
the
we
are
starting,
whether
this
this
voter
has
voted
and
whether
the
voter
has
like
their
their
the
the
vote.
They
cast
it
and
the
result
of
each
options,
and
for
that
for
this
particular
one
implementation.
B
B
We
will
anticipate
that
our
implementers
or
actually
issue
creators
will
design
how
many
options
is
available
for
for
that
particular
options.
So
that
is
also
addressable
through
the
issue
id
of
input
and
as
you
as
prior
similar
to
prior
previous
one,
you
see
old
options
will
be
overwritten
will
not
be
allowed
here.
You
will
not
allow.
B
So
that's
how
you
calculate
the
votes
and
the
top
options,
then
we'll
be
calculating
the
max
the
the
sorted
result
of
it.
So
that's
trivial
in
in
a
regular
computer
of
programming,
and
so
that's
pretty
much.
The
two
example
there's
some
other
examples
that
we
were
working
on,
but
it's
a
little
bit
too
expensive
in
gas
fees
and
we're
still
working
on
addressing
it.
For
example,
the
we
have
some
example
of
of
ranked
choice,
but
it's
we,
we
haven't
been
able
to
port
it
to
solidity.
B
B
I
guess
that
would
be
very
hard
for
audio
on
the
audience
yeah
now
I
want
to
mention
some
and
give
credit
to
some
of
the
notable
prior
arts,
so
the
maker
dao
governance
on
module
compound
governance,
open
sapling,
has
its
governance,
module
for
people
to
use
and
argon
has
its
governance
and
a
lot
more.
People
are
starting
to
see
the
value
of
having
a
doubt
to
organize
their
their
group
and
they
want
to
be
able
to
let
people
have
their
voice
now.
B
Seeing
these
different
governance
and
seeing
their
interface
differently
is
what
is
one
of
the
big
motivation
of
creating
this
standard,
because,
even
today,
these
groups
are
are
important
and
play
an
important
role
in
the
ecosystem,
have
not
been
able
to
standardize
the
way
we're
living,
probably
living
in
just
like
a
time
of
crypto
kitty
that
is
nft
before
721,
and
I
envisioned
there
will
be
an
explosion
of
proposals
and
votings
and
governance
and
doubts.
If
should
we
have
a
stable
standard
of
voting?
B
So
that's
what
we
why
we
want
to
create
this
eip,
and
I
address
this
question
when
alita
raised
the
question.
I
think
it's
very
very
important
that
the
ecosystem
has
a
way
to
get
human
consensus,
and
I
also
wanna
up
like
give
a
big
thank
you
for
posia
audience
of
today
and
also
ethereum
cat
herders
for
allowing
me
to
present
this
still
very
work
in
progress
standards.
B
We
want
to
call
for
the
audience
who
are
interested
in
helping
to
join
if
you
for
everyone,
we
look
forward
to
hear
your
ideas,
your
opinions,
your
comments,
your
critics
on
the
design,
design,
decisions
that
we
make
where
we
haven't
make
and
if
you
happen
to
be
cryptography,
researchers,
computer
scientists,
security
scientists.
There
are
areas
that
we
like
this
current
author
groups
were
not
does
not
have
enough
expertise
about,
for
example,
how
do
we
allow
anonymous
voting
right?
An
honest
voting
is
used
in
many
occasions
in
many
places,
but
it
seems
in
the
public
ledger.
B
B
There
is
already
some
the
app
even
allow
people
to
delegate
their
votes
to
them
and
and
to
get
a
gain,
and
we
know
that
there's
some
use
cases
there,
but
we
also
hope
that
there
is
a
way
for
dallas
or
for
for
groups
of
people
to
avoid
such
if
they
decide
to
right
they
if
they
want
to
make
sure
no
one
can
get
bribed
for
voting
in
such
in
certain
way.
They
can
avoid
that.
B
Ultimately,
we
hope
to
be
massively
flexible
and
be
able
to
integrate
with
those
prior
arts
right.
Imagine
when
we
have
a
voting
standard
stabilized,
we
can
people
can
write
wrappers
of
this
voting
standards
over
other
existing
prior
arts,
so
that
people
can
still
vote
on
the
existing
existing
projects
without
the
existing
project
needing
to
change
their
interface
and
integrate
with
prior
arts
and
for
and
also
propose
extensions
for
area.
We
stay
opinionless
right,
there's
many
place.
B
We
want
to
be
flexible
and
opinionless,
but
we
do
know
there's
a
usability
for
certain
design
decisions
so
propose
erc
extensions
to
those
would
be.
We
would
need
help
from
erc
authors
and
build
tests
and
for
the
implementations
and
the
apps.
So
all
the
different
type
of
help
will
need
it.
We
look
forward
to
your
help
and
you
can
ping
me
on
github
or
twitter
or
linkedin,
which
is
still
in
this
page,
and
the
parting
words
would
be
imagine
one
day.
B
A
A
B
B
Then
you
can
choose
to
represent
your
for
or
against
position
in
zero
and
one.
However,
let's
say
if
you
are
voting
in
a
political
in
a
political
campaign
to
the
side,
a
list
of
board
members
or
a
company's
board
members.
Sometimes
sometimes
you
might
want
to
choose
multiple
ones
from
a
list
of
candidates.
Let's
assume
there's
nine
candidates
and
you
want
to
choose
three
of
them
and
then
you
can
also
use
the
option
ids
to
designate
the
the
option
you
can.
B
You
can
give
each
candidate
a
number
and
then
you
can
cast
your
votes
by
with
the
proposal
id
and
then
the
candidate's
number
as
the
option
id
in
this,
and,
let's
assume
you
happen
to
live
in
somewhere,
that's
used,
ranked
choice,
voting
and
so
that
ranks
matters
in
this
case,
then
you
can
choose
your
order
of
preference
to
be
the
same
with
the
option
ids
as
an
array.
So,
by
designing
this
as
an
array
input
of
union,
we
open
up
the
door
for
this
various
possibility
of
designing
the
vote.
Implementation.
E
Yeah,
thank
you.
I
mean
it's
good,
it's
an
excellent
idea.
I
like
it.
I
just
wondering
why
not
take
it
a
little
bit
to
the
you
know
more
day-to-day
process,
like
you
know,
when
you're
gonna,
when
you
write
a
pull
request,
you
basically
go
through
that
process
of
voting.
You
know
from
the
approvals
or
editors
or
whoever
has
the
authority
to
evaluate
and
approve
it.
Even
if
you
are
you're
writing
an
issue
depending
on
the
repo
you
even
go
through
that
process,
I
don't
know,
maybe
just
take
take
it.
E
I
mean
I,
I
love
the
idea.
It
seemed
that
it
is
great,
but
maybe
just
take
it
to
the
you
know,
to
the
more
day-to-day
business,
not
like
it's
not
just
a
point
to
having
you
know
the
president
election
or
board
of
directors.
I
mean
I
like
that.
I
mean
that's
fine,
but
I
think
that
the
idea
has
would
have
a
huge
impact.
If
you
manage
to
get
it,
then
the
into
also
the
day-to-day
approach.
You
see
what
I
mean.
B
Yeah,
I
I
totally
agreed
yeah
one
of
the
one
of
the
examples
I
actually
mentioned
in
the
erc
is
that
multi-sign
on
chain
right.
We
know
that
there's
some
multi-sign
solutions,
off-chain,
but
let's
say
if
you,
for
example,
if
you,
if,
if
you
have
some
minors,
that
you
are
giving
your
wallet
access
to
and
then
they
will
sign
a
contract
and
then
you
need
to
approve
it
and
so
that
they
can
spend
up
to
certain
amounts.
That's
a!
B
B
Otherwise
it
would
be
just
like
a
all
the
decentralized
software
where
everyone
there
is
one
individual
entity
responsible
for
upgrading
it
and
also
they
can
make
their
own
judgments
and
decisions
to
upgrade
it.
So
that's
one
other
example
of
where
people
where
we
can
use
the
voting
center
to
make
sure
the
community
or
community
agree
on
something
and
that
decisions
are
made
upon,
and
so,
if
I
were
to
answer
you
of
the
day-to-day
use
case
on
blockchain
for
leveraging
the
the
the
use
cases.
B
A
I
hope
yes
all
right,
so
I
know
we
are
a
bit
over
time,
but
I
have
a
few
more
questions
that
I
can
probably
run
quickly
by
you.
The
first
word
is
about
the
eip165,
so,
according
to
the
proposal
discussion
which
we
can
find
in
the
issue
number
1202,
the
discussion
two
links
suggest
that
there
are.
There
are
quite
a
lot
discussion
and
the
proposal
received
fairly
decent
feedback.
Most
of
them
are
positive.
A
B
We'll
definitely
support
erp
165.
I
don't
think
there
is
a
particular
reason
not
supporting
it.
Eip
165
provides
a
very,
very
useful
way
for
interface
to
be
detected
to
be
used,
and
then
I
would
envision
that
a
lot
of
different
d,
apps
and
applications
smart
contract
will
use
the
the
standard
interface
implementation.
B
So
for
that
for
sure
we
will
implement
it.
I
think
that's
we
just
haven't
get
the
time
to
bake
it
into
it,
and
also
the
ese
165
depends
on
the
interface
you
design
and
then
that's
particular
number
needs
to
generate
after
we
finalize
so
the
all
the
methods
and
and
and
the
signatures.
So
that's
why
we
haven't
gone
there,
but
I
think
you
point
raise
a
very
good
question.
It
brings
to
me
another
question.
B
We
will
try
to
see
if
we
need
some
kind
of
safely
do
something
we
have
not
yet,
and
I
vaguely
feel
has
a
sense
that
that
part
needs
to
have
a
standardization
that
is
relevant
to
165,
which
is
have
not
yet
so.
If
anyone
is
interested
in
working
on
that,
I
think
that
would
be
useful
for
all
the
future
standard
designers
right.
So
I
will
I
that's.
That
would
be
my
answer.
A
Maybe
a
quick
follow-up
on
that
you
mentioned
about
integrating
the
report
to
eft-165
and
earlier
also
in
your
presentation
you
mentioned
supporting
to
payable
vote.
Do
you
think
it
can
probably
delay
status
change
of
the
proposal
like
how
long
do
you
think
the
implementation
of
all
these
things
or
may
take.
B
Yeah,
probably
take
another
three
months
for
overall.
I
start
us
out
for
overall
updates
decisions
to
be
made
and
implementation
before
we
can
come
back
to
the
community
and
and
ask
for
final
reviews,
or
maybe
it
will
take
shorter
or
longer.
But
the
type
three
three
month
is
a
timeline
in
my
mind.
Right
now,
and
my
goal
right
now
is
to
maybe
talk
to
different
various
prior
art
builders
to
get
their
collector
feedback,
because
I
know
that
they
have
made
some
design
decisions.
B
A
That
is
good
to
know.
While
we
are
expecting
some
changes
to
the
proposal,
a
suggestion
I
saw
one
particular
section
work
a
directory.
I
don't
think
that
is
anymore,
a
standard
section
to
be
added
in
eip.
So
maybe
you
can
consider
removing
that
particular
section
and
also
a
reference
implementation.
A
B
A
D
A
My
next
question
is
related
to
security
consideration,
and
this
is
my
second
last
question
I'll.
Try
to
make
it
quick.
Is
there
anything
important
into
security
consideration
that
you
would
like
to
mention
that
any
developer,
who
would
want
to
implement
this
proposal
in
your
in
any
of
their
project?
Maybe
consider
that
in
mind.
B
It
is
very
easy
to
get
the
to
to
get
the
weight
wrong
right.
For
example,
if
you
are
using
a
lot
of
times
we
you
use
the
nft
ownership
or
the
where
the
the
tokens
they
they
owned,
number
of
tokens
they
owned
to
become
the
weights.
Now,
if
you
decided
to
lock
the
the
weights
up,
make
sure
that
locking
mechanisms
are
are
safe,
otherwise,
you'll
be
locked.
If
mistake
happens,
there
you'll
be
blocking
people's
tokens
forever
or
or
break
the
assumptions
of
of
ledge
of
a
ledger.
B
So
that
is
the
the
key
part
I
think
can
go
wrong
very,
very
badly,
and
the
other
thing
is
that
the
more
subtle
but
usually
like
for
a
massive
adoptions,
usually
people
assume
they
will
use
their
own
daily.
Day-To-Day
voting
experience
to
re
to
to
to
to
refer
to
when
they
use
the
voting
applications
on
chain,
but
didn't
know
that,
for
example,
their
identity
would
be
reviewed,
or
things
like
that.
B
So
that
is
a
more
of
a
social
side
of
security,
and
it's
non-trivial
to
to
maintain
a
non-ability
and
accountability
can
go
very
wrong
in
some
ways.
For
example,
people
will
know
that
how
how
you
vote
and
in
how
much
you
vote
in
weights
prior
to
day
votes,
that's
one
possibility
right,
because
everything
is
on
chain
and
that
assumptions
are
not
very
common
in
the
day-to-day
voting
experience
right
now.
B
So
application
builder
needs
to
be
aware
that
need
to
let
the
user
know
that
and
also
understand
they
can
open
up
to
various
way
of
gaming
the
system,
so
that's
all
very
non-trivial.
It
opens.
I
think
it's
a
whole
different
conversations
and
probably
have
another
hour
to
discuss
the
security
issues
here,
and
we
also
look
forward
to
security
experts
in
in
this.
A
A
Talking
about
statuses,
like
I
understand
this
proposal
was
proposed
about
four
years
ago,
and
I
remember
seeing
conversation
moving
into
the
last
call
now
that
you
are
considering
adding
some
more
things
to
it.
I
just
want
to
make
a
mention
of
it
like
since
2018
till
2022,
the
process
has
changed
a
little
bit
and
now
there
is
a
status
called
review
which
is
in
between
draft
and
last
one,
so
I
hope
with
changes.
We
can
see
this
proposal
coming
up
into
review
status.
B
B
A
A
Share
you
can
definitely
change
it
to
review
and
once
you
think
that
it
is
all
ready
by
review
what
we
mean
is
like
all
eip.
Editors
should
pay
attention,
and
even
if
there
are
tap
developer,
they
would
like
to
provide
you
feedback.
They
can
come
forward
and
share
things
with
you
after
a
few
days.
That's
totally
up
to
the
author.
After
a
few
days,
you
can
move
it
to
last
call,
but
in
last
call
we
have
this
fixed
duration
of
two
weeks,
not
for
review.
A
B
I
think
that's
pretty
much
it.
I
I
just
really
I'm
grateful
for
your
giving
this
opportunity
for
me
to
share
and
how
to
collect
your
feedback.
Your
questions
are
greatly
valued
and
I'll
continue
to
work
with
the
group
work
group
to
drive
this
forward,
and
hopefully,
one
day
everyone
can
have
their
voice
heard.
A
Absolutely
well,
thank
you
so
much
for
sharing
this
proposal
with
us.
I
hope
the
information
shared
today
will
be
helpful
for
students
and
upcoming
developers
building
projects
on
blockchain,
and
I
hope
that
this
proposal
moved
forward
faster
than
it
had
in
the
past.
So
we
can
have
a
standard
added
to
the
ethereum
depository
soon.
A
On
this
note,
thanks
to
all
our
youtube
viewers
for
watching
it,
if
you
have
implemented
this
eib
in
your
project,
share
with
us
comment
in
the
comment
section
below.
Let
us
know
if
you
have
any
follow-up
question
on
the
proposal,
you
can
also
join
the
discussion
on
the
discussion
tool
link
provided
on
the
proposal,
check
out
description
for
details
and
related
links
that
also
contains
guest
twitter.
If
you
have
any
question
you
may
be
able
to
reach
to
the
guest
as
well.
A
If
you
have
got
any
suggestion
on
this
eip
or
any
other
eip,
let
us
know
on
cathedrals
discord
or
you
can
also
tag
us
on
twitter,
subscribe
to
youtube
categories,
youtube
channel.
If
you
haven't
done
it
already,
see
you
next
time
with
another
interesting
proposal
till
then
keep
watching
keep
sharing
your
love
with
the
idiom
cat
herders.