►
Description
Today the NEAR Contract Standards Working Group met for the third time to vote on several proposals:
➡️ https://github.com/near/NEPs/pull/351
➡️ https://github.com/near/NEPs/pull/423
➡️ https://github.com/near/NEPs/pull/431
Meeting Summary:
https://twitter.com/NEARDevGov/status/1614076996606365698
Chapters:
00:15 Agenda
00:46 Update on Developer Governance
07:00 Introductions
09:16 NEP-351
26:53 NEP-423
35:52 NEP-431
45:38 Getting Involved
Learn about Developer Governance:
Website: https://neardevgov.org
Twitter: https://twitter.com/NEARDevGov
Telegram: https://t.me/NEARDevGov
NEP Process: https://github.com/near/NEPs/blob/master/neps/nep-0001.md
Join the Contract Standards Community Group:
Telegram: https://t.me/nearnft
Join NEAR's community:
Website: https://near.org/
Reddit: https://www.reddit.com/r/nearprotocol/
Discord: https://near.chat/
Medium: https://medium.com/nearprotocol
Blog: https://near.org/blog/
Twitter: https://twitter.com/NEARProtocol
GitHub: https://github.com/near https://github.com/nearprotocol
Dev Docs: https://docs.near.org/
Create a wallet: https://wallet.near.org/create
Apps on NEAR: https://awesomenear.com/
Learn to Build On NEAR: https://www.near.university/
Grants & Funding: https://near.org/grants/
#Blockchain #FutureisNEAR #NEAR #nearprotocol
#nft #dao
A
Everyone
welcome
super
excited
to
have
our
third
contract
standards
working
group
call.
My
name
is
Ori
and
I'm
a
technical
program
manager
from
Pagoda
and
just
to
go
over
the
agenda
for
today.
First
I
will
give
a
quick
overview
on
developer
governance
and
some
updates
that
we've
made
there
next
we'll
do
some
brief
introductions.
As
we
have
a
few
panelists
joining
us
today,
then
we
will
jump
into
the
main
discussion
in
f351
for
23
and
431,
and
the
links
for
those
are
on
the
invite
to
this
call
in
case.
A
You
want
to
follow
more
closely,
then
we
will
open
it
up
to
q
a
and
lastly,
we'll
talk
about
next
steps
and
how
you
can
get
involved
in
developer
governance,
we're
going
to
start
with
a
little
bit
of
background
on
developer
governance.
So
over
the
last
few
months,
we've
been
engaging
with
the
community
over
this
initiative,
which
is
really
about
bringing
people
and
organizations
together
other
to
help
build
a
decentralized
developer
ecosystem
and
we've
been
bucketing
most
of
the
developer
community
activities
into
four
buckets.
A
A
A
You
can
find
them
on
the
developer
governance
website
and
we're
also
going
to
publish
a
blog
post
really
soon.
That
will
highlight
some
recent
learnings
and
insights
from
some
of
those
groups.
So
what
if
you
already
have
submitted
an
idea-
and
you
want
to
turn
it
into
code-
that's
what
developers
do
right.
So
this
is
where
implementation
comes
in,
and
you
can
also
use
the
developer
governance
gigs
board
to
submit
an
implementation
solution
to
your
idea
or
if
you
have
an
alternative
solution
in
mind
for
somebody
else's
idea.
A
So
so
what
happens
once
you
submit
a
nap
and
how
does
it
actually
move
forward?
So
this
is
where
the
review
comes
in,
which
involves
the
working
group,
like
the
contract
standards
working
group
that
we
have
here
today
and
the
working
group
is
basically
a
selected
Committee
of
subject
matter.
Experts
that
help
review
proposals
in
a
furly
and
timely
manner
and
oversee
decisions,
and
there
are
multiple
working
groups,
each
one
focusing
on
a
different
ecosystem
need
and
we've
already
kicked
off.
A
Four
of
those
groups,
who've
helped
to
bootstrap
the
net
process
and
we've
been
iterating
on
those
over
the
last
few
months
to
learn
what
works
and
what
doesn't,
and
we
hope
to
continue
to
introduce
more
groups
in
the
future
and
empower
the
community
to
run
them
and
iterates
further.
So
yeah
I
just
wanted
to
go
a
little
bit
into
the
roles
that
are
involved
in
the
net
process
and
then
we'll
jump
into
the
to
the
call.
A
So
first
we
have
the
the
author
or
champion
this
is
the
person
who
writes
the
proposal
and
presents
it
to
the
working
group.
Then
we
have
the
moderator
the
person
who
facilitates
the
process
and
helps
helps
validate
that
the
proposal
meets
the
guidelines
and
and
progresses
forward.
We
have
the
reviewer
the
subject
matter:
experts
who
review
the
technical
feasibility
and
then
the
working
group
member,
the
approvers,
who
helped
make
the
final
decision
and
there's
a
diagram
on
the
nep001
that
illustrates
the
process.
A
Now
most
of
this
happens,
asynchronously
on
the
net
itself
within
GitHub,
but
when
we
do
get
to
the
voting
stage,
each
working
group
has
a
public
meeting
to
discuss
the
neck
with
the
author
and
to
formalize
the
decision
and
that's
exactly
what
we're
doing
today
we're
looking
at
three
different
maps
that
are
in
the
voting
stage
and
lastly,
I
just
want
to
talk
about
what
happens
when
an
app
actually
gets
approved
and
how
can
the
implementer
seek
seek
funding?
And
so
this
leads
us
to
the
last
area,
which
is
support.
A
So
this
was
a
lot
of
information
in
a
very
short
amount
of
time,
so
just
to
make
it
easier.
There's
a
blog
post
that
you
can
check
out
later.
That
goes
into
more
detail
on
the
on
the
developer
governance
website.
So
with
that
I
want
to
officially
get
into
the
contract
standards
call
and
start
with
introductions.
So
I'd
like
to
introduce
the
official
contract
standards
working
group
members
and
hand
it
over
to
Marcelo.
B
C
D
And
me
jumping
in
right
here:
I'm
Vlad
I
also
joined
me
in
here
when
it
was
quite
early
days
before
launching
my
net
for
sure
and
we've
been
work.
I've
been
working
on
different
projects
throughout
the
whole
landscape
of
in
here,
including
Explorer,
indexers
and
now
I'm,
very
Main
head
into
the
naps
and
dedicate
my
time
into
the
Wilbur
Gardens
full
time
happy
to
be
here.
So,
let's
move
on
to
the
next
slide,
Lori.
A
Awesome
yeah
and
then
farat
is
unable
to
make
it,
but
but
we,
but
he
gave
me
the
content
for
for
the
slide
for
his
nap,
so
yeah
awesome.
Well,
let's
get
into
the
actual
enough
discussions.
These
are
the
three
naps
once
again
and
I'm
gonna
hand
it
over
to
Osman
to
just
give
a
little
bit
of
a
author
summary.
You
know
of
the
snap
and
then
we'll
get
into
the
discussion.
A
E
All
right
yeah,
so
this
snap
is
an
extension
to
an
already
existing
map
that
is
about
the
metadata,
that's
on
the
contract
and
currently
it's
very
focused
on
the
source
code.
So
there's
a
there's,
a
view
function,
that's
proposed
on
the
on
contracts,
that
is
called
contract,
underscore
Source
in
the
score
metadata
and
currently
the
the
existing
map.
330
proposes
that
you
get
back
the
version,
so
a
commit
hash
of
the
code,
that's
on
chain,
and
you
also
get
back
a
link
to
the
open
source
code.
E
So
basically,
what
this
map
this
extension
is
proposing
is
we
add
an
additional
key
to
this
structure.
That
is
a
list
of
of
naps
that
the
contract
adheres
to,
and
this
helps
with
things
like
if
you
want
to
know
like
what
methods
other
methods
to
expect
what
events
that
would
be
emitted
by
the
contract,
any
other
abstract
ideas
so
like
API,
might
fulfill
some
things
like
what
what
a
function
calls
exist
and
stuff
like
that.
E
But
this
this
will
allow
you
to
know
like
what
nuts
that
are
part
of
like
whether
it's
a
nap
or
another
standard,
even
outside
of
not
that
the
contract
adheres
to
so
that
if
you're
building
a
client,
you
can
build
it
around
that
and
you
can.
You
know
what
Behavior
to
expect
from
the
contract
and
it
proposes
it
just
an
array
of
a
map.
E
Basically,
that
has
a
standard
key
and
a
version
key,
so
you
can
see
it
at
the
bottom
that
I
could
like
just
standard
inversion,
and
it's
just
an
array
of
these.
So,
for
example,
nap
141
version
1.0.0
is
what
we
have
on
screen
there
so
yeah
very
simple,
just
an
extension
to
the
existing
view.
Call
that
tells
you
what
maps
are
available
that
whatnaps
the
contract
adheres
to.
A
D
It's
totally
optional
for
the
implementers.
If
somebody
already
implemented
nap
360,
then
it's
it's
not
breaking
those
contracts,
though
it's
definitely
beneficial
to
update
your
contracts,
if
possible.
With
this
new
feature-
and
it's
it's
just
super
nice
addition
to
to
this-
to
the
quality
of
life
of
contract
developers
that
want
to
build
composable
contracts,
so
we
also
explored
the
concerns
and
well
had
different
concerns.
D
It's
totally
fine,
like
XYZ
company,
could
decide
to
run
their
own
registry
of
of
standards,
and
that
would
be
a
bit
of
collision
and
like
and
unfortunately,
one
that
it's
it
wouldn't
be
supported.
That's
why
we
went
with
the
string
value
where
we,
we
recommend
people
to
use
nap
the
pattern
of
a
prefixing
map
and
then
a
number
so
nap,
173
and
XYZ
001
could
coexist,
and
it
would
be
totally
fine
for
contractor
support
like
standards
of
a
different
basic
sources,
which
is
super
nice
I've.
D
Seen
people
doing
this
for
Json
events.
They
didn't
you,
don't
need
to
register
your
own
Contracting,
your
own
needs
and
and
make
it
a
nap
in
order
to
to
emit
Json
events,
and
this
is
we
just
borrowed
the
pattern,
so
it's
aligned
and
also
quite
extensible
going
forward,
so
it
was
resolved.
Osman
took
another
look
and
addressed
it.
So
now
we
have
this
nice
flexible
interface.
D
D
D
I
think
it's
a
minor
thing
and
we
will
address
it
after
the
call
and
the
third
concern
that
was
raised
was
that
it
could
be
beneficial
to
have
Json
events
about
when
the
metadata
with
this
contract.
Source
metadata
is
changing,
but
it
was
decided
that
it's
outside
of
the
scope
of
this
snap
and
given
that
usually
the
source
metadata
changes
only
when
with
the
contractor
deployment,
that
could
be
the
basically
event
people
could
subscribe
for
and
once
the
code
is
redeployed,
just
check
this
contract
Source
metadata.
D
So
it
shouldn't
be
really
problem,
I
I
believe
and
it's
even
more
reliable
than
introducing
a
decent
event
that
expects
people
to
implement
it.
So
we
decided
to
postpone
it
and
probably
won't
fix
in
the
future.
So
the
these
are
the
ones
I
collected
from
pull
request
itself,
as
we
were
discussing
previously
with
the
previous
calls
of
the
working
group.
We
maintain
all
the
information
in
the
comments
or
on
the
GitHub,
so
there
is
nothing
new
here.
It's
just
a
summary.
D
We
encourage
you
to
review
the
naps
and
the
commit
a
comments
there.
If
you
have
any
other
additional
contexts,
so
we
don't
miss
it
and
don't
have
a
last
minute.
You
know
through
prizes.
So,
but
still
there
is
a
chance
right
now
for
last
time
to
maybe
highlight
something
that
we
totally
missed
and
that
could
be
a
potential
blocker
for
us
to
merge.
But
that's
basically
the
summary
or
do
you
want
to
to
to
take
a
word
and
say:
what's
gonna
be
the
next
steps
yeah.
B
D
D
A
A
D
So
there
is
a
need
for
design
and
better
tooling
around
it
like
on
the
on
the
sdks
level
and
then
on.
The
API
packages
like
in
in
your
api.gs
and
near
API,
Pi
to
you
know,
make
people's
developers
life
easier,
so
this
I
so
far,
I
haven't
heard
any
Champions
willing
to
take
this
snap
to
the
implementation
stage,
and
this
is
where
we
are
standing
right
now
in
terms
of
implementation.
So
let
me
just
walk
you
through
what
would
be
the
next
step
as
I
see
them
first.
D
Would
we
would
need
to
so
we
actually
were
looking
into
the
previous
experience
of
previous
previous
snaps.
It
seems
like
it's
very
beneficial,
to
include
benefits
and
concerns
section
from
the
presentation,
the
summary
into
the
map
itself
for
the
future
reference.
So
those
who
would
read
this
the
nap
itself
years
ahead
would
have
a
chance
to
understand
what
were
the
limitations,
what
we
considered
as
a
problem,
what
we
decided-
it's
not
a
problem.
So
ideally
we
want
to
embed
this
section
in
the
nav
documents
going
forward
and
Osman.
D
So
it
would
be
great
to
have
a
change
log
in
the
in
the
nap
itself.
So
it's
another
change
in
the
pull
request,
but
well,
given
that
nap
is
already
approved,
it
I
feel
like
it's
just
final
polishing
steps
and
then
once
that
is
done
by
Osman
as
author
of
the
nap
or
by
moderators
we
already
and
I
will
jump
in
as
a
map.
D
D
This
whole
process
is
getting
improved
over
time,
and
this
is
the
next
iteration
of
it.
As
you
may
see,
we
have
a
more
clear
structure
here
and
like
better
understanding
what
what
needs
to
be
done.
Next,
we
are
stepping
into
the
area
where
we
leverage
gigsport
more
and
more
these
days,
so
expect
to
see
engagements
over
there.
A
Yeah,
this
was
great,
thank
you
so
much
for
for
clearly
laying
this
out
for
everyone.
I
guess
before
we
move
on
to
the
next
step.
I
just
wanted
to
ask
I
know
there
are
several
attendees
on
the
call
like.
Is
there
anyone
who's
potentially
interested
you
know
and
and
implementing
this
snap?
Taking
this
this
on
or
being
involved
in
any
of
these
next
steps,
or
are
there
any
questions.
A
E
C
A
C
D
C
C
I
am
in
favor
of
the
snap,
because
I'm
repeating
what
I
said
you
there
is
a
need
for
developers
to
know
which
features
contracts
Implement
and
without
something
like
what
is
proposed.
They
will
try
character,
heuristics
like
trying
to
call
some
functions
and
check
what
works,
and
this
can
be
unreliable
so
having
some
something
like
this
is
instead
is
much
better
for
them
totally.
D
A
F
A
D
Yeah
so
well,
it's
an
again
very
nice
quality
of
life
improvements,
and
this
definitely
something
that
I
personally
was
also
hitting,
while
implementing
the
indexers
myself
and
also
needing
to
either
excessively
check
the
metadata
almost
at
every
single
block
or
a
hope
for
the
best
that
metadata
didn't
change
and
then
discussion.
Validation
problem
is
one
of
the
artist
ones
in
the
computer
science
area.
So
it's
very
nice
to
have
this
extension
to
the
events
on
the
nft
conflicts.
D
I
think
we'll
also
benefit
from
having
such
event
on
other
contracts
and
other
standards
going
forward.
This
is
a
this
thing,
paves
the
road,
I
feel
and
just
to
mention.
This
is
not
not
a
breaking
change,
so
all
the
previously
existing
contracts
will
behave
exactly
fine
and
nothing
is
changing
in
terms
of
the
expectations
to
them.
D
There
is
an
unfortunate
situation
that
we
have
all
the
nft
contracts
that
do
not
emit
any
adjacent
events
at
all,
and
there
are
current
nft
contracts
that
only
emit
mint
burn
and
transfer
events,
but
the
hope
is
that
eventually
the
new
contracts
will
will
be
upgraded
or
just
new
contracts
will
will
be
deployed
and
the
Legacy
contract
will
die
out
with
the
time
so
I
think
it's
not
a
blocker
for
us
to
consider
so
I.
Adding
this
event
will
definitely
help
us
down
the
road,
even
though
it
it
wouldn't
be.
D
The
immediate
help
for
us
and
the
other
concern
that
was
raised
in
the
comments
was
about
adding
a
similar
event
for
individual
nft
update.
So
when,
whenever
NF
like
each
nft
item
is
edited,
it
would
be
great
to
also
have
an
event
about
it,
but
it
was
decided
that
it's,
it
opens
up
too
many
other
questions
and
concerns
it's
better
to
split
the
it
into
two
different
discussions.
So
we
will
merge
this
one
first
and
then
potentially
discuss
the
another
event
added
to
the
nft
standard.
D
No
I
guess
so.
Basically,
from
my
point
of
view,
it's
only
beneficial
and,
as
I
said,
I
personally
wanted
to
have
such
an
event.
Once
I
Implement
started,
implementing
indexers
I'm
totally
aligned
with
the
with
the
goal
here
and
I
would
I
can
see
my
my
previous
team
benefiting
this
new
standards
and
Italy
see
no
downsides
right
now,
so
I'm
I'm
voting
for
approving
it
Marcelo
maybe
go
next
yeah.
C
And
I
also
lean
towards
approving
this
snap.
Just
with
the
pre
just
like
with
the
previous
snap
developers
need
this
functionality
and
without
the
standard
they
will
try
to
use
some
heuristics,
which
will
sometimes
work,
sometimes
not
work,
and
they
will
still
need
heuristics
for
older
contracts,
but
at
least
with
the
newer
contracts
which
implement
this,
it
will
work
reliably.
A
Cool
cool,
well
I'm,
hearing
unanimous
consensus,
so
it
sounds
like
this
is
the
snap
is
approved,
which
is
awesome,
yay
two
naps
in
the
same
day,
so
yeah
I,
love
that
comment
from
shot
like
the
new
ecosystem
has
changed
so
since
I've
gotten
involved
in
the
net
process,
like
I,
don't
recall
ever
being
having
two
nips
in
one
medium
that
we're
able
to
get
through.
So
definitely
a
lot
of
kudos
to
everyone.
That's
involved
in
in
this
process
and
helping
to
move
it
forward
and
for
anyone
who
might
be
new
to
this.
A
There
might
be
a
lot
of
steps
and
maybe
formalities,
but
really
we're
trying
to
make
it
very
transparent
and
and
to
evolve
this,
and
if
you
have
ideas
and
ways
that
we
can
make
it
better,
please
feel
free
to
to
share
them.
Okay,
so
in
terms
of
next
steps,
kind
of
oh
sorry,
kind
of
similar
to
the
other
one
but
glad
yeah.
D
F
D
Awesome
yeah,
but
still
other
tooling,
would
also
benefit
from
it.
So
we'll
we'll
see
we'll
still
post
a
a
call
to
for
Champions
on
the
Geeks
board
and
as
I
previously
already
mentioned,
I
I
would
love
to
to
ask
you
to
embed
the
benefits
and
concerns
and
introduce
change
a
lot
of
changelog
to
the
to
the
pr.
A
A
D
D
So
this
is
was
the
the
idea
and
yeah,
let's
jump
into
the
benefits
and
concerns
slides
the
well
after
after
the
discussion
in
in
nap
itself,
it
seems
like
there
are
other
ways
to
achieve
the
goals
and
also
the
the
the
goals
themselves
could
be
addressed
in
a
very
different
way.
To
begin
with,
so
I
spent
some
time
and
tried
trying
to
actually
encourage
the
benefits
of
this
specific
map.
D
It
was
actually
every
single
reviewer
highlighted
those,
and
we
basically
just
were
super
aligned
there,
that
this
map
does
not
solve
the
zero
cost
transfers
for
the
for
the
person
who
received
the
tokens
from
somebody,
they
would
still
need
to
submit
a
transaction
and
pay
for
the
US
in
order
to
create
this
allowance
to
set
it
up,
so
it's
not
zero
cost
at
all,
and
then
it
opens
it.
It
opens
up
a
question
like
how
to
do
how
to
what
to
do
with
with
the
allowance
amount.
D
D
B
Yeah
one
thing
is
that
the
fact
that
we
don't
have
free
that
here
it's
a
little
bit
bad
right.
It
would
be
good
to
have
one
Champion
from
the
comments
in
the
GitHub
I
guess
per
all
of
us
are
leaning
towards.
So
it's
good
to
have
someone
who
is
a
champion
this
map,
but
but
anyway,
I
do
agree
with
the
points
presented
by
Blood
and
I.
Think
it's
not
if
required,
to
be
implemented
in
a
separate
in
a
separate
contract.
C
So
I'm
also
thoughts
rejecting
the
snap
I
like
have
many
security
concerns
in
mind,
starting
from
some
race
conditions,
although
this
snap
is
trying
to
resolve
some
race
conditions
by
having
a
argument
to
the
function
that
that
allowance,
which
is
the
previous
allowance
so
potentially,
if
it
changed
like
this
function,
will
fail.
There
is
still,
but
but
then
it's
still
something
that
the
caller
needs
to
handle,
and
this
can
be
problematic,
like
this
handling,
can
be
incomplete
and
lead
to
some
security
issues.
C
But
it's
not
the
only
one
even
like
the
way
this
allowance
system
is
used
because
it
exists
on
ethereum.
We
have
some
real
world
usage
data
and
I've
recently
read
an
article
which
basically
told
people
to
look
which
contract
they
have
allowance
for
and
to
remove
it
if
they
don't
need
it.
So,
in
fact
people
tend
to
set
this
allowance
to
some
contracts
and
forget
about
it,
and
this
makes
kind
of
security
hole
in
their
wallets
and
we
don't
want
to
enable
like
encourages
this
kind
of
insecure
usage.
So
it's
better.
C
D
Yeah
and
me
myself,
as
I
already
mentioned,
I'm
leaving
leaning
towards
to
rejecting
as
well.
So
it
seems
like
we
have
again
Union
decision
of
rejecting
it.
This
time,
yeah
so
I
think
it's
great
that
we
have
a
full
packed
agenda
for
today
with
three
naps,
even
though
not
all
of
them
are
getting
approved,
it's
very
important
step
to
review
all
of
them
and
make
it
make
it
clear
the
reasons
why
we
are
making
this
sort
of
that
decision
here.
A
Yeah,
no
so
it
sounds
like
we
have
the
decision,
which
we
will
definitely
formalize
on
the
net
as
well.
I
think,
just
in
terms
of
the
next
steps
for
this
one,
it
seems
like
we're
just
gonna
do
that
exactly
on
the
net
and
then,
if
anybody
is
interested
in
picking
any
of
this
up,
you
can
always
start
with
a
new
idea,
a
new
nap
and
I
purchased
from
a
from
A
New
Perspective.
A
A
Yeah
well,
so,
just
to
I
guess
close
off
I
do
want
to
highlight
some
ways
that
you
can
get
involved
really
quickly.
So,
as
I
mentioned,
the
gigs
board
is
a
really
good
place
to
to
get
started.
If
you
have
a
specific
idea
in
mind,
you
can
go
there
and
submit
it
or
start
responding
to
other
people's
ideas.
You
can
also
add
a
solution
or
implementation
details
to
those.
A
If
you
are,
if
you
have
an
idea
that
you
want
to
get
integrated
across
the
ecosystem
or
you're
seeking
funding,
you
will
also
need
to
submit
a
nap
after
you
have
that
idea
on
the
gigs
board.
So
you
can
do
that
on
gig
on
GitHub.
You
can
also
go
and
view
all
of
the
naps
and
in
the
various
statuses,
on
GitHub
and
join
the
discussion.
A
There
is
a
community
group
as
well
for
contract
standards,
so
you
can
join
that
to
just
seed
ideas
or
connect
with
others,
and
you
can
learn
everything
about
developer
governance
on
our
website
side
and
our
social
accounts,
and
we
definitely
have
a
lot
more
coming
and
we
plan
to
continue
to
iterate.
You
know
and
make
this
whole
ecosystem
better,
so
yeah.
A
Lastly,
I
really
want
to
give
a
huge
shout
out
again
to
everyone
who
has
been
involved:
the
authors
of
those
three
naps
Osman
Lachlan
and
firat,
the
working
group
members,
Marcelo,
Evgeni,
Vlad,
the
subject
matter:
experts
who
helped
do
the
technical
assessments,
so
Robert,
Olga
and
and
everyone
else
who's.
Just
a
part
of
this.
It
really
is
a
community
effort.
So
thank
you.
So
much
and
with
that
I
want
to
wish
you
all
a
great
weekend
and
reminder:
there's
a
there
are
two
working
group
meetings
happening
next
week,
so
please
join
them.