►
Description
The Antelope Coalition updates the community on rebranding, IBC/FF, Wallet SDK, P2P RFP, Block explore and more!
00:00:00 Start
00:00:05 Rebranding to Antelope
00:01:28 IBC/ FF update
00:09:57 Wallet SDK update
00:16:12 Status of GitHub migration
00:19:50 Documentation on Antelope
01:23:50 P2P RFP update
01:26:53 Legal entity for Antelope
01:35:03 Scalability+ bluepaper update
01:38:39 Block explorer and Top 21 reprioritization
02:08:52 End
Everything EOS is the official media channel of the EOS Network Foundation (ENF). The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.
// EOS Network Foundation //
https://www.eosnetework.com
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosnetwork.com
#EOS #EOSIO #ENF
A
A
B
E
A
So
but
but
new
name,
many
people
excited
and-
and
it's
a
great
start
for
for
our
our
future
and
future,
so
awesome
we're
here
so
back
to
business.
We
wanted
to
talk
about
the
ibc,
faster
financiality
vote
and
contract.
We
did
have
some
initial
discussions
about
how
we
would
vote
on
this
today
and
how
we
would
go
forward
because
there
are
basically
three
signers
required
for
a
contract.
A
So
so,
even
if
we
vote
for
for
doing
this,
it
is
more
like
stating
the
intent
to
sign
the
contract
and
move
forward
with
this
so
years.
Eve
just
put
out
that
he
would
generally
confirm
the
intent
to
sign
the
contract
as
long
as
it
is
sure
that
the
it
right
ip
rights
and
and
license
are
secured
for
any
code
base,
that's
being
produced
and
merged.
So
you
wanna
kind
of
outline
this
a
little
more.
D
A
G
And
for
the
record
darren
and
I
discussed
and
we're
in
agreement,
we
would
essentially
suggest
each
milestone,
gets
reviewed,
approved,
paid,
open
sourced
and,
like
basically
open
source
on
their
mit
license.
So
essentially
anything
that
gets
produced
is
automatically
you
know
like
made
available
under
mit
and
can
be
merged
with
the
code
base.
D
D
E
E
F
G
E
G
E
D
E
D
E
D
A
A
D
D
D
B
D
A
E
C
A
Excellent,
so
wax
we
will
reconfirm
with
with
lucas
in
telegram
chat,
but
we
reach
quorum.
So
we
will
continue
and
would
like
to
discuss
with
or
have
the
final
approval
from
wax.
But
I
don't
personally
think
he
would
have
any
objections,
because
the
the
signs
and
comments
that
he
made
in
previous
meetings
and
regarding
this,
this
documentation
and
proposal
was
always
positive.
So
I
assume
he
will
vote
yes,
but
I
will
verify
with
them
after
the
meeting.
D
And
for
clarification
as
well,
I
I
do
believe
that
wax
would
vote
yes
on
this,
but
should
we
be
in
a
position
where
not
all
chains
agree?
We
do
not
need
under
current
governance
mechanisms.
We
do
not
need
unanimity
in
in
order
to
proceed
as
much
as
that's
nice
and
it's
pretty
much
been
the
case
every
time
just
put
that
out
there
for
those
listening.
A
Yes,
we
will.
We
have
quorum
based
on
the
three
chains
voting.
Yes,
so
we
will
continue
with
the
developments
and
are
happy
that
aaron.
Finally,
you
can
start
doing
the
things
that
you've
been
working
on
for
so
long.
So
that's
great
everybody's,
anticipating
that
and
waiting
for
you
to
to
start
and
deliver
those
things.
F
E
As
you
know,
I
mean
you
know,
you
know:
I've
been
chatting
tech
stuff
about
using
the
eosio
core
library
more
in
the
explorer.
So
how
how?
What
just
now
this
is
effectively
approved?
How
soon
before
you
think-
and
it
touches
on-
I
guess
branding-
is
there
a
name
decision
that
has
to
happen
before
what
you
have
in
your
library
in
its
current
form
could
potentially
become
you
know,
antelope.js
or
whatever
like
how
soon
before
like
we
could
start,
you
know
importing
and
using
it
under
a
new
name.
F
I'm
not
entirely
sure
I
have
a
timeline
on
that.
The
that
one
repository
that
already
exists,
that's
kind
of
the
core
of
this
project.
We
do
plan
on
putting
that
into
the
antelope
repository.
What
that's
called,
however,
I'm
not
sure
it'll
be
renamed
immediately.
I
think
keeping
it
in
its
current
name
space
as
opposed
to
changing
it.
Multiple
times
is
probably
a
good
thing.
The
suite
itself
may
have
a
name.
F
I
forget
what
the
one
of
the
ethereum
ones
is,
but
one
of
the
other
ones
is
hardhat,
and
then
they
kind
of
have
sub
components
of
that.
I
imagine
this
will
be
similar
to
that
where,
like
the
suite
itself,
has
kind
of
a
bigger
name
and
then
the
sub
components
may
have
individual
names
sort
of
like
the
releases
leap,
for
example.
F
Yeah
and
if
on
the
technical
side,
it'll
just
be
renaming
where
those
things
are
imported
from,
I
think
all
of
the
individual
components
themselves
will
be
rather.
Generic
names
like
the
api
client
is
still
going
to
be
an
api
client.
It's
not
going
to
be
like
a
something
something
js
client,
the
library
name
may
change,
though,
and
the
name
space.
A
Okay,
so
libraries
and
namespace
good
keyword,
we
had
the
status
of
github
migration
or
migration
and
scenario
where
jeff
and
adam
had
been
preparing
project
plans
and
checklists
for
the
actual
tasks.
So
may
I
ask
jeff
what
is
what
is
the
status
of
the
activities
or
ted?
Maybe
in
combination
not
sure
who
is
actually
doing
this.
J
J
A
K
It's
it
might
it's
mostly
an
enf
plan,
so
github
has
been
migrated.
It's
not
probably
at
the
level
you
might
want
to
see
deeper
into
github,
mostly
argos
doing
that,
and
so
you
know
the
the
repos
are
done
for
the
most
part
you've
got
the
build
was
given
to
matthew
darwin.
It
is
running
on
jungle
right
now
the
leap
3.1
rc4,
build
is
live
and
running
off
of
the
new
repos
arg
is
now
putting
all
of
the
coalition
github
accounts
back
in
we've
changed
some
of
the
permissioning
etc.
K
So
for
now
it's
it's.
The
github
is
basically
done
the
rest
of
it
is,
you
know,
other
items
that
are
probably
more
around
marketing
or
something
we.
We
have
some
documentation
stuff
for
the
enf
that
we're
we're
finishing
up,
but
that's
not
related
to
this.
Obviously
things
like
eos
js,
which
was
dormant
for
two
years.
K
We
have
someone,
that's
working
on
that
when
we
feel
the
time
is
right,
we'll
bring
it
across
there's
also
some
other
client
libraries
like
java,
for
you
know
the
android
and
swift
for
iphone
that
we
will
start
to
bring
across,
but
for
the
most
part,
everything
we
need
for
the
coalition
in
terms
of
github
is
done,
and
hopefully
you
all
have
gotten
your
invites
or
you'll
get
them.
You
know
today
or
tomorrow,
for
the
new
repos
for
the
new
organization.
A
Okay,
very
nice,
so
talking
about
you
do
you
touch
documentation.
Justin
is
not
here
due
to
obvious
reasons
so
because
he
he
just
been.
How
do
you
say
he
just
got
farther
so
so
he
probably
has
one
reason
not
to
be
here
at
the
moment,
but
he
did
raise
the
question
in
telegram
about
documentation
on
antelope.
A
K
K
How
how
developers
would
work
on
our
network-
and
I
think,
making
a
antelope
documentation
where
it's
really
kind
of
core
generic,
but
not
aimed
at
a
actual
operating
chain
is,
is
doesn't
make
sense,
because
how
you
would
do
something
on
wax
is
slightly
different
than
how
you
might
do
it
on
eos
and
versus
you
know.
Yes,
you,
the
smart
contract
probably
looks
the
same,
but
onboarding
etc.
So
my
thought
would
be
for
antelope.
K
So
that's
what
we
have
been
doing
and
planning
to
do
now,
if
that's
not
what
the
coalition
believes
and
obviously
it
can
be
opened
up
for
discussion,
and
we
we
have
today.
We
have
four
people
that
are
on
our
developer
relations
team
and
that
do
documentation
that
do
all
of
this,
so
that
we
we're
obviously
investing
a
lot
in
that.
And
you
know
if,
if
we
were
to
say
no,
those
all
are
our
coalition,
then
you
know
that
that's
something
I
guess
it's
up
to
the
coalition
to
decide.
K
Those
costs,
though,
probably
would
would
that
need
to
be
borne
by
the
coalition.
It's
just
up
to
each
team
to
decide.
Do
they
do
they
really
feel
the
same
about
the
documentation
etc.
We
have
not
rolled
ours
out,
yet
we
you,
you
can
tell
three
of
these
people
came
from
block
one.
So
if
you
go
to
you
know
developers.eos.io,
you
can
see
we.
We
know
how
that
was
all
built.
We've
rewritten
parts
of
the
stuff
that
weren't
open
sourced
and
you
can
imagine
other
than
the
the
branding
etc.
K
It
will
have
some
look
and
feel
like
that
does
plus
the
the
new
things
that
are
being
built
by
nathan,
james
for
the
dev
hub,
which
will
be
a
lot
of
video
content
and
the
likes,
and
it
all
pretty
much
centers
around
again
working
on
eosio.
But
that's
just
what
we're
thinking
now
and
I
guess
it's
up
to
the
coalition
to
decide
if
that
feels
fine
or
if
there's
a
a
different
desire.
E
We
link
out
to
in
a
lot
of
places.
I
feel,
like
you
know,
generally
speaking
in
canada,
what
justin
mentioned,
although
I
wanted
to
bring
this
up
on
a
call
two
weeks
ago.
We
just
it
wasn't
time,
but
I
feel,
like
you
know,
when
you
look
at
software,
it's
documented
right
so
like
as
we
pay
people
to
improve
features.
You
typically
document
when
you
add
features
right,
like
all
the
plugins
and
everything
that
I've
always
used
developers.eos.io
or
is
documenting
the
code
that
is
now
antelope
right.
E
I
would
say
that
there's
something
missing
for
antelope
then,
and
what
what
you
guys
are
building
may
be
partially
generic
and
partially
for
eos,
and
I
will
say
we
will
always
have
documentation
for
telos,
but
to
have
our
documentation,
contain
all
the
plugin
configuration
parameters
for
node
os,
for
instance,
or
just
all
the
standard
contract,
apis
and
types,
and
how
to
use
the
asset
and
the
symbol
classes.
And
things
like
that.
E
K
So
let
me
give
you
some
just
to
throw
this
out
there.
We
differently
than
what
block
one
did
we've
open
sourced
the
tools
that
generate
the
documentation
that
will
live
out
at
docs.eosnetwork.com,
so
it
generally
comes
by
scraping
the
source
code
by
you
know
going
into
the
docs
directory
under
lead
by
looking
in
the
welcome
directories.
All
of
these
things
are
are
things
that
you
know
that
will
now
be
open
source
that
you'll
be
able
to
look
at
them
and
say:
okay,
do
we
want
this?
K
We
want
that,
so
you
could
use
that
and
generate
the
telos
version.
Otherwise
we
would
either
need
to
decide-
and
this
just
makes
it
more
complex
and
then
we'll
need
to
push
costs
back
into
the
coalition
to
say,
okay,
well,
a
lot
of
what
we're
doing
is
now
going
to
be
sitting
under
antelope.
Then
we
need
to
spread
those
costs,
but
then
we're
going
to
always
have
stuff
that
would
stay
at
eof
docs.eosnetwork.com.
K
K
You
know
or
again
we
would
have
to
then
go
back
and
look
and
say:
okay,
we're
going
to
split
the
documentation
which
we
have
not
been
planning
on
and
and
then
splitting
it
put
some
stuff
under
antelope
and
then
it's
confusing
to
people.
Well,
there's
some
stuff
here
in
antelope.
But
if
you
want
to
use
eos,
you
know
well
there's
stuff
over
here,
but
then
part
of
it's
over
at
antelope.
K
K
K
You'll
have
the
documentation
and
it's
just
a
matter
of
running
scripts-
that
periodically
kick
off
in
github
when
a
push
occurs.
You
know
all
of
a
sudden
it
kicks
off
and
updates
your
documentation.
That's
the
path
we're
going
right
now,
but
again,
this
is
up
for
the
coalition
to
decide.
I'm
just
telling
you
where
we're
at
at
this
very
minute.
We
can
obviously
every
it's
all
software.
It's
all
changeable.
E
K
Yeah
we,
yes,
we
we
at
this
point
have
planned.
I
mean
you
know
that
that
would
be
more
of
an
eve
call,
but
we
have
planned
any
of
the
software
that
the
main
teams
are
writing.
As
long
as
it
gets
into
the
documents,
the
either
the
md
files
that
are
living
and
some
of
the
doxygen
files
that
are
living
in
the
repos,
we
we
had
to
go
back.
We
have
to.
D
K
But
there's
another
thing:
you
guys
can
update
the
documents.
Now
you
guys
all
have
ability
to
open
pr's
against
the
replay
and
so
you're
like
hey.
I
think
the
documentation
on
this
smart
contract
stuff
is
not
up
to
snuff
and
you
guys
can
go
in
update
it
increase
it,
make
it
better
and
then
now
it
flows
out
to
wax
telos
and
eos
dock
stuff,
because
now
they
can
all
be
generated.
K
Complete
head
to
bottom
from
these
generators,
and
you
can,
you
know,
decide
to
modify
your
generator
and
hold
some
stuff
make
it
where
it
pulls
some
stuff
out
of
the
telos
repos,
like
you
have
some
special
tele
stuff.
So
your
generator,
that's,
maybe
been
forked
or
you
run
the
the
one
common
generator
with
a
dash
telos
flag,
and
it
then
says:
oh,
go
over
grab
these
things
out
of
the
telos
repo.
K
In
addition,
and
so
the
generators
become
a
little
bit
more
powerful
and
they're
they're
using
all
the
core
things,
but
also
using
all
the
special
sauce
that
wax
and
delos
have.
That
makes
it
where
now
the
documentation
sets
are
complete
on
your
site
and
that's
what
kind
of
harmed
you
in
the
past
is
block.
One
wouldn't
open
source,
the
darn,
you
know
generator
and
we
it
is
now
and
we're
happy
to
share
it
with
you
and
have
you
know
one
of
our
engineers,
a
guy
that
build
it
from
scratch.
K
E
Yes,
that
I
mean
so
knowing
that
there's
the
generators
open
source
is
good.
I
feel
two
things.
One
there's
a
question
and
the
other
is
that
you
know
if
the
generator
like
you
said,
could
have
have
a
configuration
kind
of
behavior
like
we
demonstrated
we
parameterized
the
explorer.
So
it's
you
know
easily
deployed
by
anybody.
Yes,
that
you
know,
but
I'll
just
have
to
see
what
it
looks
like
because
yeah
that
would
be
fine.
E
So
that
leads
into
my
question,
which
is:
does
it
produce?
Like
the
and
I
looked
at
one
point,
I
tried
to
reverse
engineer
that
documentation
generator
as
well.
Does
it
produce
the
whatever
that
library
is
gatsby
front
end
code
like
in
its
entirety,
or
does
it
produce
markdown
files
that
can
be
used
in
any
type
of
documentation
framework.
K
I
I
believe
it
does
both.
Unfortunately,
in
the
end,
it
all
ends
up
producing,
I
believe,
html
out
on
this,
the
final
site,
but
I
do
believe,
there's
some
interim
markdown
files.
I
can
definitely
I'll
connect
you
with
eric
passmore,
who
wrote
100
percent
of
the
code
who's
now
an
employee
of
ours
and
he'll
be
happy
to
help
and
the
goal
would
be.
You
know
you.
K
I
think
it's
I
mean
it's
there's
a
whole
bunch
in
there,
and
so
what
he
tried
to
do
was
do
mostly
what
had
been
done
and
maybe,
with
a
little
bit
newer
technology
than
had
been
used
in
the
original
one.
I
mean
we
were
able
to
talk
to
the
engineer
that
had
written
the
original
generator,
even
though
he
could
not
give
us
the
source
code,
and
so
it
unfortunately,
probably
is
not
as
pretty
as
you're
hoping
I
I
can
go
poke
around
and
see.
K
If
I
can
see
the
repo
it
should
be
public
and
I'll
share
it
in
the
I'll
share
it
in
the
chat
here.
If
I
can
find
it
and
you
can
start
to
look
at
the
the
horrible
mess
it
is,
but
I
mean
it
does
work
and-
and
we
can
probably
let
you
see
where
we
are
so
far
in
the
verse-
the
replaced
version-
we
have
it
password
protected.
It's
it's
at
docs.usnetwork.com,
so
you'd
get
an
idea
of
what
the
generator
is
doing.
K
It's
not
we're,
not
100
done
yet,
but
I
will
give
you
the
repo
link
it's
this
one.
I
don't
think
that
they
pushed
across
yet
over
to
antelope,
because
we
hadn't
discussed
this,
but
I'm
totally.
Okay
with
it.
I
mean
it's
eve's
decision
and
it's
a
coalition's
decision,
but
it
seems
like
a
logical
thing
to
do
to
move
it
over.
E
F
As
well,
the
sdks
are
going
to
have
their
own
documentation
portal
because
it's
for
a
specific
audience
and
the
way
that
both
block
one
did
it
and
it
sounds
like
the
enf
is
now
doing.
It
is
like
this
omnibus
documentation,
and
I
think
it
may
be
worth
exploring
breaking
that
apart
for
different
audiences
into
different
documentation.
F
Things
like
you
need
to
consider
this
as
kind
of
like
a
seven
layer,
salad
or
something
where
there
are
different
levels
in
which
different
audiences
are
going
to
want
to
be
reaching,
and
some
of
those
are
identical
across
different
networks
like
telos,
is
a
good
example.
The
the
apis
and
the
like
the
leap,
implementation,
details,
they're
going
to
be
identical
to
eos
and
wax
is
only
going
to
have
one
variation
of
that
which
is
the
rsa
or
whatever
it
is
like
there
is.
F
Unless
for
branding
purposes,
you
guys
all
want
to
drive
and
duplicate
effort.
It
would
make
sense
to
have
that
be
one
thing
for
each
topic,
as
opposed
to
multiple
portals
that
all
cover
everything
the
sdks
are
already
going
in
this
direction.
With
the
proposal
we
had,
but
arguably
the
apis
should
have
their
own
leap
as
an
implementation.
C
F
Need
its
own
and
the
smart
contracts,
which
are
like
the
special
sauce
to
each
network,
those
realistically
should
be
unique
to
each
network,
but
that's
the
only
thing
that
should
be
unique
to
each
network.
There's
everything
else
is
going
to
be
identical
and
it's
a
lot
of
duplicated
effort,
so
maybe
structurally
breaking
this
apart
into
a
project
with
multiple
documentation
portals
for
different
purposes
for
different
audiences
that
can
all
be
tied
together
through
the
various
websites
for
the
various
networks
would
be
a
more
logical
approach.
K
So
it's
it's
not
duplicated
effort
if
it's
all
coming
from
the
same
source
and
just
landing
in
different
landing.
I
don't
know
if
you
were
saying
you
don't
believe
that
people
should
have
a
unified
documentation
on
eos
for
the
eos
network
and
telus
for
the
telescope,
if
it's
all
pulling
from
repos
that
are
both
common
and
disparate
and
makes
it
where
telos
has
its
own
version
of
documentation
versus
eos,
and
yet
nothing
was
duplicated.
It's
just
the
the
scanner
parser
thing
is
is
has
a
flag
to
make
it
land
a
little
bit
differently.
K
I'm
not
sure
if
you're
saying
disagree
with
that
or
you're
saying
that's
fine
that,
but
that
there
would
be
parts
that
were
common,
which
my
proposal
has
all
the
common
code
stays
common
and
that
the
disparate
code
stays
different
out
in
telos
repos
like
when
telus
is
talking
about
their
system
contract.
They
pick
that
up
and
get
it
on
their
website
that
way,
people
that
are
tell
those
people
go
to
telus
for
all
their
documentation.
F
That
won't,
I
guess
what
I'm
saying
is
that
won't
be
the
case
with
how
the
sdk
proposal
is
written
right
now
there
will
be
one
sdk
website
that
telos
wax
eos
all
linked
to
for
the
documentation,
and
that
is
for
a
very
specific
audience.
I
don't
anticipate
that
each
of
these
networks
would
replicate
that
documentation.
K
F
K
Well,
the
issue
is:
do
you
think
a
developer
wants
to
go
to
eight
websites
or
one
website
to
learn
stuff?
A
lot
of
this
is
already
done.
We
already
have
it
in
one
place,
we're
offering
it
to
telos
robert,
so
maybe
the
sdk
can
stand
out
by
itself
and
sdk
is
linked
out
to
the
sdk,
because
it's
special
and
it's
it's
going
to
live
over
its
own
website.
K
F
Because
block
one's
attempt,
documentation
was
a
failure.
There
was
too
much
information
for
different
audiences.
All
in
one
place.
The
separation
of
information
based
on
the
type
of
audience
that
you
are
seeking
to
educate
is
incredibly
important.
I,
as
a
developer
like
this,
is
not
out
of
will.
I
have
not
done
smart
contract
development
and
all
of
the
documentation
that
I
need
as
an
operator
and
as
a
client
developer
is
mixed
in
with
these
smart
contract.
K
Developments
we're
working
to
separate
that
that's
what
having
a
single
documentation
team,
which
were
which
we
built
now
and
we
have
a
different
person-
writing
the
scrapers
and
stuff
we're
starting
to
tease
that
apart
and
fix
it,
and
instead
of
having
just
random
people,
putting
documentation
all
over
the
place
and
people
hoping
they
find.
It.
K
F
Developers
search
for
things
they
don't
developers,
aren't
going
to
go
to
the
telos
website
explicitly
unless
they're
getting
started.
But,
for
example,
when
they're
going
to
start
searching
for
the
send
transaction
to
api,
do
we
want
one
search
result
to
pop
up
for
every
single
or
antelope
network
that
exists,
or
do
we
want
one
universe.
K
K
I'm
talking
about
how
they
want
their
documents
laid
out
how
they
want
them,
formatted
how
they
want
the
branding
on
their
page
to
go
if
they
want
their
network
to
be
look
as
though
they
have
their
documentation.
They'll
they'll
want
that.
But
if
they're
like
hey,
we've
given
up
we're
just
all
everything's
just
antelope
now
and
then
who
really
owns
the
brand
antelope
who's,
taking
the
pride
in
antelope
and
who's,
making
sure
that
everything's
being
perfectly
done
there,
because
now
the
very
little
documentation
that's
left,
and
then
you
know
this
almost
does
feel
like
now.
D
F
No,
I
am
talking
about
the
like
the
client,
sdk
frameworks
that
exist
or
dooms.
Yes,
that's
forward
contracts.
These
are
things
that
exist
today
or
purely
api
documentation
for
somebody
that
needs
to
know
what
the
structure
of
the
apis
are
like.
That
is
a
very
specific
subset
of
developers
that
exist.
B
How
does
more
more
of
the
point?
How
does
cosmos
do
this?
How
it
is
so
I
I
so
I
think
that,
since
there
is
somebody
who's
already
done,
this
and
their
their
communities
have
had
a
chance
to
respond.
I
think
we
could
learn
a
lot
by
by
taking
a
look
at
those
and
yeah
and-
and
I
would
also
say
that
I
heard
you
know
ted-
you
said
hey
well,
if
this,
ultimately
five
years
from
now
this
needs
to
be.
B
I
actually
think
that
if
there
are
thing
if
we
are
making
decisions
as
we
make
decisions
here,
I
I
would
encourage
us
to
the
extent
we
can
not
to
make
short-term
decisions
right
if
we
say
okay
well,
this
is
the
most
productive
way
right
now,
but
the
real
way
long
term
is
we
want.
We
should
do
this,
I
would
say
once
you
once
you
set
up
a
framework
and
a
solution,
it
it
doesn't
change.
B
K
K
On
my
chain,
we
should
allow
that
and
then
we
should
allow
the
other
chain
to
say
put
it
on
antelope,
because
it's
just
as
easy
for
us
to
make
a
generator
for
antelope,
because
we've
already
made
the
generator
that
works
for
eos
now
again,
who's
going
to
be
taking
care
of
all
the
branding
and
all
the
styling
and
all
this
stuff
it's
like
for
us.
We
we.
B
B
B
You
know
today
is
also
someday
and,
and
these
things
get
baked
in,
if
we
don't
do
in
the
right
way
and
the
other
thing
that
I
think
is
imagine,
I
think,
listen,
I
think
all
of
us
have
a
vision
for
antelope
that
is
much
bigger
than
these
four
chains
or
the
six
or
seven.
You
know
prominent
chains
that
exist
now.
I
think
part
of
the
strength
that
we
present
is
that
there's
going
to
be,
you
know,
scores
or
hundreds
of
chains
or
thousands
god
someday
right.
K
Is
that
in
our
best
interest
or
is
at
some
point,
the
chains
will
try
to
differentiate
each
other
right
if
we're
trying
to
differentiate
from
each
other?
Our
developer
and
onboarding
experience
should
differentiate
and
we
believe
we've
hired
some
good
people
to
do
that,
and
we
want
to
we're
trying
to
make
our
chain
work.
We're
sharing
as
much
as
we
can,
but
at
some
point
the
marketing
developer
outreach.
D
Isn't
aaron
saying
neither
isn't
aaron
saying
neither
so
it's
it's
like
not
either
of
these
options
that
are
currently
being
discussed,
he's
saying
just
no
central
repository
just
they
live
elsewhere
in
the
respective
field
that
they
came
from
this.
These
documents
already
live.
Yes,
so
that's
the
problem,
I'm
saying
is:
how
do
you
split
those
up,
then
aaron,
where.
C
D
I
K
Notice
on
that
part
for
two
years,
we're
working
towards
that
we
haven't
revealed
it
yet,
but
that
is
the
point
is
to
make
them
different
chapters
in
different
and
even
multiple
books.
But
the
and
again
this
the
scraper,
the
tool
that's
been
built,
allows
the
chains
to
make
it
look
differently
for
how
they
want
it
done,
and
I've
shared
the
the
repo
for
that.
What
what
we've
already
developed
to
get
that
right,
working,
which.
B
If,
if
we,
let's,
let's
look
at
this
from
a
different
angle,
we
what
we've
identified
one
of
the
major
groups
that
we
want
to
be
very
friendly
towards
are
web
2
developers,
who
are
their
job
now
be
in
you
know,
involves
coming
to
web
3.
and
one
of
the
strengths
we
have
is,
rather
than
than
those
people
having
to
immediately
choose
what
chain
they're
going
to
go
on.
B
They
are
first
choosing
technology,
which,
I
think
is,
I
think,
is,
is
aligned
with
how
a
major
company
or
a
large
organization
is
going
to
work
which,
which
of
these
technologies
are
going
to
go
to
we're
going
to
go
with
antelope
we're
going
to
go
with
cosmos,
we're
going
to
go
with
polka
dot
or
what?
What
are
we
you
know
and
then,
once
that
decision
is
made
on
its
own
merits,
then
they
will.
They
will
further
refine
into
what
chain
what
particular
chain
they
go
on.
I
B
Even
if
it's
just
a
one,
employee
organization,
somebody
you
need
to
have
somebody
whose
job
it
is
to
stay.
On
top
of
these
things
to
really
care
more
about
about
antelope
than
any
single
chain.
Until
you
have
that
until
you
have
that
that
structure,
it
really
isn't
going
to
fill
the
needs
we
set
out
for
it.
So
those
are
two
things
I
wanted
to
share.
K
So
we
have
that
today,
and
I
think
the
thing
that's
getting
lost
here
is
at
some
point.
Each
chain
is
going
to
try
to
differentiate
itself
and
and
grow
its
user
base
grow
its
developer
base.
So
if
we
make
it
where
nope
that's
only
done
at
antelope,
you
have
to
decide
if
you're,
antelope,
first
and
all
the
developer
relation
stuff
is
just
in
antelope
and
then
later
you'll,
just
accidentally
fall
into
eos
or
or
tell
us
or
waxed.
I
I
disagree
with
that.
K
I
think
what
needs
to
happen
up
front
is
the
chains
start
differentiating
their
developer
kind
of
outreach
program
and
showing
that
hey
we're?
This
is
what
we're
developing
for
this
is
the
type
of
developer
we're
trying
to
attract
our
marketing
materials.
Our
developer
relations
program
is
pulling
in
people
because
eventually
there
will
be
a
limited
number
of
developers
coming
in
to
the
overall
ecosystem
and
sure
we
hope
that
the
four
of
us
are
the
four
survivors
or
you
know,
maybe
there's
five
or
six
survivors.
F
K
Look
at
nfts
right
now
dominated
by
wax
right.
If
you're,
if
you're
an
nft
developer
in
eos
world
you're,
going
to
go,
wax
wax
is
trying
to
say
they're
the
gaming
and
they're
the
nft
group.
We
are
already
differentiating,
and
I
think
that
we
have
to
realize
that
part
of
that
is
the
developer
outreach.
If
we
say
we're
going
to
take
all
of
our
documentation
and
all
of
our
developer
outreach
and
centralize
it
into
analog,
it's
stopping
the
chains
from
differentiating
and
actually
doing
it's
neutering
marketing.
We
would
have
to
centralize
marketing
at
some
point.
K
The
the
ultimate
completion
of
this
would
be
put
all
four
of
these
chains
together
and
make
one
chain,
because
they
can't
differentiate.
They
can't
market
differently.
They
can't
have
separate
developer
outreach.
Let's
just
combine
them
into
one
chain.
Combine
all
their
finances,
combine
all
their
people,
do
a
layoff
and
we're
just
one
big
chain.
B
I
really
disagree.
I
don't
I,
I
think
that
those
things
can
be
separate.
I
think
that
the
and
will
be
and
naturally
will
be
separate.
I
don't
think
that
a
core,
a
core
documentation
of
our
shared
elements
of
and
tools
that
we're
putting
together,
I
mean
we're
sharing
the
development.
We're
sharing.
You
know
we're
sharing
those
things.
Why,
then,
would
we
have,
for
you
know
and
then
and
later
on,
n,
separate
documentation,
efforts
for
the
for
the
core.
K
Stuff,
that's
they're,
not
separate
douglas
there's
one
repo
where
all
the
documents,
multiple
repos,
where
the
documents
live.
All
of
you
have
right
access
to
those
repos.
You
can
make
enhancements
when
you
want
there's
a
open
source
scraper
that
lets
you
land
them
into
whatever
format
you
want
in
addition
to
changing
all
the
branding
around
it,
so
you
don't
have
to
make
them
look
the
way
the
eos
chose
or
wax
shows
your
screen.
K
The
way
you
modify
the
scraper
makes
it
where
they
land
in
different
directories,
land
in
a
different
format
and
those
that's
the
beauty
you
can
make
your
document
look
very
differentiated
from
eos's
or
from
waxes,
but
it's
all
coming
from
the
same,
centralized
source.
The
documents
themselves
live
inside
the
repos
and
all
of
you
have
right
access
to
those.
K
The
way
they
are
instantiated
onto
your
websites
is
completely
up
to
you
and
just
as
a
matter
of
how
much
time
do
you
want
to
modify
the
the
generator
that
is
actually
reading
those
documents
that
are
in
the
repos
and
putting
them
out
in
html
on
the
website?
So
you
can
control
how
much
you
want
to
invest
in
developer
relations.
How
much
you
want
to
invest
in
differentiation.
How
much
you
care
about
your
branding
to
make
your
experience
so
much
different
than
eos's
or
waxes,
and
you
know
I
will
agree
with
one
thing.
K
I
will
agree
that
the
way
black
one
did
it
was
crap,
but
you
know
that's
that
and
we're
gonna
all
surpass
that
I'm
sure,
but
I
do
believe
we
we
need.
We
will
all
share
the
same
common
tools
and
documents
how
we
make
them
look
and
how
we
promote
them
and
how
we
emphasize
one
part
versus
the
other
will
be
up
to
the
change
independently.
I
think
that
is
important.
A
So
I
I
would
basically
second
what
what
douglas
said-
and
I
feel
also
feel
strong
about
that,
because
I
personally
also
think
it's
like
the
differentiation
and
development
outreach.
I
I
personally
don't
think
it's
it's
mainly
based
on
how
the
documents
look
like
it's
it's
more
like
do.
I
find
what
I
what
I'm
looking
for.
Obviously,
there's
there's
two
components:
it's
the
it's,
the
general
open
source
documentation
which
is
maintained
by
by
antelope
in
some
way
by
the
coalition
and
those
that
contribute
to
the
code,
and
then
there
are
the
change
specialties.
A
So
obviously,
if
we
have
a
centralized
repository
or
a
kind
of
website
that
that's
the
place
to
go
for
antelope,
then
we
still
have
to
resolve
the
issue
of
the
specialties
for
tells
wax
whatever.
So,
if
you
want
to
want
to
understand
our
our
desired
voter
and
governance,
you
will
have
to
have
a
different
telesite.
A
A
I
think
it's
it's
very
valuable
to
have
this
kind
of
documentation
on
an
antelope
page
which
everybody
can
reference
to,
and
this
is
our
core
code.
This
is
where
it's
documented
there
you
find
all
the
information
and
there
you
find
the
sdk
documentations
and
if
you
want
to
know
specialties
of
chels
ux
wax.
Whoever
here
you
find
some
more
links
which
could
be
could
be
maintained
a
different
way.
So
I
I
think
it's
like
this
strong.
A
The
the
power
of
antelope
is
that
we
work
together
and
have
this
documentation
at
one
place
and
and
can
direct
people.
What
I
do
second,
is
that-
and
I
put
in
actually
putting
a
piece
into
the
agenda-
is
like
a
lead
management
part.
So
what
happens
if
any
new
dapp
is
is
entering
the
antelope
website
and
says
oh
yeah,
I'm
interested.
I
want
to
discuss
with
somebody
how
I
can
spin
up
my
own
chain
or
how
can
I
spin
out
a
side
chain
on
one
of
the
other
chains?
A
So
so,
how
do
we
manage
this?
Who
is
having
access
to
the
info
at
and
outreach
email
boxes
and
who
will
pick
up
those
calls
if
somebody
is
interested
in
any
antelope
topics,
I
think
that's
that's
kind
of
playing
together,
but
the
general
documentation
for
antelope.
I
think
it
belongs
to
antelope
to
the
coalition
that
should
be
maintained
centrally.
That's
my
personal
opinion.
It
is.
K
Maintained
centrally
it's
sitting
in
it'll
be
sitting
and
we'll
move
it
in
the
central
antelope
repos
it'll
be
a
central
open
source
scraper,
that's
not
a
question
of.
Is
the
documentation
centralized
it's
a
question
of.
Do
the
chains
have
an
ability
to
use
it
as
a
branding
asset
and
to
differentiate
they
actually.
A
May
erase
the
question
then,
but
because
you
obviously
you
you
were
doing
this
for
for
eos,
you
have,
you
have
significantly
more
resources
than
us,
the
smaller
chains,
so
that
that's
that's
fair
and
somebody
needs
to
configure
that
scraper
and
keep
it
up
to
date.
So
question,
though,
is
then:
if
we,
as
we
have
a
repository
for
antelope,
will
we
also
use
that
scraper
to
create
an
antelope
repository
page
website
that
includes
all
the
documentation?
K
Done
you
could
have
an
antelope
generic
one,
but
again
antelope
is
not
a
thing.
You
don't
run
on
the
antelope
chain.
You
run
on
eos,
telos,
wax
or
ux,
and
so
to
me
I
mean
sure
we
could.
We
could
put
it
there,
but
I,
what
I
don't
want
to
see
is
that
people
take
away
the
ability
for
the
change.
This
is
part
of
marketing
developer
relations
is
an
important
way
that
a
chain
differentiates
to
say.
This
is
why
you
should
pick
me
because
after
douglas's,
first
step
of
first
you've
decided
to
go
antelope.
K
The
second
step
is
now:
how
do
I
decide
if
it's
wax
ux
or
eos,
and
this
is
part
of
that?
We
have
to
allow
marketing
to
have
an
asset
to
use
to
to
grow,
we're
all
going
to
try
to
compete.
Hopefully
the
people
like
fio
and
proton
and
ultra
just
get
slaughtered
from
this,
but
in
the
end
there's
there's
just
a
finite
pie.
That's
going
to
be
divided
and
we
have
to
realize
that
we
have
to
allow
the
the
people
in
the
coalition
to
also
differentiate
I'm
okay.
K
B
B
E
K
I
K
Shows:
here's
eos,
here's
telos,
here's
ux,
here's
wax
and
you
go
oh
great.
So
there
is
a
docs
you
can
it
comes
up
if
you,
google,
antelope's
docs,
it
comes
right
up
and
it
tells
you
hey,
there's
four
chains
in
our
coalition:
here's
theirs,
here's!
You
know
blah
blah
and
you
go
that
way
that
instead
of
duplicating
it
a
fifth
time,
but
that
way
you've
allowed
the
change
to
market
and
differentiate,
because
we
have
a
developer
outreach
program.
We're
trying
to
put
together.
K
That
probably
is
not
the
same
as
what
wax
is
trying
to
do
or
or
maybe
ux
or
telos,
and
it
it
shouldn't
be.
These
should
be
differentiated.
To
allow
us
to
try
to.
You
know,
grow
our
businesses.
Right
I
mean
we
should
cooperate
as
much
as
possible.
We're
centralizing
the
documents,
we're
centralizing
the
scraper,
but
how
you
embody
that
with
the
the
marketing
and
the
brand
around
it
should
be
differentiated.
K
So
my
recommendation
would
the
antelope
just
has
docs.antelopesio
and
it
points
at
the
four
documentation
areas
that
you
could
go
to
people
say:
oh
yeah,
antelope
is
a
coalition.
It's
it's!
It
shares
this
base
code,
the
documentation,
but
the
change.
There's
no
antelope
chain
running.
I
can't
run
an
antelope.
Now
is
my
time
since
I've
gotten
to
this
page
in
google
now's
my
time
to
try
to
figure
out.
Do
I
want
to
be
on
eos
telos
wax?
Oh
well,
let
me
kind
of
look
at
their
documentation.
K
I,
but
that's
quite
a
bit
farther
downstream
when
I
test
that
you
know,
but
I
think
there
need
to
be
four
independent
test
nets.
I'm
okay
with
an
antelope
test
now
it'd
be
very
generic,
though
right,
because
it
would
just
run
the
the
the
vanilla
contract
right
and
we'll
agree
with
you
guys
to
make
the
vanilla
so
that
it's
not
the
same
as
eos,
and
so
it
won't
be
the
same
as
telus
won't
be
the
same
as
wax,
but
that'll
be
a
little
less
useful.
I
mean
really.
We
want
people
once
you've
made
your
decision.
K
D
I'd
just
like
to
chime
in
please
aaron
wrote
in
the
chat,
and
I
maybe
aaron.
If
you
can
explain,
because
I
don't
understand,
point
number
one
and
point
number
two
seem
to
to
very
much
conflict
each
other.
So
if,
if
documenting
them
across
every
chain
and
bad
because
there's
duplication
is
bad
but
also
centralizing,
it
is
bad.
F
F
F
So
the
second
one
about
it
being
assembled
into
one
place,
isn't
about
it
being
assembled
under
a
chain.
It
is
the
documentation,
subject
matter
being
all
squished
together,
I'm
looking
at
the
dev
docs
repo
right
now
and
this
list
of
coverage
that
it's
talking
about
services,
probably
a
dozen
different
professions
right.
K
We'll
eventually
split
it
up
to
block
producers,
developers,
node
operators
etc,
so
that
you
come
in
as
as
what
what
is
my
use
case
and
it's,
but
that's
not
the
way
it
was
we're
just
trying
to
you
know
we
went
from
zero
about
three
weeks
ago
to
where
now,
we've
actually
got
it
actually
generating
stuff
from
from
nothing.
So.
I
Would
it
make
sense,
because
I
I
just
like
listening
to
you
guys,
there's
some
key
questions
here
and,
and
I
think,
there's
a
more
agreement
than
than
then
maybe
you're
talking
about
like
the
duplication
of
the
documentation,
for
example,
it
seems
like
that
is
a
guiding
principle.
Where
you
don't
want
that
duplication
to
happen.
You
want
to
be
efficient
and
the
knowledge
sharing
to
go
across
the
chain.
How
do
you
make
that
happen?
I
I
What
are
some
of
the
you
know,
practices
that
are
that
are
being
deployed
there,
and
you
know
what
learning
is
there
and
then
also,
you
know
having
a
list
of
those
key
kind
of
guiding
principles
for
the
coalition
around
how
this
would
work
and
and
having
those
you
know,
tested
by
the
use
cases
right
if
the
developer
comes
in,
they
hit
this
website.
There's
trying
to
solve
this
problem.
Where
did
it
go?
How
do
we
streamline
it?
B
I
I
thank
you
for
mentioning
that,
and
I
do
agree,
and
I
would
also
say
guys
this
is.
This
is
not
moving
towards
resolution.
This
is
obviously
a
complex
issue
that
we
have
to
have
more
discussion
on,
and
so
I
wanted
to.
I
wanted
to
go
back
and
ask
ask
kirsten:
do
you
think
it
that
we've
reached
a
point
in
this
conversation
where
we
should
table
this
and
create
a
a
separate
work
group
for
discussions?
So
we
can
get
back
to
the
other
business
on
the
agenda.
A
A
As
you
say,
we
won't
gain
resolution
here
and
and
find
the
solution,
so
it
does
make
sense
to
build
a
work
group
that
is
considering
all
those
different
things
out,
performs
a
benchmark
on
how
do
or
how
do
the
other
chains
and
train
coalitions,
work
on
on
these
topics
and
how
have
they
been
successful
or
not
successful
doing
this,
so
I
I
would
propose
to
really
do
this.
So
thank
you
for
that
proposal,
doctors,
which
I
pick
up
so
as
as
very
active
in
this
discussion,
ted
aaron.
A
K
D
D
D
D
E
H
E
B
Right
and-
and
just
recently,
you
know
in
this
call
it
was
you
guys
shared
that
you
would
be,
you
would
be
doing,
there
would
be
a
vanilla
version
that
would
be
on
testnet
or
whatever,
but
it
would
exist
and
that
it
would
be.
It
would
not
just
be
the
eos
version.
So
if
that
is
the
case,
then
that
has
to
be
hosted
somewhere.
B
E
E
There
is
now
a
plus
eos's
changes
that
it
sounds
like
you're
going
to
be
maintaining
in
your
enf
repo,
of
course,
just
like
we
have
to
maintain
our
changes.
Tell
us
repo,
but
I
just
want
to.
I
guess,
make
sure
that
we
protect
the
antelope
and
the
reference
contracts
are
still.
You
know,
fully
maintained
as
part
of
iterating
antelope
itself.
H
E
H
H
E
E
E
But
it
sounds
like
you
guys,
are
kind
of
maybe
going
a
different
direction,
or
maybe
I
just
need
to
understand
what
it
means
and
like
what
you're
saying
and
that's
why
I
asked
for
the
examples
of
what's:
what's
going
there
versus,
what's
going
on
antelope
like
what?
What
are
some
examples
of
that
and
depos
feels
like
that's
what
antelope
is
and
what
has
been
in
the
vanilla
system
contract
since
day
one.
So
I
think
that
that's
where
I
really
want
to
see
some
clarity.
E
B
A
A
A
C
H
A
G
A
H
J
H
This
is
just
something
that's
still
in
progress
for
oci,
but
they're
still
on
schedule
for
getting
their
proposal
put
together.
Jonathan
gleesack
is
the
lead
on
that,
but
again
just
to
clarify.
There
have
been
two
bids
on
the
smart
contract
libraries
and
I
believe
one
of
those
was
that
group.
That
knows
the
telos
team.
A
A
Okay,
we,
we
did
have
the
discussion
on
the
ibc
contract
parties
and
legal
entity.
So
since
we
discussed
overly
in
at
the
beginning
of
the
meeting
that
that
there
will
be
basically
three
parts,
three
counterparties
signing
with
ux
is
this
still
a
discussion
point,
because
we
discussed
that
we
would
create
a
work
group
to
discuss
about
a
legal
entity
for
antelope.
D
So
the
contract
itself
needs
to
be
signed
by
the
three
separate
parties
as
they
currently
exist.
However,
in
the
contract,
it
also
calls
for
an
entertain,
an
entity
to
be
created
for
the
ip,
correct
and
yeah,
and
that
has
there's
no
progress.
There's
no.
It
has
not
moved
now
with
what
I
brought
up
at
the
beginning
of
the
call
guillaume.
Do
you
think
that
that
actually
changes
that
requirement,
or
is
it
still
essentially
a
requirement?
I
I
don't
have
an
answer.
I
don't
know
what
do
you
think
young.
G
Well,
I
mean
if
we,
if
we
just
go
and
let's
say
like
let's
say,
open
source
the
code
making
it
mit,
then
we
don't
need
that
structure
it
like.
I
mean
it's
still
useful
for
other
reasons,
but
we
don't
need
that
structure
now
to
be
referenced
inside
the
agreement.
So
like
it's,
not
it's
not
an
urgency.
It's
still
like
I
said
it's
still
useful,
to
have
a
structure
in
place
for
many
other
reasons,
but
it
doesn't
hold
up
so
that
hold.
D
Up
for
and
for
ibc,
though,
because
we're
not
paying
everything
up
front
the
protection
the
entity
was
there
also
to
protect
that
you
essentially
get
paid
for
completion
of
the
work.
Is
that
now
potentially
gone?
If
there
is
no
entity
or
does
that
still
remain
effectively,
because
the
three
have
signed
the
contract.
G
I
don't,
I
don't
think
it
was
ever
like
a.
It
was
more
for
the
transfer
of
vip
right.
It
was
more
for
that
yeah.
It
was
more
for
the
transfer
of
the
ipeda
because
essentially
like
the
way,
the
way
we
look
at
it
is
we
have
to
share
the
the
ip
to
have
it
review
to
be
accepted.
So
so
that's
like
we're
going
to
share
it
anyway,
it's
more
about
like
when
is
it
released
to
the
general
public
and
then
under
what
terms,
and
who
is
the
you
know
like?
C
G
D
Separate
to
this
I
guess
the
discussion
of
legal
entity.
One
thing
that
is,
it
should
be
a
consideration
is
that
right
now,
essentially,
the
enf
is
the
one
handling,
I
guess
the
enf.
How
can
I
say
this?
The
treasury
we
invoiced
out
each
individual
chain
so
that
you
could
send
so
that,
on
your
end,
you
could
have
an
invoice
as
to
why
you
were
sending
funds
to
the
treasury.
On
our
end,
we
don't
have
an
invoice
as
to
why
we
are
potentially
spending
the
or
sorry.
D
Currently
we
don't
have
an
invoice,
so
those
funds
currently
are
counted
by
us.
The
issue
there
is,
then
we
have
the
tax
liabilities
for
those
funds
that
currently
are
sitting
in
the
treasury.
Now
that
we
have
the
sdk
contract
done,
we
would
be
able
to
showcase
that
those
funds
are,
you
know,
to
be
spent,
but
they
don't
account
for
100
of
the
funds
in
the
treasury
and
in
the
future.
That
will
often
remain
the
case.
D
For
this
that's
another
area
where
I
think
ant
slope
having
an
entity
would
come
in
handy
because
that
would
be
removing
that
liability
from
the
enf,
but
now
that
would
be
putting
the
liability
of
tax
burden
on
antelope
the
entity.
So
that
may
be
where
we
want
to
continue
that
discussion.
Anyways
we
we
may
have.
We
may
be
okay,
because
we
are
going
to
try
and
leverage
the
same
structure
that
we
have
for
the
grants
that
we
we
have
in
eos,
whereby
we
say
the
treasury
isn't
ours.
D
D
B
We're
going
to
have
to
pick
it
up
and
as
we
I
think,
it's
been
good
that
we
have
not
focused
on
it
too
much
at
this
point.
But
my
guess
is
that
we're
getting
to
the
point
where
we
should
put
some
effort
into
it,
because
eventually
something's
going
to
come
up
where
we
need
it
where,
where
none
of
the
single
chains
want
to
you
know,
we
don't
want
to
see
be
seen
as
a
lim
as
a
general
partnership.
B
B
So
I
think
that
this
is
probably
a
good
time
for
us
to
start
or
restart
that
effort,
and
you
know,
we've
got
a
lot
of
a
lot
of
the
a
lot
of
our
initial
development
is
out
of
the
way
the
branding's
out
of
the
way
there's
much
work
to
do,
but
I
think
this
is
where
we
start.
I
don't
think
we
should
kick
it
down.
The
road
very
far
agreed.
G
A
G
G
G
But
yeah
like
it's,
it's
I
guess
like
for,
for
the
time
being,
they're
not
they're
not
needed
until
the
move
forward
with
this,
and
then
I
don't
think
they
ever
were.
You
know,
like
related
to
the
paper
like
paper
was
mostly
what
lucas
has
been
working
on
and
I
guess
like
there
might
be
additional
things
we
want
to
put
in
there,
but
it
was
seemed
to
me
like
it
was
kind
of
necessarily
necessary
either.
You
know
it
was
a
bit
of
a
different
exercise.
A
But
then,
if
everybody
agrees
I
I
will
move
that
to
the
eighth
eighth
of
september
item
and
and
discuss
that
at
that
point,
then,
okay,
cool
process
and
resource.
We
discussed
that
last
time.
I
don't
want
to
cover
this
because
we
we're
at
the
end
of
the
time
anyway.
So
so
one
thing
I
I
did
mention
here
and
that's
probably
something
we
can
discuss
next
week
is
how
we
what
happens
with
outreach
to
the
antelope
website.
So
who
takes
care
of
this?
A
A
A
B
One
other
thing
about
yeah,
one
other
thing
about
that
in
with
that
quarterly
re-evaluation,
we
want
to
one
things
I
brought
up
and
I
think
we
all
generally
agreed
on
is:
we
want
to
have
a
comment
period.
A
community
comment
period
coming
up
to
that,
so
that
we
live
up
to
our
our
pledge
of
openness
and
if
it's
on
the
8th,
I
think
we
should.
I
think
we
somebody
needs
to
begin
plant
somebody
or
some
small
group
or
whatever
needs
to
needs
to
figure
out.
How
are
we
going
to
take
comments?
B
B
If
we
don't
talk
about
it
this
time,
we
should
talk
about
it
next
time,
but
or
we
should
talk
about
in
the
channels.
But
if
we
don't,
you
know,
if
we
don't
talk
about
it
soon,
then
it's
not
going
to
be.
You
know
that
we're
not
going
to
have
any
kind
of
meaningful
period
for
people
to
to
share
their
thoughts
with
us,
and
I
think
that's.
G
G
We
ended
up,
selecting
all
needed
up,
20
or
something,
but
there's
there's
quite
a
few
things
that
are
not
on
that
list.
That
I
think,
would
be
interesting
to
look
at
so
so
yeah,
just
anyone
really
that
has
any
suggestion,
features
or
various
additions
to
the
world
base.
You
should
be
given
an
opportunity
to
voice
these
ideas.
E
E
Yeah,
so
I
mean
I'm
not
trying
to
like
advocate
short-circuiting
that
process,
but
we
do
have
an
explorer
and
I
didn't
get
much
feedback
if
you
weren't
here.
I
don't
know
if
you
were
here
known,
but
you
know
we
parameterized
it.
It's
it's
basically
working
against
every
every
chain.
Here
you
know
we
all
have
hyperion
right.
So
it's
it's
something
that
I
I
I
feel
like
I
proved
could
be
easily
configurable
for
different
chains.
I
mean
we're
continuing
to
iterate
on
it
and
add
improvements
and
every
one
of
you
is
welcome.
E
E
I'd
love
to
see.
You
know
at
least
the
four
coalition
chains
in
in
that
sidebar
and
have
it
hosted
somewhere,
possibly
under
the
antelope
domain
or
or
not.
We
can
figure
that
out
later,
but
you
know
it's
there.
It's
it's
mostly
done,
there's
just
some
customizations
that
are
needed
for
each
chain,
even
specifically
like
the
colors
and
the
logos
like.
I
obviously
didn't
pick
the
right
ones
and
didn't
put
a
lot
of
time
into
it.
D
I
guess
what
I
what
I
said
last
time
is:
I
do
believe
that
I
align
with
the
idea
that
antelope
should
have
access
to
a
block
explorer
or
that
we
make
that
available
to
people.
My
view
is
that
the
block
explorer
would
be
like
just
a
block
exploration
function,
which
is
perhaps
different
than
the
swiss
army
knife
that
we're
accustomed
to
with
with
blocks
or
authority
or
whichever
of
the
other
ones.
I
would
be
okay
with
fast
tracking
that
component.
D
What
I
said,
though,
is
that
if
antelope
is
going
to
be
on
boarding
this
cost,
then
it's
obviously
not
just
up
to
me.
That's
why
I
brought
up,
and
we
talked
started
talking
about
how
do
we
reprioritize
priorities,
which
led
into
the
all
right?
Then
we
should
probably
every
couple
of
months
revisit
the
priorities
so
that
we
can
relay
out
the
road
map
up
update
it.
D
If
there
are
any
changes
and
such
again,
I
I
would
be
at
the
position
that
having
antelope
have
a
block
explorer,
so
not
necessarily
swiss
army
knife,
but
a
block
explorer
with
a
simple
drop
down
that
could
point
to
the
four
separate
coalition
members
right
now
would
be
of
of
benefit,
I
think,
would
be
pretty
cool.
If
that's
the
case,
then
it
actually
doesn't
need
all
of
the
other
functions
that
you
just
mentioned.
I
I
think
that
that
would
be
okay.
D
E
Know,
and
and
to
to
to
your
point
like
the
power
up
example,
I
only
brought
that
up
because
right
now
in
the
explorer,
when
you
go
to
an
account
you,
when
you
go
to
your
account,
you
can
stake
cpu
and
net,
so
it
maybe
in
that
regard,
we
could
turn
we
could
add
a
simple
parameter
in
the
config.
Where,
for
for
your
chains
or
you
know,
for
eos,
you
just
have
a
flag
that
says:
don't
do
cpu
and
net
it
wouldn't
do
power
up
either
right.
D
Is
even
I
guess,
if
further
away
from
that,
I
I
don't
even
see
a
vision
where
a
block
explorer
has
the
power
up
function
because
I
think
that's
separate.
I
think
the
block
explorer
is
really
just
the
block
explorer
you
put
a
transaction
id
and
you
get
information
from
that
transaction
id.
You
do
not
transfer
tokens,
you
do
not.
You
do
not
interact
with
the
block
explorer
to
interact
with
the
blockchain.
In
that
sense,
that
is
a
different
vision
that
we
are
heading
in
okay.
It's.
E
E
D
Yeah
yeah,
it's
so
again:
it's
not
that
I'm
against
the
actual
iteration
of
the
current
block
explorer.
It's
the
I
believe,
a
block
explorer
in
the
future
will
simply
be
the
block
explorer
and
then,
if
that's
the
case
and
antelope
sees
value
in
that,
let's
implement
a
block
explorer
for
antelope
that
has
simple
drop
down
menu.
D
C
D
E
B
An
alternative
just
make,
it
turn
make
it,
so
you
can
turn
it
off
that
you
can
turn
off
those
feet,
those
all
those
things
in
the
configuration
can
I
flip
the
the
question
around
and
say:
telos,
you
know
I,
I
understand
your
your
vision
for
it,
and-
and
there
is
no
one
right
answer-
we
have
a
we.
Our
vision
that
we've
been
building
on
is
that
we
believe
that
there
is
value
in
this
kind
of
swiss
army
knife.
B
If
you
want
to
call
it
that
one-stop
shop,
especially
if
it
can
be
made
if
it
can
have
a
variety
of
of
modalities,
so
there's
a
simple
mode
and
a
an
advanced
node
mode
or
or
whatever
right,
and
even
maybe
more
granular
than
that,
maybe
there's
a
developer
mode.
Maybe
there's
a
there's,
a
trade,
a
a
trader
mode
right.
What
anything
like
that?
So
would
anyone
have
a
pro
since
we've
already
done?
This
we've
already
gone
pretty
far
down
this
road
and
we
see
a
value
in
it
existing.
D
E
Unicode
right
and
I
I
agree
that
there's
things
that
don't
belong
in
the
block
explorer,
but
I
think
there's
probably
things
that
don't
belong
in
unicode
like
deep
contract,
interaction
table
and
interface.
There's
things
that
I
should
log
into
explore
and
do
that's
the
usability
conversation.
I
don't
really
necessarily
want
to
have
that.
I
I
think
that
well,
two
things
one,
you
know
each
chain
can
decide
what
they
tell
the
exchanges
to
do.
E
I'd
like
to
see
a
really
friendly
landing
pad
for
new
users
that
just
withdrew
from
the
exchange
and
now
they're
stepping
into
our
ecosystems
like
a
wallet
if
the
wallet
can
show
that
transaction
and
get
them
onboarded
in
a
friendly
way
to
log
in
and
start
using
the
tokens
they
just
withdrew.
But
generally,
I
think
we
got
to
figure
out
where
that
line
is
where,
where
the
sides
blur
and
the
edges
overlap,
that's
usability.
E
Where
there's
four
chains
in
the
sidebar,
we
can
have
the
test
nets
also
they're
all
there
as
long
as
there's
a
hyperion
endpoint,
and
then
you
know
to
kind
of
what
what
douglas
was
saying
like
you
know,
we're
going
to
continue
developing
it
and
adding
features.
I
would
say
that
there's
certain
features
that
we
probably
aren't
going
to
build
like
pro
bono,
like
we're
not
going
to
build
a
power
up
really
sophisticated
ui,
unless
you
guys
want
to
build
it.
E
You're
welcome
to
put
a
view
developer
on
it
and
do
it
and
it'll
go
right
in
the
code
base
or
you
know
we
would
just
probably
put
enough
effort
into
parameterize
disabling
that
and
then
the
eos
configuration
would
just
not
have
resource
management
turned
on
and
you
would
just
not
have
buttons
on
the
account
page.
So
you
know
that
that's
more!
What
I'm
getting
at
like
like
douglas
said,
would
would
you
be
receptive
to
that?
E
Should
we
because
we
do
have
it
and
it's
very
close
to
being
good
enough,
in
my
opinion,
to
just
have
antelope
scan
and
put
that
out
there
as
like,
hey
look,
here's
four
chains,
look
at
what
they're
all
doing
dig
through
our
blocks.
You
know-
and
it's
all
branded
for
each
of
us-
that
that
was
more.
What
I
was
was
getting
at
and
then
of
course
not
I'm
not.
D
Opposed
to
that,
I
I'm
I'm
okay
with
that.
I
am
somewhat
worried
about
whether
or
not
that
how
can
I
put
this,
whether
or
not
we
continue
down
the
same
path
that
we
believe
is
is
maybe
not
as
valuable
for
ux
if,
if
we
do
have
antelope
scan-
and
we
recreate
this
idea
of
the
swiss
army
knife-
does
that
actually
long
term
just
continue
the
same
usability
that
we
have
right?
I
don't
know
so,
but
no
I'm
not
opposed
to
that.
D
E
Like
yeah,
you
can
go
right
now
and
use
it
on
you.
It's
connected
to.
I
think
I
switched
to
rios
hyperion
as
long
as
there's
a
reliable
hyperion.
You
can
log
in
and
use
it
for
everything
except
the
fact
that
it'll
help
you
stake,
cpu
and
net,
which
you
don't
do,
but
it's
fully
functional.
You
know
we
have
to
change.
So
I
guess
I.
G
G
So
if
you
were
able
to
say,
for
example,
support
ux
and
add
that
like
allow
people
to
see
their
balance
because
it's
most,
I
guess
like
most
other
solutions,
that
we
looked
at
we're
only
looking
for
one
token
on
the
yes
token
contract,
but
for
us
for
us
it
would
essentially
be
all
that
we
need.
I
guess,
all
the
difference
that
we
need
to
to
benefit
from
this
and
it
would.
It
would
then
become
potentially
a
better
choice
than
what
we
have
which
is
esq.
E
So
yeah
it's
definitely
possible
just
to
give
you
a
quick
answer.
I
mean
yes,
we
built
it's
all
written
in
view
which
is
actually
the
quasar
framework,
but
you
know
it's
all.
We
have
a
pretty
solid
strategy
for
making
things
customizable
where
each
chain
has
their
own
directory
and
you
can
write
whatever
code
you
want
in
there
and
then
any
place
for
your
example.
Like
you
know,
you'd
show
the
users
utx
and
utx
ram
you
would.
E
E
That's
already
established
for
other
places
where
you
just
read
the
config
and
decide
if
you
turn
that
on
and
then
your
config
would
just
turn
that
on
and
you
know
make
it
configurable
it's
you
know
it
should
be
pretty
easy
to
add
that
in
the
code,
so
that
you
guys
just
turn
on
the
the
ram
token
option
and
say
what
the
symbol
is
or
something
like
that
right
shouldn't
be
too
hard
to
do
that
and
that's
kind
of
why
we
made
it.
Parameterized
ourselves
initially.
G
A
B
Yeah
sure,
as
long
I
mean
what
my
my
what
I'm
hearing
is,
nobody
has
an
objection
to
us
building
this
out
as
antelope
scan
supporting
other
chains
as
we
can.
You
guys
would
come
to
us
with
prs
or
requests
and
and
then
the
the
thought
that
perhaps,
if,
in
the
future
our
vision,
if
the
users
really
like
what
we
built
and
it
becomes,
it
becomes
useful
that
you
know
we
would
have
the
possibility
of
of
trying
to
get
some
some
retroactive
funding
for
what
we
had
built
on
spec.
B
Basically,
if,
if
those
things
aren't,
but
we
don't,
but
we
don't
have
any,
but
we
don't
have
any
expectation
of
a
guarantee
of
that.
If
that's
okay
with
everybody,
then
I
think
we
I
think
we
know
how
to
keep
moving
on
on
development,
because
we
we
we
are
at
a
bit
of
a
crossroads
of
which,
whether
we're
going
to
ramp
down
or
ramp
up
and-
and
you
know
that
answer
is
gonna-
be
helpful
for
us.
So
is
my
understanding
correct
for
for
eos
and
and
ux
at
least.
D
Yes,
but
you
kind
of
threw
a
wrench
in
there
that
I'm
not
sure
if,
if
which
is
the
funding
thing
yeah
the
funding
for
past
work,
do
you
mean
past
work,
as
in
the
last
year,
for
where
it
is
right
now
or
what
do
you
mean
password
from
now
on
to
actually
build?
Let's
say
the
support,
because
I
don't
know
what
that
even
means
in
terms
of
funding,
so
I
wouldn't
be
able
to
agree.
That's
why
I
can.
I
can't.
B
I'm
not
asking
you,
I'm
not
asking
you
know
what
that
means.
Well,
it's
not
it's
it's
it's
nebulous
intentionally
and,
and
you
know,
if
it,
if
it
even
happened,
we
would
bring
a
proposal
and
people
would
talk
about
it
and
we
would
talk
about
what
makes
sense
and
what
you
know.
I
don't
want
us
to
have
to
waste
time
on
that
now
I
just
don't
want.
What
I'd
like
to
know
is
if
we
ever
come
and
sit
and
say:
hey
people
love
this
tool,
they're
using
it
all
over.
B
Where
you
know
now
they
see
it,
we're
so
glad
we
do
it.
Can
we
get
some
you
know.
Can?
Can
this
be
something?
That's
you
know
get
some
get
some
some
funding.
You
know,
that's
that's
the
question
that
I
would
want
to
want
to
ask
if,
if
or
if
peop,
you
know
at
least
be
open
to
that
concept
later
and
and
not
say
well,
you
never
said,
and
you
never
even
raised
the
topic
of
future
funding.
So
you
know.