►
Description
Topics covered
----------------------------
01:15 - About proposal
02:10 - Guest introduction
03:17 - Presentation - agenda
04:07 - Types of tokens based on state mutability
6:20 - Challenges of supporting mutable tokens
9:49 - Problem statement - How to unambiguously identify a token state, without the knowledge of implementation details?
10:46 - Do we need a standard? Example ERC 20
12:00 - Do we need a standard?
12:47 - Existing attempts
16:51 - EIP-5646
20:36 - Do not use state fingerprint as a sole token identifier
21:04 - Examples - Loan token
End of presentation
25:09 - Rational and usefulness of the proposal
32:34 - Attack factor - what will the adversary do?
35:55 - Responsibility of the implementer
36:45 - Significance of state fingerprint events. Why is it not a part of the current specs?
38:18 - Implementation of EIP-5646
39: 20 - Workaround the existing projects to deploy this EIP
40:54 - Are you working with a project or on a prototype?
42:38 - Security consideration for dapp developers
43:48 - Thoughts on EIP process
44:58 - When to move to the Last Call
Resources:
-----------------
Proposal - https://eips.ethereum.org/EIPS/eip-5646
Discussion - https://ethereum-magicians.org/t/eip-5646-discussion-token-state-fingerprint/10808
Slides - https://docs.google.com/presentation/d/1ATXANwMH4mQMD5iyedL4ppsRJY_tOxAoxLOlk05aa2g/edit?usp=sharing
ERCs Playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqXee9EMQDIEz2CslTnsW0K
PEEPanEIP - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Questions for Guests - https://docs.google.com/forms/d/e/1FAIpQLSdsmujnH_ncIlSEJ23s9jzXAKwfpTGNeJqjREWPloBbkJVQTA/viewform
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Follow at Twitter
-----------------------------------------------
Naim Ashhab @ashhanai | Will @wschwab_ | Blaine Malone @blainemalone | Pooja Ranjan @poojaranjan19
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/ethereumcatherders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/
A
D5
or
decentralized
Finance
is
another
very
popular
stream
of
blockchain
Technology,
the
availability
of
D5
protocols,
open
doors
for
many
to
invest
and
trade
cryptocurrencies.
It
will
be
interesting
to
understand
the
know-how
of
protocol
development
if
you
are
a
default
protocol
developer
and
interested
in
learning
about
standards
proposed
for
token
State
fingerprint
continue
watching.
A
Welcome
to
P
penit
episode,
90
ASI
is
dedicated
to
ethereum
Improvement
proposal
for
protocol
development.
I'm
your
host
Pooja
London.
In
this
special
episode
on
D5,
we
will
learn
about
eib
5646
token
State,
fingerprint
with
name
a
shop
name.
Is
the
author
of
the
proposals
and
a
developer
at
pwn,
a
D5
protocol
on
ethereum
mainnet
to
unlock
peer-to-peer
lending
using
any
token
as
collateral
nfts
included,
EAB
5646
was
created
on
September
11th
and
is
currently
in
review
status.
A
A
B
Yes
sure
so
hello,
my
name
is
the
name
I'm
a
smart
contract,
deaf
at
Pawn
Pawn
is
a
peer-to-peer
Landing
protocol
on
ethereum,
mainnet
and
and
polygon,
and
it's
try
to
be
as
open
as
possible.
So
you
can
use
any
standard
token,
which
is
erc20
721
1155
as
a
collateral,
and
there
is
no
white
list.
So
if
you
can
find
a
lender,
you
can
borrow
a
money
and
proceed
with
a
loan.
A
bit
about
my
myself.
I
studied
computer
science
at
the
Czech
Technical
University
in
Prague.
B
B
Perfect
so,
let's
just
briefly
say
what
I'm
going
to
talk
about.
First
it
will.
We
will
talk
about
types
of
token,
based
on
on
a
state
mutability.
Then
we
will
talk
about
some
challenges
of
supporting
mutable
tokens.
We
will
ask
a
question:
if
we
even
need
a
standard
for
that,
then
we
will
show
some
existing
attempts.
B
B
So,
first
of
all,
you
have
a
tokens
without
any
state.
This
is
basically
token
without
any
additional
data
stored
on
chain.
All
you
need
to
know
is
a
token
ID.
If
you
are
the
owner,
you
have
all
the
value
of
the
of
the
token.
Some
examples
are
the
most
known,
pfp
nft
collection
as
board
AP,
Art,
Club,
crypto,
Punk
or
co-ops.
B
Then
you
have
tokens
with
with
the
state
which
is
immutable,
so
the
token
holds
some
additional
data
mapped
to
the
to
the
Token
ID
on
chain,
but
they
are
not
changed
during
the
life
cycle
of
the
token,
so
they
are
set
on
the
Main
and
that's
basically
it.
You
can
imagine
some
example.
Examples
as
a
static
token
bundle
where
the
the
bundler
itself
stores
the
area
of
the
assets
which
the
bundle
ID
holds.
B
B
You
can
imagine
a
metaverse
land
where
the
parcel
ID
is
the
same,
but
what
you
build
on
the
land
is
a
is
a
different
or
some
Dynamic
token
bundle
where
this
is
like
a
modern
approach
to
that,
where
you're,
basically
like
a
deploy
a
proxy
and
you
tokenize
just
the
ownership
okay,
so
we
will
talk
about
the
mutable
tokens.
So
what
are
the
challenges
of
supporting
these
mutable
tokens
in
the
D5
protocol?
Let's
show
it
on
an
example.
B
What
the
holder
of
the
lp
token
can
currently
do
is
to
withdraw
the
the
whole
liquidity
so
basically
leaving
the
the
token
empty
without
invalidating
the
offer,
so
the
offer
is
still
still
valid
and
the
the
holder
can
can
accept
it
and
if
he
accepts
the
the
offer,
the
seller
basically
rocks
the
buyer
right,
so
buyer
bought
an
empty
LP
token,
with
zero
value
for
20..
So
that's
definitely
something
we
want
to
protect
our
our
users
from
so
yeah.
B
This
is
the
issue
for
most
of
the
D5
protocol
these
days
and
it
could
be
a
Marketplace.
It
could
be
a
lending
protocol.
It
could
be
an
option
protocol
just
name
it,
basically
anything
where
there
is
some
kind
of
offer
and
you
are
trying
to
like
Identify
some
token,
which
is
the
problem,
because
currently
you
identify
a
token
with
the
contract
address
and
token
ID.
If
you
are
talking
about
nfts,
because
these
are
the
standards
right,
the
RC
721,
that's
that's.
What
we
use
mostly
or
1155
is
somebody.
B
Somebody
wants
to
use
this
standard
team.
So
if
Marketplace
want
to
solve
this
issue,
it
would
need
first
to
know
that
the
token
is
is
mutable
because
from
the
protocol
perspective
it's
valid
ERC
721
token.
So
there
is
no
reason
for
the
protocol
to
to
manage
it
differently
than
any
other
any
other
token
so
yeah
first,
it
needs
to
know
that
this
token
is
mutable,
and
that's
it's
not
enough
that
the
contract
address
a
token
ID
is
used
as
an
identifier.
B
B
But
this
brings
like
obvious
bottleneck
because
protocol
we
need
to
support
any
mutable
token
one
by
one
specifically,
which
does
not
scale
and
that's
something
we
don't
want
to
do
so,
yeah,
just
to
sum
it
up.
What
we
need
right
now
is
to
add
some
additional
data
to
the
way
how
we
identify
tokens,
specifically
the
mutable,
the
mutable
ones.
So
next
to
the
contact
address
and
the
token
ID,
we
need
some
additional
State
data,
and
with
that
now
we
can
work
and
and
problem
a
question
what
we
are
trying
to
solve.
B
So
how
do
unambiguously
identify
a
token
State
without
the
knowledge
of
an
implementation
details
if
we
divide
divide
this
sentence
into
two
parts,
the
first
is
how
to
unambiguously
identify
a
token
State.
This
is
basically
saying:
hey,
I,
really
like
don't
care
what
the
state
is.
I
just
want
you
to
give
me
different,
State
different
identifier
for
a
different
states
and
same
identifier
for
the
same
state
and
the
second
part
without
the
knowledge
of
an
implementation.
Details
is
I,
don't
care
what
the
state
is
like.
B
Yeah
I
want
to
I
want
to
work
with
any
mutable
token,
the
same
way
I
don't
want
to
distinguish
between
them
so
yeah.
Now
we
have
the
the
question
the
issue,
the
thing
we
are
trying
to
solve.
We
can
look
at
the
example
of
erc20.
What
the
erc20
actually
did
is
creating
or
creating
an
agreement
between
basically
a
token
and
D5
protocols
about
what
the
token
will
Implement,
how
the
minimum
API
will
will
be
implemented.
B
B
It's
saying
these
are
the
requirements,
so
the
D5
protocols
can
work
with
any
token
implementing
erc20
the
same
way
so
for
the
token
death,
if
I,
Implement
erc20
token
I
know
that
any
D5
protocol
which
works
with
these
type
of
tokens,
Can
support
my
token
out
of
the
box,
which
is
great,
but
without
the
standard
the
D5
protocols
would
have
to
support
the
tokens
one
by
one
figure
out
what
transfer
function
they
use
if
they
even
have
the
approval
and
so
on,
and
so
on.
So
again
it
doesn't
scale.
B
B
With
with
the
standard
you
can
do
the
same
thing
as
as
with
erc20
or
erc721.
You
can
just
ask
if
the
token
implements
the
standard
and
then
use
the
defy
defined
interface
to
interact
with
it.
So
this
is.
This
is
great.
This
is
the
the
money
Lego
narrative
we
want
to.
We
want
to
push.
This
is
something
which
scales
perfectly
so
yeah.
Let's
aim
for
that.
B
There
were
already
some
existing
attempts
to
to
do
that.
First,
I'll
talk
about
token
implementing
some
sort
of
State
hash
function,
so
I
found
two
your
projects
Blockheads
and
mokens,
where
blog
heads
defined
token
metadata
hash
function,
which
returns
some
some
some
sort
of
identifier
of
the
of
the
state
and
moken's
get
State
hash,
which
is
doing
basically
the
same
thing.
Unfortunately,
these
two
projects
are
not
aiming
to
standardize
these
functions.
B
B
B
The
pros
of
this
proposal
was
that
buyer
can
specify
which
attributes
he's
interested
in
so
let's
say,
buyer
wants
to
buy
cryptokitty
and
he's
saying:
hey,
I'm
I'm
interested
in
this
this
and
this
property,
and
this
is
the
offer,
and
you
cannot
change
this
property
or
the
offer
it
will
be
invalid.
You
can
change
anything
else,
but
not
these.
Not
this.
Not
this
set
of
properties.
B
B
Another
attempt
was
EIP,
1948
called
non-fungible
Data
token
from
the
EIP
non-fungible.
Tokens
are
extended
with
the
ability
to
store
Dynamic
data.
This
is
really
almost
what
we
were
looking
for.
This
almost
solved
the
problem
with
the
unambiguous
identifier,
State
identifier,
so
it
can
be
almost
used
as
a
unified
ABR
for
mutable
tokens
with
the
the
read
data
function.
Unfortunately,
in
this
spec
there
is
also
a
write
data
function,
which
stores
the
new
state
hash.
B
B
B
This
interface
also
has
to
implement
DRC
165
to
be
discoverable
by
the
defy
protocols
great.
So
this
EIP
doesn't
specify
how
to
compute
a
state
fingerprint
the
state
fingerprint
can
be
stored
or
computed
in
a
contract.
It
really
depends
on
the
on
the
needs
of
the
devs.
How
big
the
state
is,
what
exactly
is
is
stored
or
computed,
but
it
gives
the
devs
the
biggest
flexibility,
but
the
function
has
to
implement
some
requirements.
B
So
if
we
go
quickly
through
them,
the
get
State
fingerprint
function
must
return
a
different
value
when
the
token
State
changes
and
must
not
return
a
different
value
when
the
token
State
Remains
the
Same.
This
is
basically
the
first
part
of
the
of
the
problem
we
defined
previously
on
how
to
unambiguously
identify
the
state.
This
is
basically
saying
hey
for
the
same
value
return,
the
same
fingerprint
for
the
different
state
return,
different
fingerprint
cool
next
point
is
the
get
State
fingerprint
must
factor
in
all
parameters
that
might
change
the
state
of
the
token.
B
This
is
a
little
bit
poorly
phrased.
I
may
change
it
in
the
future,
but
what
I'm
trying
to
say
with
that
is
the
function
has
to
count
with
all
parameters
that
can
change
in
the
lifetime
of
the
of
the
token.
So,
basically,
it
doesn't
really
make
sense,
or
it's
unnecessary
to
compute
with
all
parameters.
I
will
have
an
example
later,
but
just
quickly.
Let's
say
you
have
a
state
with
eight
properties,
but
only
three
of
them
can
change,
and
five
of
them
are
like
static.
B
B
Okay,
let's,
let's
go
on
the
get
State
fingerprint
fingerprint
may
include
computed
values
such
as
values
based
on
a
current
timestamp,
for
example,
expiration
and
maturity
yeah.
This
is
self-explaining
and
the
last
is
may
include
token
metadata.
Uri
I
have
read
a
lot
of
discussion
about
the
metadata
URI
and
a
lot
of
like
approaches
which
I
found
in
the
context
of
of
research
or
in
the
research
for
the
for
this
EIP.
They
were
including
the
metadata.
B
So
if
some
token
decides
to
use
the
this
state
fingerprint
for
the
metadata
yeah,
why
not?
It
can
be
if
it's
part
of
the
state,
if
it's
considered
part
of
the
state
go
for
it
and
the
last
but
not
least,
the
supports
interface
with
this
concrete
hash
must
return.
True,
this
is
basically
saying
hey
it
is.
It
has
to
implement
the
ERC
165,
and
this
hash
is
the
interface
ID
of
the
eip5646.
B
Nothing
more
I
cannot
stress
this
enough,
so
I
created
a
standalone
slide
for
that,
but
do
not
use
State
fingerprint
as
a
sole
token
identifier.
It
has
to
be
used
with
combination
of
contract,
address
and
token
ID
to
to
act
as
a
token
identifier
of
a
of
a
mutable
token.
Okay,
so
again
don't
use
it
as
a
sole
token
identifier.
It's
not
a
build
for
that.
B
This
is
example
of
a
token
bundler
or
token
bundle
ownership.
Token.
So
let's
say
you
have
a
you,
have
a
bundler
which
is
deployed
as
a
as
a
different
proxy
and
you
are
tokenizing
just
the
ownership,
so
the
owner
of
this
token
can
actually
withdraw
something
from
the
from
from
the
bundle
it
has.
Two
properties
is
locked
and
announced.
B
I
probably
will
not
go
through
why
it's
here,
but
you
can
ask
later
if,
if
you're
curious,
but
the
state
fingerprint
will
look
basically
like
this,
so
the
state
fingerprint
is
basically
just
a
hash
of
encoded
values
of
this
is
locked
flag
and
and
the
nuns
and
that's
everything
you
need
from
that.
With
this
implementation,
any
D5
protocol
working
with
assets
implementing
ERC
5646
can
safely
use
this
bundle,
ownership
and
sell
it
use
it
as
a
collateral
in
the
landing
protocol.
B
Another
example
is
a
loan
token,
so
this
loan
token
represents
a
loan
in
a
peer-to-peer
lending
platform,
and
you
have
a
mapping
which
is
loan
ID
to
a
loan
struct.
The
loan
struct
represents
the
state.
The
state
has
several
properties.
First
is
status,
borrower,
expiration,
late
repayment
enabled
flag
some
struct
for
credit
and
collateral
assets.
You
can
see
that
there
is
just
two
properties
which
are
mutable.
It's
the
status
and
late
repayment
enabled
the
borrower
address
and
expiration
the
credit
and
collateral
assets
are
immutable.
B
So
in
the
state
fingerprint
function
you
don't
have
to
include
all
of
them
because
yeah
they
will
never
change.
So
you
can
save
gas
here,
and
you
can
see
that
on
the
first
line
there
is
the
the
status
on
the
third
line.
There
is
the
late
repayment
enabled
flag
and
on
the
second
line,
there
is
a
condition
or
we
are
Computing.
This
like
computed
property
called,
is
expired,
so
if
the
status
is
two
and
the
loan
expiration
date
is
in
the
past,
we
consider
this
loan
expired.
B
So,
even
though
nothing
happened
on
chain,
nothing
changed
in
the
stored
values.
The
state
fingerprint
can
change,
because
the
time
passed,
the
block
timestamp
is
bigger
and
the
loan
is
is
expired.
Okay.
That
was
it.
Thank
you
for
everything
and
if
you
want
to
read
more
about
the
EIP,
please
go
to
the
EIP
dot
ethereum.org
pages
or
to
ethereum
magicians.org,
and
please
leave
a
feedback.
A
Thank
you.
It
was
a
nice
presentation.
Thank
you
for
sharing
that
I
hope.
Many
others
like
me
will
find
this
helpful
to
learn
about
how
this
works
and,
of
course,
the
proposal
so,
generally
speaking,
review
is
a
status
on
the
EAP
standardization
life
cycle,
where
we
hope
to
share
information
about
The
Proposal
with
the
community
and
collect
constructive
feedback
to
help
the
proposal
become
a
standard.
So,
as
you
already
have
shared
the
link
to
the
fem,
hopefully
we
will
get
some
more
comments
over
there
and
we
see
this
proposal
moving
forward.
A
C
Sure
actually
great
presentation,
I
was
when
I
want
to
ask
you
a
few
questions
just
about
the
design
I
mean,
which
you
touched
on,
of
course,
but
with
returning
at
bytes
32..
So
like
you
like,
you
demonstrated.
The
idea
is
that
you
can
basically
catch
act
after
Avi
encoding
the
relevant
details
and
that
way,
you're
able
to
have
one
data
type,
that's
being
returned,
but
I
was
wondering.
If
maybe
you
could
try
and
walk
through
the
rationale
on
the
usefulness
like
using
your
example.
C
Let
me
just
take
a
look
over
here,
so
lunds.states
loanstat,
oh,
was
that
oh,
it's
status,
isn't
it
sorry
I
just
need
to
make
my
screen
a
little
bit
bigger
here
and
then
catch
hack
it
and
then
call
and
then
see
if
what's
being
returned,
is
the
same
bytes
32
that
they
expected
to
be
I'm.
Getting
a
bit
long-winded
here.
B
Yeah
I
think
I
understand
what
you're
asking,
even
though
the
state
fingerprint,
if
you
know
the
implementation
details,
is
deterministic,
it's
not
meant
to
be
deterministic
in
a
way
that
the
front
end
will
actually
build
the
state
and
use
it
in
the
in
the
offer.
This
is
meant
to
be
at
the
time
when
the
buyer
is
is
creating
an
offer.
It
will
ask
the
contract
for
the
state
fingerprint
and
include
it
in
the
offer.
It
will
identify
the
token
at
the
time
of
creating
the
offer
or
signing
the
offer.
B
C
B
Yeah
exactly
and
you
don't
need
to
know,
that's
the
part
of
the
of
the
problem
that
we
want
to
like
be
able
to
identify
mutable
tokens
without
knowing
the
implementation
details.
So
if
we
take
example
of
ERC
721,
you
also
don't
know
what
the
token
ID
represents
there
right.
There
is
some
metadata
which
are
off
chain,
or
there
are
some
data
which
are
stored
on
chain,
but
still
you
identify
the
token
by
the
contract
address
and
token
ID,
even
though
you
don't
know
what
exactly
it
represents.
B
You
need
some
additional
informations
for
that
right,
so
this
standard
is
aiming
just
to
like
take
a
snapshot
of
the
state
in
a
in
a
to
protect
basic,
basically,
the
buyer
or
the
lender.
So
the
the
holder
of
the
token
cannot
change
the
state
and
then
accept
the
offer.
So
the
offer
is
only
valid
for
the
state
at
the
time
of
creating
that
offer.
So
maybe
to
answer
you
will
have
to
take
a
look
into
the
token
at
the
time
when
you
are
creating
the
offer.
B
C
It
I
think
so
I
mean
if
I'm
understanding
you
right
you're
talking
about
an
integrate
like
the
integration
concerns,
which
is
that,
in
order
to
integrate
one
of
these
tokens,
the
only
thing
they
need
to
know
ERC
165
Returns,
the
right
for
by
returns,
true
on
the
right
for
byte
sequence,
and
then
they
can
assume
there's
a
get
State
fingerprint.
So
integrating
becomes
very
easy
because
they
know,
like
it's
very
predictable.
C
What
they're
getting
back
I
think,
what's
bothering
me,
the
most
is
I'm
sure
you've
got
a
good
answer
for
this,
like
I'm
in
bothers
and
I.
Think
I
have
like
some
crazy
question
here
or
anything
like
that
is
at
that
point
that
we've
kind
of
reduced
everything
down
to
about
32
hash.
How
useful
is
the
hash
like?
What
does
the
hash
become
useful
for.
B
C
B
I,
don't
need
to
know,
what's
changed,
I
just
need
to
know
that
it
changed.
If
I
would
like
to
know
what
exactly
changed,
then
I
would
need
to
know
the
implementation
details
right
and
that's
the
part
I
I
said
I,
don't
want
to
know
I
want
to
like,
as
as
one
as
general
as
possible,
so
yeah
basically
the
same
thing
as
the
as
the
erc721
you
have.
You
can
have
additional
data
stored
to
the
Token
ID
right.
B
Even
if
we
don't
have
this
get
State
fingerprint
function
you
you
know
there
is
some
loan
which
has
stored
this
status,
borrower,
expiration
and
so
on,
but
you
don't
like
need
that
to
identify
the
token
like
the
erc721
is
not
saying
anything
about
additional
data,
and
this
this
EIP
or
ERC.
5646
is
just
about
like
having
the
tools
to
distinguish.
If
the
state
changed
or
not.
B
For
answering
that
yeah,
the
the
EIP
1180
I
mentioned
before
I
think
they
were
trying
to
actually
like
solve
I.
Think
the
problem
you
have
on
your
mind
that
the
the
buyer
or
the
lender
can
specify
what
exactly
can
change
and
what
cannot
change
so,
for
example,
in
in
this
like
loan
token
I
as
a
buyer
can
say:
hey
I
want
the
status
to
be
the
same.
I
want
the
loan
to
be
or
not
to
be
expired,
but
I
don't
care
if
the
late
repayment
enabled
flag
is
changed
or
not.
D
C
D
D
Her
name,
that
was
a
great
presentation.
I,
am
still
trying
to
get
kind
of
to
understand
the
the
attack
Factor
here.
So
you
know
that
I
get
that.
Basically,
the
rug
can
be
pulled
out
from
underneath
you
between
like
getting
this
nft
and
then
when
you're
gonna
sell
it.
So
I
just
want
to
like
understand
that
attack
a
little
bit
more
like
what
would
the
adversary
do.
B
This
basically
yeah
that
one
yeah,
so
imagine
part
of
the
offer,
is
identifying
what
you
are
trying
to
buy
right
So.
Currently,
you
can
identify
any
token
by
a
contract
address
and
the
token
ID,
because
that's
the
standards
for
that.
Otherwise
you
would
need
to
know
the
implementation
details.
So,
if
you
want
to,
if
you
want
to
sell,
for
example,
the
uni
uni
swap
V3
LP
NFD
on
openc,
and
somebody
gives
you
an
offer,
you
can
withdraw
all
the
liquidity
and
not
change
the
token
ID
nor
the
contract
ad.
B
D
Yeah,
sorry,
so
does
that
come
down
to
like
the
Block
Level
ordering
of
transactions?
So
let's
say
I
I
said
someone
wants
to
sell
their
LP
token
and
then
I
place
a
buy
order.
The
the
seller,
who
is
like
evil
in
this
case,
wants
to
basically
put
their
withdrawal
transaction
just
before
my
buy
transaction
is
that
is
that
sort
of
what
we're
talking
about.
D
Yeah
and
then
I
guess
the
other
question
was
it
sounds
like
the
implementer
of
this
EIP
needs
to
kind
of
be
careful
about
using
these
like
variables
that
can
change
without
them
kind
of
realizing
so,
for
example
like
if
they
did
use
like
block
time
stump
in
there,
which
changes
all
the
time,
then
they
might
invalidate
an
order
accidentally
that,
like
maybe
the
block,
timestamp,
wasn't
actually
kind
of
meant
to
be
there.
It.
B
D
B
Yeah
yeah,
definitely
it's
the
responsibility
of
the
implementer
to
do
it
responsibly.
Right
you,
if
you
put
the
block
timestamp
directly
into
the
state
fingerprint
this
state
fingerprint
will
be
different
for
basically
every
time
if
you're,
not
asking
in
the
in
the
context
of
one
block
right,
so
you
can
use
the
Block
timestamp
in
part
of
like
a
condition
which
is
used
here,
but
not
directly,
because
then
it
would
not
make
sense,
it
will
always
change
and
basically
any
offer
created.
This
way
like
using
the
ERC
5646
would
basically
fail
would
be
invalid.
B
A
B
Yeah
I
put
it
into
the
ethereum
magician
discussion
post
as
an
open
question,
because
at
the
one
hand
it
makes
sense
to
trigger
or
emit
an
event
for
for
the
UI
to
know
that
the
state
fingerprint
did
change,
but
on
the
other
hand,
for
example,
here
you
can
see
that
the
state
fingerprint
can
change,
even
though
there
is
no
like
transaction
involved.
So
I
wasn't
really
sure
if
I
was
want
to
give
this
false
sense
of
security
that
it's
going
to
be
triggered
every
time.
B
A
A
All
right,
my
next
question
is
about
proposal
implementation.
You
did
mention
about
couple
of
projects
who
are
implementing
IIT,
Blockheads
and
more
cons
that
you
mentioned
that
they
are
probably
implementing
it.
So
are
they
implementing
this
proposal
or
maybe
a
version
of
this
proposal
that
may
have
inspired
you
to
come
up
with
this
proposal.
B
No,
no,
they
are
not
implementing
this
proposal.
They
are
deployed
I,
think
several
years
now.
So
it's
just
the
like
Assurance
that
yeah
this
problem
exists
in
in
a
space
and
it's
not
like
standardized
yet.
So
there
is
a
lot
of
different,
or
at
least
two
different
implementation
of
the
same
thing.
So
if
we
want
to
support
them,
we
would
need
to
support
them
individually.
B
B
Yeah
yeah.
Basically
the
idea
is
the
the
same
as
you
have
an
official
wrapper,
so
you
will
have
official
state
fingerprint
computer.
It
will
be
like
a
standalone
contract
will
which
would
Implement
just
this
get
State
fingerprint
function,
but
it
will
count
the
state
fingerprint
from
or
already
deployed
like
token.
B
So
it
won't
be
part
of
that
token,
so
the
discoverability
will
not
be
there,
but
it's
some
like,
like
a
trade
of
like
a
workaround,
how
to
actually
implement
the
the
function
to
already
deploy
tokens
so
yeah
the
the
D5
protocols
will
still
have
to
have
some
kind
of
like
mapping
of
yeah.
This
deployed
Legacy
token
has
this
address,
which
implements
the
the
state
fingerprint
function
but
yeah
at
least
it's
some
way
how
to
how
to
do
that
after
the
deployment.
B
Honestly,
no,
this
EIP
came
from
the
issue
one,
so
we
want
to
support
mutable
tokens.
We
want
to
enable
mutable
derivative
tokens
to
be
used
on
the
platform
used
as
collateral
without
going
through
this,
like
hey
I'm,
losing
ownership
to
some
bundle
and
using
that,
so
we
want
to
make
it
more
like
native.
B
A
A
Sounds
good
like
having
a
prototype
or
a
real
project.
Implementation
definitely
gives
confidence
to
other
dab
Builders
to
adopt
a
CIP
and
also
to
the
EIP
editors
to
move
the
proposal
to
the
final
status.
So
it's
good
to
know
that
this
is
under
consideration
for
at
least
one
project.
Another
question
is
about
security.
Consideration,
though
this
proposal
seems
to
be
like
a
lighter
version
of
any
other
standard.
Is
there
any
special
security
consideration
that
dap
developers
might
want
to
consider
while
implementing
this
proposal.
B
Yeah
well
for
the
D5
protocol
developers.
They
should
not
use
it
as
a
sole
token
identifier
and
for
the
token
implementers
they
just
need
to
be
sure
that
all
the
mutables
mutable
State
properties
are
included
in
the
Computing
of
the
state,
fingerprint
otherwise
yeah
just
not
use
block
timestamp
directly,
because
then
you
will
have
always
the
the
different
state
fingerprint
and
other
than
that.
I
don't
think
there
is.
There
is
any
other
security
issues.
A
That's
a
good
piece
of
advice
depending
upon
the
kind
of
project
someone
is
working
or
developing,
may
consider
these
important
factors
to
implement
EAP
56
courses.
Well.
I
understand
this
is
the
first
proposal
that
is
coming
from
your
end
for
the
ethereum
repository
I,
wonder
if
you
have
any
thoughts
on
the
process,
if
that
you
would
like
to
share
with
us.
B
B
I
would
like
to
get
an
answer
to
when
you
can
actually
move
the
the
EIP
to
the
last
call,
or
what
does
it
mean
to
have
like
community
community
feedback,
because
yeah
I
understand
that
now
it's
it's
a
little,
but
what's
what's
the
the
threshold
there,
so
this
like
a
transition
functions,
could
be
defined
a
little
bit
better
but
other
than
that
I
think
yeah,
it's
it's
a
it's
a
fine
Journey!
It's
about
the
content!
More
than
than
the
process,
foreign.
A
That's
right
to
answer
your
questions
generally,
it
is
on
the
author
to
move
to
the
proposal
to
the
last
call
when
it
is
assumed
that
there
would
not
be
any
significant
specs
change
expected
with
the
proposal.
As
soon
as
an
author
gets
confidence,
they
can't
create
a
pull
request
to
move
it
to
the
last
call.
However,
with
respect
to
ERC
proposals,
the
general
recommendation
is
to
have
it
backed
by
some
kind
of
implementation
or
reference
implementation.
A
That
generally
helps
to
like
move
the
proposal
to
what
the
final
status
after
the
last
call.
There
is
a
wait
time
of
two
weeks
in
which
a
proposal
is
again
reviewed
by
EIT,
editor
and
obviously
by
community,
and
if
there
is
no
strong
recommendation
for
changes
coming
up,
then
the
proposal
is
moved
towards
funding
status
after
the
last
call
period
is
over
thanks.
B
A
Would
like
to
make
a
mention
here
that
I
found
that
that
this
proposal
is
making
a
very
good
use
of
discussion
to
thread
to
provide
the
background
related
information
to
help
readers
understand
why
this
proposal
needs
to
be
a
standard
good
rest
for
you
as
an
author,
that
you
try
to
be
respectful
of
the
ethereum
EIT
standard
repository
and
didn't
put
everything
in
the
dot
MD
file
yeah.
That
was
really
nice.
I
hope
many
other
authors
may
get
some
inspiration.
A
All
right,
it's
time
to
wrap
up
name.
We
appreciate
you
taking
our
time
to
join
us
today
and
share
about
the
upcoming
standard,
EIP
5646
token
State,
fingerprint
I
hope.
With
this
talk,
aspiring
tap
developers
may
have
learned
about
the
proposal:
application,
binary
interface,
the
ABI
and
the
importance
of
a
state
identification
of
a
derivative
token.
A
We
look
forward
to
have
increased
adaptability
of
this
proposal
and
the
proposal
to
be
moved
forward
to
the
panel
status
and
on
this
note,
thanks
to
everyone
watching
or
listening
to
this
special
episode
on
D5
standard,
should
you
have
any
question?
Let
us
know
in
the
form
available
in
the
description
or
leave
a
comment
or
reach
us
at
eat
cattle.
This
is
God
check
out
descriptions
for
links
to
useful
resources
and
guest
Twitter
to
follow.