►
From YouTube: EOS Community Weekly Fireside Chat - July 6TH
Description
This week the EOS Fireside community talks about Faster Finality, trustless ICB, Pomelo S3, user experience, and more!
00:00:00 Welcome to Fireside EOS Chat and today's topics by Stephane
00:03:00 EOSIO Coalition and Faster Finality by Gnome, Yves,
00:28:13 Defining the “Trustless” concept by Gnome, Yves, Arhag
00:45:55 Key takeaways on Tustless and IBC by Yves, Gnome, Arhag
00:48:35 Wrapping up the IBC conversation by Gnome, Arhag
00:58:28 Sidechains on WAX and other EOSIO projects by Gnome
01:17:02 The power of working together by Zack, Aaron
01:21:42 The importance of user experience by Yves, Aaron
01:36:57 Pomelo S3 update by Stephane
01:39:44 Blockchain Futurist conference by Stephane, Yves, Zack
01:43:38 Mandel RC2 updates by Arhag
01:44:55 Eden election update by Stephane, ChuckMacdonald
01:49:23 EOS Zine update by Stephane
01:50:27 Bithumb increased staking rewards by Denis
01:53:41 Gamefi and AGGs by Stephane, Denis, Yves
02:02:07 Wrapping it up with a GO EOS!
02:03:04 End
// EOS Network Foundation //
https://eosn.foundation
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosn.foundation
#EOS #EOSIO #enf
A
Everyone
to
the
EOS
fireside
chat
thanks
for
joining
us
in
Discord.
If
you
want
to
take
part
in
either
jumping
on
and
audio
chatting
with
us
or
text
chat
chatting
with
us
via
the
live
chat
contained
in
in
this
Discord
event.
You
can
also
follow
us
on
YouTube
and
Twitter
and
yeah
thanks
for
thanks
for
tuning
in
so
today.
We've
got
a
few
topics
to
discuss,
got
actually
a
nice
list
to
go
through.
A
If
you
can
see
here
visually
in
the
live
chat,
we
got
some
people
sharing
their
favorite
video
games
because
we'll
be
talking
about
decentralized,
autonomous
gaming
guilds
a
little
later
in
the
show,
but
sure
so,
let's
go
quickly
through
the
agenda.
For
today,
we've
got
some
eosio
Coalition
progress
Guillaume
from
the
ux
network
is
here
with
us
today,
so
we'll
be
hearing
about
that
from
him.
We'll
be
talking
about
game.
Five
and
dags,
like
I,
said
we'll,
be
sharing
some
wombat
stats
kind
of
related.
A
A
We've
got
the
Mandel
3.1
release
candidate
2
that
was
released
today
we
got
some
updates
from
the
EOS
design
from
Lars
Eden
election
coming
up
this
weekend,
of
course,
and
some
more
news
from
bitum,
but
before
we
get
into
all
of
those
exciting
EOS
news,
we
wanted
to
share
a
few
Discord
updates
for
you
guys.
So
if
you
may
have
noticed
that
we
added
a
new
channel
today
called
starboard
and
that's
going
to
allow
us
to
kind
of,
have
a
community
create
curation
of
our
our
most
favorite
posts
on
Discord.
A
A
But
now
it's
only
going
to
be
reserved
for
a
pop
token
bot
commands,
so
you
can
go
in
there
and
type
your
EOS
account
with
a
dollar
sign
in
front
of
it
and
sign
up
for
today's
pop
token
distribution
for
all
our
other
chatting
and
discussions
Etc
we're
going
to
be
using
the
voice
chat.
That's
now
found
inside
the
voice
chat
text
box.
A
That's
now
found
in
inside
this
event
when
we're
in
the
voice
chat,
so
you'll
find
it
in
the
top
right
corner
of
the
voice
chat
event
when
you're
in
here
with
us
in
the
audio
Channel.
So
all
right
and
yeah.
So
thanks
everyone
for
joining
today
and
we're
gonna
get
it
started,
get
right
into
it.
I'm
gonna
invite
Guillaume
to
talk
to
us
about
some
of
the
work
that
he's
been
doing
with
the
eosio
coalition.
A
B
B
One
of
these
is,
of
course,
an
improvement
to
I
mean
like
in
safety
for
any
sort
of
transaction
that
may
be
high
Stakes
or
that
may
involve
you
know
an
off-chain
counterpart.
So,
for
example,
like
very,
very
obvious
example
of
where,
when
it
matters
is,
whenever
someone
receives
say
a
payment
for
for
something.
B
We'll
talk
about
that
as
well,
meaning
that
give
now
communicate
between
blockchains
and
have
have
a
very
high
speed
between
these,
these,
like
messages
being
exchanged
by
blockchains,
and
we
can
reach
consensus
much
faster.
Where
about
the
state
of
the
chain
and
making
sure
that
these
transactions
are
not
going
to
be
reversed,
and
this
is
quite
important
because
in
the
we
also
have
been
working
on
a
IBC
protocol
interval,
blockchain
communication
protocol
and
under
the
old
finality
rules,
it
still
requires
several
books,
few
minutes
for
Fidelity
to
occurred.
B
So
this
is,
of
course,
like
less
interesting
from
a
user
experience
perspective.
Now,
if
you
can
train
that
time
to
a
few
seconds,
it
definitely
improves
greatly.
The
the
user
experience
and
another
interesting
possibility,
following
faster
finality,
is
the
ability
to
also
increase
the
number
of
blood
producers
on
a
chain
without
a
incurring
additional
penalties.
B
When
it
comes
to
finalizing
good
luck,
because
under
the
current
model,
the
more
blood
producers,
you
would
add
the
longer
you
would
have
to
wait
until
a
blood
becomes
final,
but
under
this
faster
finality
proposal
now
that
the
time
remains
relatively
low,
even
if
you're
adding
more
blood
producers.
So
these
are
the
kind
of
Main
benefits.
I
guess
that
faster
penalty
by
itself
provides,
but
part
of
our
proposal
is
also
to
include
aggregate
signatures
which
are
very
interesting
in
their
own
right.
B
They
are
a
part
of
the
faster
than
the
proposal
because
they
they
allow
for
faster
verification
of
the
cryptographic
proofs
that
are
required
to
decrease
definitely
time,
but
they
also
open
the
door
to
a
number
of
other
future
features
that
can
be
developed,
such
as
better
confidential
transactions,
more
privacy
and
so
on
and
so
forth.
So
that's
in
NHL,
that's
our
that's!
Our
take
on
the
master
penalty
feature
and
we're
hoping
to
get
that
done
over
the
next
few
months.
A
A
C
C
B
Well,
I
guess:
I
guess
this
is
this
is
like
a
governance
question
so
that
the
way
we're
approaching
this
is
we
want
to
provide
the
tools
for
the
chains
to
be
able
to
to
modify
their
governance
if
they
choose
in
order
to
possibly
include
more
blood
producers.
Now,
of
course,
Every
esio
Chain
is
different.
Some
may
want
to
increase
that
number.
Some
may
want
to
keep
it
as
it
is,
of
course,
that
also
has
implications
with
regards
to
what,
possibly,
with
regards
to
inflation,
to
blood
producer
rewards.
B
So
so
that's
that's
a
question.
That's
a
bit
difficult
to
answer
because,
ultimately,
it's
still,
it's
still
a
decision
that
needs
to
be
taken
by
all
the
chains
individually,
but
it
does
open
the
door
for
multiple
blood
producers.
It
might
be
as
simple
as
just
keeping
block
rewards
the
way
it
is,
except
now
you
would
have
possibly
more
of
the
standby
BPS
also
producing
blocks.
It
could
also
imply
a
different
remuneration
for
blood
producers.
D
D
Yeah,
so
so
the
idea
is
in
the
proposal
and
with
the
back
and
forth
that
ensued
when
discussing
the
proposal
making
that
feature,
it's
not
really
a
feature
taking
that
into
consideration,
so
that
should
EOS
go
in
this
route
or
any
other
EOS.
I
o
iteration
go
in
this
route
that
it'd
be
optimized
to
be
able
to
do
so.
E
E
This
just
opens
the
door,
it
doesn't
force
you
to
go
through
it
to
increasing
block
producers,
but
if
one
was
interested
in
increasing
the
number
of
block
producers
or
more
accurate,
accurately
block
finalizers,
there
is
an
issue
with
the
existing
EOC
consensus
algorithm,
which
is
the
time
to
finality
scales
linearly
with
the
number
of
producers.
So
right
now
in
EOS,
for
example,
there's
21
if
you
doubled
it.
E
The
time
to
finality
doubles
from
three
minutes
roughly
to
six
minutes
and
that's
because
of
a
choice
in
the
consensus
algorithm
to
limit
how
quickly
blocked
producers
or
finalizers
can
provide
their
confirmations
of
a
block
which
leads
to
finality.
It's
limited
to
provide
only
one
confirmation
per
block,
and
that
was
done
as
a
as
a
way
to
reduce
overhead,
because
all
those
signatures
are
captured
on
chain
forever,
basically
in
the
block,
headers
and
so
aggregate
signatures
allows
for
taking
all
21
signatures
and
combining
them
into
a
single
signature.
So
it
compresses
arbitrarily.
E
E
As
fast
as
possible,
as
fast
as
Network
conditions
allow,
which
is
what
leads
to
faster
finality,
but
it
also
means
that
you
could
then,
with
no
additional
overhead
I
mean
there's
some
overhead,
but
with
better
scaling
overhead
linearly
scaling,
potentially
rather
than
quadratically
scaling
Network
traffic,
you
can
increase
the
number
of
DPS
considerably,
so
that
was
as
part
of
this
RFP.
It
was
requirement
to
look
into
a
little
bit
of
the
performance
of
how
well
that
could
scale.
B
And
then
you
can
take
signatures
that
have
been
provided
by
block
producers
or
blocks
final
finalizers
and
also
add
them
up
and
then
verify
that
the
aggregate
signature
matches
the
aggregate
key
in
one
operation.
So
that's
that's!
That's
very
interesting
from
a
cryptographic
standpoint
because
it
now
allows
you
to,
as
Eric
said,
to
reduce
the
size
of
the
of
the
signature
that
are
coming
to
contained
in
the
blocks
and
also
reduce
the
time
that
it
takes
to
verify
them.
B
And
it
may
not
seem
that
much
when
you
think
about
21
block
producers,
although
it's
it's
still
like
fairly
heavy,
because
we
have
one
blood
that
comes
every
half
second,
but
as
you
start
thinking
about
maybe
like
15
million
up
to
100
blood
producers,
it
starts
to
matter
a
lot
so
be
able
to
compress
these
signatures
into
one
single
signature.
Regardless
of
how
many
block
producers
you
have
is
quite
quite
valuable.
D
And
this
has
a
very
direct,
significant
cost:
tangible
cost
now
talking
about
money
when
you're
doing,
for
example,
IBC
between
ethereum
and
EOS,
for
example
correct
yum.
So
if
the
if
the
block,
header
or
I
guess
the
information
contained
within
the
block
is
now
smaller,
because
it's
compressed,
then
there's
a
significant
cost
savings.
When
doing
this
and
I
think
you
had
mentioned
roughly
20
to
30
X
cost
savings.
B
Literally
yes,
indeed,
because
I
mean,
as
everyone
knows,
executing
transactions
on
ethereum
is
very
costly.
The
gas
fees
tend
to
be
very
high.
They
came
down
quite
a
bit
from
the
recent
a
few
last
few
months
or
a
few
weeks,
but
I
remember
not
so
long
ago.
You
know
that
it
would
cost
like
a
hundred
dollars
worth
of
either
to
make
a
simple
transfer.
B
So
now
when,
when
it
comes
to
verifying,
let's
say
that
entire
blockchain
proves
this
is
this
is
quite
quite
a
hefty
price
that
that
you
have
to
pay.
If
you
have
to
verify
every
single
thing
under
the
current
esio
method.
So
now,
with
with
fast
personality,
we
can
drastically
reduce,
discuss
and
bring
it
to
a
lot
much
more
manageable
level.
D
So
again,
that
opens
up
a
lot
of
doors,
especially
as
then.
The
other
piece
of
this
puzzle
that
yama's
been
working
on
is
that
IBC
between
eosio
iterations,
but
also
between
EOS
and
external
chains,
right
so
having
this
holistic
approach
and
how
we're
deploying
code
and
within
which
direction
we're
going
and
why
we're
doing
so
is
really
not
taken
in
a
void.
B
D
There's
a
somebody
in
in
the
chat,
I,
guess
Drew
and
yes,
B's
turkey.
That
mentioned,
will
the
inflation
rate
increase?
Has
a
number
of
BP
increases?
No,
so
the
inflation
parameters
is,
is
a
different
parameter,
and
so
no
just
because
you
have
more
VPS
doesn't
mean
the
inflation
increase
notwithstanding.
If
the
governance
process
determines
that
it
wants
to
increase
inflation
again,
that's
a
completely
separate
variable,
so
not
in
scope
of
any
of
this
and
then
Drew
mentioned
I.
D
What
era
I
mentioned
earlier
is
obviously
the
votes.
Let's
assume
nothing
else,
changes
well
then
you're,
75
component,
when
changed
that
25
component
of
that
one
percent
would
now
be
distributed
proportionally
to
the
amount
of
blocks
that
you've
participated
in
validating
again,
that's
that's
a
there's,
a
lot
of
if
there,
but
generally,
if
people
wanted
to
know,
but
we're
nowhere
near
doing
that,
it's
just
that
that
possibility
will
now
exist
and
then
we
would
have
to
go
through
like
anything
else.
D
If,
if
this
were
to
become
reality,
then
what
are
the
advantages,
the
disadvantages?
Why
would
be?
Why
would
we
do
this?
How
would
this
in
effect
come
about?
What
are
the
technical,
Pros
cons?
You
know
what
are
the
reasonings
behind
us?
What
does
this
open
up?
Does
we're
not
there
yet
at
all?
This
is
really
is
it
out
of
scope
for
faster
finality.
B
B
You
can
buy
it
on
the
first
chain,
then
transfer
it
to
the
second
chain
using
IBC
and
without
having
to
wait
many
minutes
to
have
your
token
available
on
the
other
chain
and
then
profit
from
this
Arbitrage
opportunity.
So
it
does
help
liquidity
quite
a
bit.
It
makes
I
would
also
argue
it
makes
a
lot
of
transactions
safer
in
a
sense
because
if
you,
if
you
start
doing
press
chain
Arbitrage
and
things
of
the
sort,
there
might
be
some
chains
that
you
preferred
than
others.
B
Maybe
you
trust
a
specific
chain
more
than
another.
So
now
you
have
a
lot
faster
response
time
if
you
want
to
move
your
tokens
to
another
chain
and
so
on
and
so
forth,
and
of
course,
when
it
comes
to
settlement
of
a
payment
having
a
having
faster
finality
also
decreases
the
time.
The
number
of
confirmations,
if
you
want
that,
are
required
for
the
transfer
to
become
final,
so
I
mean
I'm
sure
everyone
has
been
I
had
a
chance
to
experience.
D
And
to
expand
on
that,
the
last
part
that
you
just
mentioned,
yum
faster
finality
in
itself
clearly
has
benefits.
Ibc
in
itself
clearly
has
benefits,
but
the
Coalition,
determined
and
and
I
guess
is
still
in
the
progress
of
their
in
the
process
of
determining
is
that
the
two
combined
opens
up
immense
potential
immense
possibilities,
as
you
as
you
just
mentioned,
and
that's
really
where
once
think
about
it
for
the
others.
D
Listening
as
well,
we
are
seeing
especially
wax,
for
example,
is
seeing
limitations
of
being
able
to
run
one
chain
in
how,
for
example,
the
amount
of
accounts
that
it
can
facilitate
on
one
chain,
the
amount
of
actual
wax
accounts
or
EOS
accounts,
or
whatever
it
was.
The
amount
of
accounts
on
one
chain
having
faster
finality
combined
with
IBC
in
between
EOS
IO
iterations
opens
up
the
potential
for
horizontal
scaling,
like
we've
never
seen
before,
and
this
is
just
a
small
glimpse
of
it.
D
But
this
idea
that
you'd
be
able
to
potentially
spin
up
new
chains
purpose
chains
that
would
link
together
and
being
able
to
transfer
between
them.
If
we're
talking
about
faster
finality,
let's
say
between
one
and
six
seconds
on
both
sides.
Right
so
let's
say
it's
between
EOS
I
o
and
they'll
say
oh
and
it's
a
simple
transaction
and
it's
a
one.
Second
thing
that
means
within
a
very,
very
respectable,
let's
say
2
to
12
seconds.
D
You
could
transfer
between
chains,
you'd
effectively
be
able
to
and
we're
not
there
yet
but
you'd
be
able
to
scale
horizontally
the
network
in
a
way
kind
of
unlocking
infinite.
Scalability
we're
not
there
at
all.
Yet,
but
that's
you
know
one
of
the
possibilities
that
comes
out
of
having
both
of
them
together
and
that's
one
of
the
reasons
why
the
Coalition
really
in
this
market,
if
you
go,
listen
to
the
I,
believe
it's
the
last
Thursdays
call
wasn't
a
way
faced
with
a
decision
of.
D
D
B
Yeah,
I
guess
that's!
That's
that
that's
exactly
it!
From
my
perspective,
I've
been
in
the
crypto
space
for
quite
a
while
and
back
in
2011,
when
I
first
got
interested
in
Bitcoin.
There
was.
There
was
a
this.
This
website
called
Bitcoin
thought
that
was
essentially
like
a
forum.
A
lot
of
very
interesting
discussions
were
taking
place
there
and
there
was
a
a
user
of
Bitcoin
talk.
His
name
was
tier
Nolan,
his
nickname.
B
He
came
up
with
the
essentially
what
was
the
I
believe,
the
first
atomic
swap
model,
so
the
idea
was
to
create
a
transaction
that
would
trustlessly
allow
you
to
exchange
two
different
cryptocurrencies.
He
was
giving
the
example
Bitcoin
and
Litecoin
in
a
way
that
would
ensure
that
none
of
the
two
count,
the
parties,
that
trade
could
essentially
like
steal
the
funds
from
the
other
and
they
would
have
to
complete
simultaneously
in
one
Atomic
transaction
against
the
name
and
I
was
quite
fascinated
by
by
this.
B
B
On
code
that
would
allow
to
do
that,
which
I
ended
up
doing
in
2012,
give
or
take,
and
once
I
kind
of
saw
it
happen
like
I
was
able
to
make
a
transaction
between
Bitcoin
and
Litecoin
I
realized
that
there
was
something
very
important
about
the
ability
to
communicate
and
exchange
value
between
chains
and
now
fast
forward.
Many
years
in
2018,
when
yes
was,
was
launched.
B
We
were
part
of
that
launch
process.
I'm
the
CEO
of
blood
producer
called
yes
Titan
for
those
producers,
and
essentially
we
were
one
of
the
key
reasons
why
we
were
so
interested
in
yes
in
general,
was
that
promise
of
an
interlock
chain,
communication
mechanism
and
I,
remember
being
really
fascinated
when,
when
Dan
Larimer
showed
up
on
one
of
the
zoom
calls
with
the
blood
producers
and
started
explaining
his
idea
for
for
for
IPC
and
I
was
like
great.
This
is
just
around
the
corner.
B
He
was
saying
like
yeah.
We
should
have
that
like
in
a
couple
of
months
from
now,
and
that
was
back
in
2018
and
I
waited
and
I
waited
I
waited
and
that
never
came
so
at
some
point,
I
was
like
okay,
like
better,
better
look
into
that
thing
and
start
see
if
I
can,
if
we
can
build
it,
because
that's
actually
really
really
cool
and
very
important
to
the
future
of
the
solar
industry.
B
So
like
of
course,
of
course,
a
lot
of
other
people
have
been
thinking
about,
interchange,
Communications
and
there's.
There's
always
you
know
like
shortcuts
that
you
can
take
to
get
there,
one
of
which
is
to
use
oracles
that
are
essentially.
You
know
the
group
of
call
them
Witnesses,
validators
or
whatnot
that
will
monitor
what's
happening
on
one
chain
and
based
on
what's
happening
there.
They
will
take
an
action
on
a
smart
contract
on
another
chain.
B
So
you
can
imagine
how
that
would
work
where
someone
looks
some
token
on
chain
a
and
then
the
oracles
witness
that
the
tokens
have
been
locked
and
then
they
would
essentially
create
a
transaction
on
chain
B,
where
they
would
Mint
new
tokens
like
wrap
tokens,
and
then
these
wrap
tokens
could
be
used
on
chain
B
and
moved
around
stole
the
exchanged
transferred
whatever
and
then
you
would
essentially
redeem
them
for
the
original
Thing
by
the
original
token,
by
burning
them.
So,
like
again,
you
would
burn
these
tokens
on
chain
B.
B
Thinking
about
like
Ronin
and
Wormhole,
and
all
of
these
mechanisms
that
we're
using
a
similar
type
of
multi-sig
structure,
they
are
very,
very
big
vectors
in
attack.
So
for
us
it
was
very
important
for
me
to
get
go
to
design
an
IBC
solution
that
would
be
completely
trustless
and
when
I
say
completely
trust.
This
is
what
I
mean
really
is
that
it
should
use
cryptography
and
not
trust
in
some
special
people
or
some
appointed
people
to
permit
transactions
across
chains.
So
I.
E
So
I
I
do
want
to
push
back
on
that.
That
claim
a
little
bit,
because
my
view
is
that
these
are
all
fundamentally
Oracle
based
it's
just
so.
There
is
trust
in
this
IBC.
It's
trust
in
the
consensus
algorithm
of
the
source
chain
right,
so
you
send
information
from
the
source
chain
to
destination
chain.
How
does
the
destination
chain
know
that
this
message
is
authentic?
C
E
D
E
Yeah,
it's
important
to
Define
what
we
mean
by
trustless,
but
the
reason
I
think
this
is
relevant
is
because
in
this
what
we
were
talking
about
earlier
of
this
wider
ecosystem
of
chains,
communicating
together
to
scale
if
the
chains
are
effectively
the
same
governance
model
right
and
they're
just
using
different
chains.
Then
the
fact
that
you
trust
one
Shard
means
you
could
just
trust
the
other
shards
as
well,
because
they're
the
same
trust
right.
This.
D
Completely
trusting
the
validators
or
the
consensus
mechanism
of
one
or
the
other
that
you're
transacting
through
I
agree,
but
that's
implicit,
so
it's
by
default.
That
happens.
So
it's
not
adding
an
extra
layer
of
trust
which
typically
comes
in
the
form
of
an
oracle.
So
if
you're
already
there,
you
you've,
already
gone
through
you've
already
passed.
That
boat
you've
already
crossed
that
line
essentially
but
you're
right
that
you
need
to
trust
the
original
Source
chain
and
the
outgoing
chain,
but
you're
already
there.
E
E
G
E
C
E
D
I,
don't
trust
the
consensus
mechanism
of
ethereum,
why
am
I
sending
the
the
value
to
a
theorem
in
this
example
or
to
whatever
chain
right
like
I'm,
making
that
decision,
and
so
in
that
decision
I
am
the
actual
bottleneck,
not
necessarily
the
trust
within
the
chain
and
I
think
that
that's
what's
very
different
with
what
is
currently
being
implemented
or
will
be
implemented
with
everything
else.
We've
seen
on
the
market
is
everything
else
that
we've
seen
on
the
market?
Doesn't
not.
It
doesn't
solely
rely
on.
D
In
this
example,
the
EOS
validators
and
the
ethereum
validators
IT
inserts
a
third-party
validator
in
between,
and
that's
where
I'm.
That's.
Why
I
agree
with
the
the
the
the
wording
that
it
is
trustless,
because
those
two
are
implicit
at
the
onset?
The
third
one
is
the
one
that's
not
being
added
in
the
mix.
If
that
makes.
E
E
There's
there's
a
way
you
can
go
further,
where,
if
you
could
actually
prove
there's
zero
knowledge
proofs,
the
entire
logic
of
the
other
chain,
then
you're
still
vulnerable
to
like
false
history,
attacks
double
spend
kind
of
things,
but
you're
never
going
to
believe
something
that
violates
an
invariant
of
the
overall
system.
But
that's
like
the
next
level,
which
is
Cutting
Edge
stuff.
But
no,
that's.
That's
like
that's,
like
cryptographers
need
to
find
better
ways
to
speed
up.
B
B
I
personally,
love
that,
by
the
way,
this
this
pushback
versus
pushback,
all
that
stuff
I
actually
actually
agree
with,
with
the
both
of
you
and
I
guess:
I
guess,
like
it's
absolutely
correct.
If
you
I
mean
if
you
are
using
a
blockchain,
especially
proof
of
stake,
blockchain
such
as
well
D
Plus
in
the
case
of
yes
but
such
as
yes,
it
is.
It
is
some
there's
some
degree
of
trust
in
the
validator
set
of
that
chain.
B
That's
implicit
and
then,
of
course,
if
you
are
moving
value
from
yes
to
another
similar
chain,
let's
say
wax
for
this
example.
It's
also
it's
also
I
guess
in
an
implicit
way.
You
are
also
trusting
the
validators
of
wax
to
do
good
by
the
transactions
that
occur
there
and
not
overrule
the
your
decision.
As
a
user,
not
you
know,
steal
the
funds
that
are
in
the
account
or
whatnot
when
we
build
ripc
system.
B
That
was
that
was
our
definition
of
trustlessness,
essentially
like
it
was
assuming
that
you
are
interesting,
the
validators
of
chain
a
and
that
you're
already
trusting
the
validators
chain
B.
We
wanted
a
solution
to
not
require
any
additional
trust
in
any
additional
party
outside
of
these
two
sets
of
validators.
So
that's
what
we
mean
when
you
say
it's
trustless
now,
there's
there's
also
the
questions
that
can
that
derive
from
this,
and
it's
quite
interesting
for
those
for
the
students
of
crypto
history.
B
Block
size
Wars,
where
some
people
at
the
time
at
the
time
it
was
that
was
a
little
bit
before
blood
cash.
Sorry
Bitcoin
cash.
It
was
something
called
Bitcoin
ABC
if
I
remember,
right
and-
and
even
even
like
a
little
bit
before-
that
the
question
of
the
block
size
became
quite
hot
debate
between
various
losers.
B
Bitcoins
winner
Bitcoin
should
increase
the
size
of
the
blocks
from
one
megabyte,
maybe
to
two
megabytes
or
four
megabytes
or
eight
megabytes,
and
people
were
essentially
saying
like
here
are
some
pros.
Here
are
some
cons
and
there
were
well.
There
was
quite
a
bit
of
a
debate
around
the
question
and
ultimately
there's
a
number
of
things
that
that
happened
during
during
that
time
period.
B
But
one
of
the
very
interesting
one
was
that
there
was
a
coalition
of
Bitcoin
miners
that
tried
to
force
the
activation
of
some
of
these
changes
to
the
Bitcoin
Network
and,
ultimately,
that
Force
change
was
actually
prevented
by
a
a
like
the
threat
of
a
user
activated
soft
Fork.
So
the
idea
was
that
the
users
a
lot
of
prominent
users
in
the
Bitcoin
ecosystem,
and
that
includes
exchanges
that
includes
individual
users.
B
What
else
and
whatnot
came
together
and
said
like
if
the
miners
go
ahead
and
try
to
push
this
increase
the
blood
size?
We
will
simply
go
our
own
merry
way
for
the
network
and
keep
it
as
it
is.
So
so
that's
quite
interesting
because,
essentially,
what
that?
What
that
means?
Is
that,
ultimately,
that
the
game
theory
behind
this
is
the
full
node
users
ended
up
deciding
not
the
miners,
not
the
validators,
but
the
full
node
users.
B
So
everyone
that
was
running
a
full
node
on
bitcoin
were
not
necessarily
miners,
but
they
ended
up
deciding
that
they
would
not
honor
the
changes
that
the
miners
were
presenting.
So
so,
in
a
sense
yes,
yes,
I
O
in
general,
like
vanilla,
yes,
IU
has
a
different
model
than
that,
because,
ultimately,
the
block
producers
have
this
God
Mode
Power,
where
they
can
decide
what
a
super
majority
to,
for
example,
change
the
keys
to
an
account
or
to
overwrite
the
code
of
a
smart
contract
and
so
on
and
so
forth.
B
So
so
it
is,
it
is
in
that
sense,
I
mean
there's,
there's
pros
and
cons
of
that
approach.
Pros,
of
course,
include
the
restitution
of
funds
from
people
that
maybe
fall
victims
of
the
hack.
If
those
smart
contracts
get
hacked,
there's
there's
the
possibility
that
blood
producers
can
recover
the
funds
before
too
much
damage
is
done.
There
are
cons
as
well,
because
now,
of
course,
the
immutability
question
of
smart
contracts
is
in
question
and
one
of
the
things
that
we
we
doing
in
the
ux
network
side
of
things
is.
B
We
introduced
the
a
similar
mechanism
than
what
you
have
on
the
Bitcoin
Network,
where
the
it's?
Actually
it's
actually
a
bit
more
complex
than
that,
but
what
it
allows
the
user
to
do
is
to
Mark
a
smart
contract
as
immutable
and
then
prevent
even
a
super
majority
of
blood
producers
from
altering
the
permissions
and
the
the
code
to
a
Smart
contract.
So
that's
quite
that's
quite
an
interesting
feature
that
I
think
we
came
up
with
it's.
B
We
have
in
mind
that
we
would
like
to
eventually
build,
but
to
me
this
is
something
that
I
feel
should
also
be
discussed
as
part
of
similar
similar
questions,
because,
ultimately,
there's
there's
a
need,
in
my
opinion,
for
true
immutability
or
smart
contracts
that
would
prevent
even
the
validators
in
the
blood
producers
of
the
network,
from
modifying
every
single
contract
or
being
able
to
you
know
like
eventually
like
override
the
code,
so
I
mean
on
ethereum.
For
example,
you
can't
override
the
code
of
a
smart
contract.
B
I
mean
there's,
there's
potentially
ways
around
some
of
the
of
the
the
immutability
considerations,
but
in
a
sense
this
this
code
is
law
versus
what
then
I
remember
was
calling
intent
of
code.
Is
law
I,
don't
think
it's
a
fully
settled
question
yet,
and
I
would
love
to
hear
more
from
others
in
the
space
about
whether
their
thoughts
regarding
this.
D
E
D
Two
is
the
amount
of
developer
power
that
is
now
back,
leading
and
guiding.
Eos
development
is
is,
is
quite
immense
and
it
is
much
greater
than
what
we've
seen,
let's
say
in
the
last
two
years
give
or
take
or
so
and
so
in
terms
of
Promise
in
terms
of
Direction.
In
terms
of
tangent,
you
know
change
we
we
are.
D
You
know
in
a
year
or
so
they
already
have
this
functional,
and
so
the
idea
is
we
would
be
able
to
as
a
coalition
deploy
this
on
our
respective
chains
over
the
next
two
months,
depending
on
on
the
parameters
that
we
need
to
come
up
with
and
such.
But
it
is
realistic
that
EOS
IO
chains
between
the
Aussie
o
chains
could
have
IBC
within
you
know
by
the
end
of
the
summer,
type
of
thing
or
very
early
fall,
and
so
that
to
me
is
extremely
exciting.
D
D
E
Well,
I
think
well
so
the
conversation
was
going
to
immutability,
but
I
think
you
brought
you
brought
it
back
to
IBC
I!
Think
it's
worth
wrapping
that
up
and
then
we
can
discuss
immutability.
If
we
have
time
if
we
want
to
so
I'll
let
Guillaume
talk
about
the
I
received
that
I,
guess
and
I
can
add
as
needed.
E
B
I
mean
I,
guess,
I
guess,
from
from
our
step,
one
I
was
I
was
explaining
just
a
little
bit
how
we
came
up
with
like
why
we
decided
to
start
working
on
IBC
and
then,
of
course,
when
it
comes
to
trustlessness,
then
that's
why
I
did
this
little
segue
into
the
the
mutability
aspect
of
things,
but
it's
it's.
It's
definitely
a
different
topic
that
I'll
be
happy
to
come
back
on
again.
B
Another
fireside
chat
at
some
point
to
discuss
more
in
detail
if
that's
of
interest
to
the
rest
of
the
audience,
but
to
to
summarize
to
wrap
up
the
a
bit
on
IBC
Eve
is
actually
a
correct.
The
the
for
us
IBC,
as
as
we
as
I,
was
saying
when
we,
when
we're
originally
heard
Daniel
I,
remember
talking
about
it.
We
got
really
excited
about
the
general
concept.
B
We
waited
for
a
few
years
for
a
viable
solution
to
be
released
and
then,
as
we
said,
I
was
not
happening.
We
decided
to
start
looking
into
this
ourselves
and
I
believe
I,
believe
it
was
towards
the
end
of
2019
that
we
started
kind
of
doing
some
research
trying
to
figure
out
a
way
to
get
there
and
around
the
end
of
2020.
We
had
a
proof
of
concept
prototype
that
was
essentially
demonstrating.
B
What
we
had,
we,
we
discussed
at
the
time
with
block
one
Eric
was
one
of
the
local
engineers
at
the
time.
I
would
have
a
look
at
what
we
were
doing
and
essentially
we
we
kept
working
on
it,
kept
refining
it
kept
improving
various
aspects
of
it,
and
it
was
always
a
you
know
like
a
kind
of
a
chicken
and
egg
problem.
Where
how
do
you
go
about
releasing
this?
How
do
you
go
about
because
I
mean,
as
I've
said
before,
Bridge?
Nowhere
is
not
really
useful.
B
So
our
IBC
approach,
kind
of
kind
of
deals
with
both
of
them
both
of
these
use
cases,
whether
it's
communication
between
chains
that
are
completely
different
with
completely
different
set
of
validators
or
it
can
also
be
applied
to
the
sidechain
model,
which
may
have
either
the
same
validators.
Then
it's
it's
parent
chain
or
approximately
a
subset
of
these
validators
and
generally
like
you,
could
you
could
even
consider
a
scenario
where
these
side
Chains
would
not
have
their
own
token,
but
would
also
rely
on
the
main
chains
token.
B
D
B
So
I'm
not
I'm,
not
I'm,
not
exactly
sure
what
their
proposal
was.
I
know
that
at
some
point,
I
think
during
pomelo
season
one
there
was
a
one
of
the
proposals
for
funding
was
to
create
an
IBC
solution
and
I
believe
it
was
the
Boyd
team
that
was
behind
that
one.
What
they
were
saying
is
they.
They
were
going
to
match
a
the
metal
contribution
up
to
fifty
thousand
dollars
or
something
for
a
an
IBC
solution
and.
B
B
It's
probably
doable.
It's
probably
something
that
can
be
done.
I've
been
looked
into
much
detail
about
the
cosmos
IBC.
Although
I
know
it's
it's
one
of
it's
one
of
the
ones
that
I
prefer,
because
they
are
also
using
cryptography
and
they're,
also
not
relying
on
oracles
and
whatnot.
The
whole
customer
support
system
is
actually
quite
good
from
technical
standpoint.
B
For
you
know
like
conversion
to
the
cosmos,
you
know
like
the
way
of
doing
things
and
so
on
and
so
forth.
So
to
me,
I
I,
I,
I,
would
say.
I
would
say,
like
our
approach.
I
think
is
better
in
that
regard.
It's
native
to
esio
and
does
not
does
not
require
implementing
some
kind
of
slots
around
to
just
harmonize
it
with
something
else,
but
I
believe
that
in
a
sense
in
what
it
does
and
how
it
works,
there's
quite
a
bit
of
similarities.
B
B
See
if
he
has
anything
else,
but
I
mean
from
our
standpoint,
this
is
this
is
what
we,
what
we
essentially
when
we
did
our
research.
Initially
before
we
got
started
on
IBC.
We
reviewed
just
about
everything
that
was
available
and
it
Cosmos
did
come
up
as
one
of
the
one
of
my
favorite
approaches,
but
it
had.
B
It
had
like,
like
I,
said
like
it's,
it's
built
for
the
cosmos
and
Thunderman
ecosystem,
and
it
has
has
in
software
in
general,
if
you're,
trying
to
adapt
to
another
technology,
stack
typically
you're
going
to
have
you're
going
to
incur
some
overhead
when
it
comes
to
converting
different
different
things,
so
that
they
work
with
the
other,
the
other
ecosystem.
So
that's
why
I
I
prefer
prefers
like
sticking
to
a
native
solution.
B
I
I
still
I
mean,
despite
all
of
the
issues
that
we've
seen
with
token
price,
with
block
one
and
whatnot
I
still
believe
that
the
sio
is
a
superior
foundation
for
the
building
like
smart
contracts
and
blockchains,
so
I
mean
I.
Think
I.
Think
the
despite,
despite
everything
else,
block,
wanted
a
really
really
good
job
in
building
this.
As
a
as
a
software
platform,
so
I
think
I
think
we're
better
off
sticking
to
sticking
to
the
the
native
solution.
D
B
I
I
am
not
very
familiar
with
avax
or
with
subnets,
so
I'm
not
100
sure
what
the
differences
would
be,
but
the
idea
in
general
and
I
mean
this
is
probably
a
little
bit
more
along
the
lines
of
what
Dan
and
I
remember
proposed,
originally
in
terms
of
IBC.
If
I
remember
correctly
at
the
time
when
this
was
floated
around
coming
soon
type
of
feature,
they're
they're,
Dynamics
proposal,
the
block
producers
would
remain
the
same
across
multiple
of
the
multiple
sidechains.
B
So
then
you
would
have
your
21
block
producers.
They
will
also
be
running
potentially
an
Infinity
of
side
chains
and
they
would
they
would
basically,
you
know
like
we
can
think
of
it
as
a
I.
Don't
know
like
that,
multiple
different
silos
that
each
of
them
do
their
own
thing
and
then,
whenever
there's
a
need
for
communicating
between
these
silos,
there's
there's
a
small
pipeline
where
you
can
essentially
move
tokens
or
exchange
messages
between
these
these
silos.
B
So
that's
that's,
that's
interesting,
but
that's
also
I
think
a
bit
limiting,
because
the
the
issue
that
we
see
right
now
is
that
when
you
come
when,
when
it
comes
to
running
yes,
I
O,
especially
on
a
very
very
high
I
guess,
activity
chains
such
as
wax
the
the
material
costs
of
running
a
block
producer
increase
dramatically
and
probably
one
of
the
most
difficult
to
scale
aspect
is
Ram.
So
it's
not
necessarily
it's
not
necessarily
easy
to
to
run
multiple
side
chains
with
the
same
set
of
producers.
B
Some
blood
producers
may
be
more
specialized
in
you
know
like
I,
guess,
like
governance
or
writing
software,
some
of
them
might
be
specialized
more
in
running
infrastructure
and
so
on
and
so
forth.
So
I
think
there's
there's
some
respect
some
consideration.
That
needs
to
be
given
to
the
technical
proficiency
of
various
block
producers
when
it
comes
to
deciding
how
you
want
to
scale
this
thing.
So
my
opinion
and
it's
just
an
opinion.
What's
can
of
course
tackle
that
problem.
B
The
way
they
want
them,
Every
Chain,
has
a
program
as
well
would
be
to
possibly
create
a
model
where
a
subset
of
blood
producers
would
be
able
to
run
these
side
chains,
so
so
assuming,
for
example,
that
you,
you
have
21
block
producers
on
the
Chain
plus,
maybe
like
50
standby
block
producers.
My
idea
would
be
to
for
a
sidechain
model
to
be
able
to
tap
into
that
quote:
quote
unused
resource,
which
is
a
standby
block
producers
and
possibly
allow
them
to
run
side
chains
that
would
connect
with
the
main
net.
B
So
now
you
would
add
the
ability
to
kind
of
organized
the
permissive
network
based
on
their
technical
proficiency
based
on
some
degree
of
the
bus
ranking.
They
need
to
still
be
voted
in
better
by
the
community,
but
then
they
could
they
could
get
a
task
of
running
a
side
chain,
for
example,
and
that
will
connect
with
them.
So
I
think
I.
Think
if
we
compare
this
to
Dan
larimer's
original
proposal,
the
the
I
I
believe
that
this
approach
would
yield
more
flexibility.
Again.
B
It's
still
still,
you
know
up
to
the
individual
chains
to
decide
how
they
manage
the
governance
process,
but
to
me,
I
feel
like
there's,
there's
a
lot
of
untapped
resources
in
these
standby
block
producers
that
are
essentially
being
paid,
sometimes
for
not
doing
very
much.
So
that's
my
that's
my
kind
of
take
on
the
question.
D
B
Who
should
be
the
validators
on
these
side
chains
and,
of
course,
I
mean
you
can
probably
add
to
that.
Also
like
application
change
change,
which
don't
necessarily
even
who
require
more
than
one
blood
producer,
you
could
run
an
application
chain
which
would
be
just
you
know,
like
one
dap
running
their
own
chain
and
still
be
able
to
communicate
with
other
side
chains
or
the
main
Network
as
well.
B
So
it
kind
of
it's
kind
of
come
back
to
what
he
was
saying
earlier,
we're
focusing
mostly
on
the
technology
aspect
of
the
of
the
software.
When
it
comes
to
governance,
we
we
want
to.
We
want
to
keep
the
door
open,
but
let
the
the
various
communities
and
stakeholders
take
these
decisions.
These
are
complex
decisions.
They
have
a
lot
of
implications.
B
D
And
just
to
add
to
what
Yom
said
as
well,
one
of
the
the
Well
from
my
point
of
view,
because
my
my
mission
mandate
is
to
the
EOS
token
holders-
and
that's
that's
very
well
within
the
Coalition
as
well-
is
to
represent
the
our
shareholders,
which
are
the
EOS
token
holders.
One
of
the
good
things
about
these
proposals
is
that
there
are
Milestone
based.
D
So
essentially,
if
yum
doesn't
do
the
job,
he
doesn't
get
paid,
put
it
as
bluntly
as
possible,
and
so
it
really
still
puts
the
the
power
in
the
hands
of
those
that
are
guiding
this
process
and
it
really
incentivizes
or
It
lines.
Incentives
to
ensure
that
multiple
things
one
is
that
even
throughout
this
process,
the
ux
team
in
this
particular
example
of
faster
finale
in
IBC
they've,
been
very
much
open
to
the
architectural
and
design
considerations
of,
for
example,
the
three
other
Coalition
members.
D
So
we've
been,
you
know
we
had
a
call.
Yesterday
we
had
a
few
calls
on
the
subject
over
the
last
couple
of
weeks,
but
here's
what
they
have
right.
Now,
here's
what
it's
going
to
look
like
in
the
future
and
now,
as
essentially
kind
of
the
client
ux
being
a
client
as
well,
because
it's
part
of
the
Coalition
too,
but
as
as
the
client
we're
able
to
work
with
the
in
this
case
at
high
level,
the
vendor
to
determine
and
and
to
work
with
them.
These
are
our
requirements.
D
B
Yeah
and
that's
that's
very
good
point-
I
mean
just
just
an
example,
for
example,
with
regards
to
personality
when
the
BBN,
the
ux
network
team
and
the
originally
company,
when
we
start
looking
into
that,
are
pretty
much.
Our
sole
Focus
was
to
improve
the
user
experience
of
IVC
and
to
make
it
easier
also
to
connect
with
other
chains.
But
then,
as
we
started
discussing
this
with
the
other
members
of
the
Coalition,
we
learned
that
Telos
their
interests
and
password
finality
had
to
do
with
the
increase
of
blood
producers.
B
They
were.
They
were
very
interested
in
increasing
the
number
of
blood
producers,
but
they
were
limited
right
now
because,
as
Eric
was
saying,
adding
under
the
current
model,
adding
more
about
producers
increases
the
time
to
tonality
in
a
linear
fashion,
which
is
not
very
good.
So
for
them,
that
was,
that
was
one
of
the
main
requirements
was
actually
to
to
allow
for
more
block
producers
and,
as
we
discussed
us
as
everyone
brings
their
own
considerations
with
the
table
same
thing
with
wax.
B
For
example,
when
they
started
when
you
started,
collaborating
part
of
the
Coalition
wax
were
telling
us
what
kind
of
problems
they
were
running
into
right
now,
with
Ram
limitations
and
limitations
of
the
number
of
accounts
that
we
can
have
on
chain
and
their
need
for
side
chains.
That
opens
up
also
like
more
possibilities
for
us
to
adjust
our
proposal
in
our
software
to
to
also
take
care
of
these
other
considerations,
so
I
think
I
think
all
in
all,
it's
been
a
very,
very
fruitful
exercise.
B
So
far,
a
lot
of
a
lot
of
very
good
ideas
have
been
floating
around
and
I
also
also
need
to
to
highlight
Eric's
contributions
to
these
discussions,
because
he's
brought
a
lot
of
very
good
points
on
how
we
can
get
further
optimize,
how
we
can
further
increase
the
the
range
of
options
and
minimize
the
negative
aspects
of
taking
certain
trade-offs
and
so
on
and
so
forth.
So
it's
been.
D
Yeah
as
operators
of
the
software
right,
so
the
actual
users
of
the
software.
Where
are
the
limitations?
Where
are
the
current
pain
points,
and
so
the
feedback
is
also
not
given
in
a
void.
The
solution
isn't
being
delivered
without
the
consideration
of
the
actual
users
of
the
product.
Ultimately,
that's
I
mean
that
is
something
that
we've
never
had
as
EOS
or
actually
any
of
the
chains.
D
We've
seen
a
very
very
I
mean
very
rapid,
but
also
very
significant,
Direction
and
collaboration
that
that
started
occurring
where
people
now
are
not
only
empowered,
they're
incentivized
to
be
able
to
upgrade
the
software
to
be
able
to
partake
in
the
upgrading
of
the
software
or
in
the
direction
of
how
the
software
will
be
upgraded.
And
so,
if
you
go
look
at
GitHub
the
amount
of
work
that's
been
done
over
the
last
couple
months,
and
now
you
amplify
it
with
the
Coalition
and
other,
essentially
the
largest
users
of
the
software.
D
Outside
of
from
our
point
of
view,
EOS
right
coming
at
the
table,
you
now
have
other
networks.
Other
communities
coming
in
and
saying
hey,
I've
always
wanted.
This
I've
always
had
an
issue
with
this
or
I've.
You
know
I've
wanted
to
have
this
at
the
core
protocol
level.
Now,
there's
a
mechanism
for
us
to
do
so
all
open,
transparent
collaborative
and
for
me,
that's
just
been
an
incredible
thing
to
be
a
part
of
at
ux
Telos
wax
I
mean
the
Coalition
six
months
ago.
K
D
Out
since
that's
curbed,
the
the
strength
of
the
four
players
that
ultimately
decided
to
join
I
would
say
and
I
don't
know
what
your
take
is
on
this,
but
the
amount
of
collaboration
and
the
even
though
we're
all
competitors
to
a
certain
degree,
the
amount
of
collaboration
and
overlap
and
and
work
towards
a
common
vision
is,
is
just
incredible.
It's
been
really
amazing
to
be
able
to
see
that
and
that's
something
that
we
did
not
see
at
all
in
the
last
four
years.
B
Everyone
is
kind
of
focusing
on
their
own
niches,
and
everyone
has
their
own
I.
Guess,
like
you
know,
like
markets
and
their
their
own
Focus.
We
at
ux
are
really
going
more.
The
the
D5
route
like
this
is
what
we
are
interested
in
guys
at
wax
are,
are
going
more
to
gaming
route
and
I
mean
yes
has
been,
and
Telos
has
been
very,
very
involved
in
the
governance
and
kind
of
like
setting
up
proper,
proper,
centralized
governance
rules
and
so
on
and
so
forth.
B
So
there's
there's
quite
there's
quite
a
bit
of
of
a
there's,
some
overlap
for
sure,
but
there's
also
quite
a
bit
of
differences
in
the
markets
and
purpose
of
these
chains,
and
if
you,
if
you
even
bring
non-coalition
members,
it
goes
even
further
than
that.
As
we
were
discussing
in
the
early
days
with
other
esio
chains,
there
were
even
some
private
chains
that
were
that
were
running.
You
know,
like
you
can
think
of
you
know
like
bullish
and
voice
and
Eva,
for
example,
a
ride
sharing
platform.
B
They
were
also
very
interested
in
what
we
were
doing.
So
it's
not
it's
not
it's
not
like
it's
not
that
there's
we
don't
have
to
be
in
competition.
This
is
a
big
enough
buy
for
for
everyone
to
find
their
to
find
their
their
spot
and
their
Niche,
and
the
one
thing
that
unites
us
is
the
same
code
base.
Is
the
the
yes.
B
So
it's
for
me,
it's
a
no-brainer.
It's
like
this
is
this
is
this
is
how
it
should
be.
It
should
be
collaborating
on
what
we
share
and
still
do
our
own
thing
go
our
separate
ways
when
it
comes
to
Market
it
to
bring
it
to
to
to
our
respective
communities
but
I
think
it's
the
best
of
both
worlds.
We
can.
We
can
keep
innovating
in
each
in
our
separate
areas,
while
also
sharing
what
is
common
to
all
of
us.
B
B
There's
there's
two
parts
in
in
IBC
or
two
main
parts
that
I
would
say
that
there's
there's
on
one
side,
there
is
Gathering
proofs
of
an
action
occurring
on
some
Source
chain
and,
on
the
other
side,
verifying
the
validity
of
that
proof
on
a
destination
chain.
So,
for
example,
we
also
built
an
evm
verifier.
B
So
when
it
comes
to
when
we
create
a
proof
save
from
the
yes
I
O
side
of
things,
we
can
also
verify
the
validity
of
that
proof
on
any
evm
based
chain
and
then,
when
it
comes
to
verifying
on
an
esio
chain,
a
proof
that's
been
generated
on
another
chain
such
as
ethereum
or
binance.
We
also
we're
also
working
on
building
these
modules
so
as
to
include
as
many
chains
as
possible.
B
So
everything
that
has
to
do
with
evm
is
is
a
bit
easier
like
when,
when
because
we've
done
it
once
so
like
any
evm
based
chain,
the
verifier
should
work
with
little
to
no
modification
when
it
comes
to
verifying
on
esio
actions
that
occur
on
another
chain,
such
as
binance
ethereum,
it's
a
different,
it's
a
different
Beast.
You
have
to
kind
of
do
it
like
on
a
chain
by
Chain
basis,
because
they
all
have
their
own
consensus
mechanism.
B
Ethereum,
of
course,
is
using
currently
using
proof
of
work
at
some
point
in
the
future
seems
that
they're
going
to
be
moving
to
a
proof
of
stake
model
binance
uses
something
that
they
call
proof
of
authority.
Solana
uses
something
called
proof
of
history,
and
each
chain,
FX,
is
using
snowmen
consensus
and
each
shame
has
their
own
mechanism.
H
Ideally,
all
of
the
bottlenecks
and
ux
issues
can
be
avoided
completely
because
you
have
someone
who's
so
focused
on
the
client-side
experience
and
so
in
tune
with,
what's
going
on
at
the
protocol
level
that
by
the
time
these
products
are
released,
we'll
have
a
great
user
experience.
I
just
wanted
to
shout
out
Aaron
as
also
being
a
core
contributor
to
the
coalition.
B
B
And
Aaron
has
been
also
also
been
working
on
a
proposal
for
improving
client-side
sdks,
making
it
easier
for
that
developers
to
build
great
user
experience
and
low
friction
interfaces
with
wallets
and
so
on
and
so
forth.
So
I
mean
when
it
comes
to
this.
This
collaboration,
one
of
the
really
good
benefits,
is
now
as
we're
discussing
say.
Ibc
Aaron
can
also
start
thinking
as
he's
working
on
these
sdks
okay.
How
can
I
make
these
sdks
work
with
this
IBC
and
improve
the
user
experience
at
that
level?
J
Yeah
you've
used
the
word
holistic
earlier
and
that's
very
much
the
approach
we
should
be
taking
and
trying
to
get
those
opinions
from
different
Realms
of
this
I
mean
these
features
are
so
powerful.
Just
and
I
I
really
don't
want
to
compare
these
two
things,
but
because
this
is
what
I'm
trying
to
prevent
I
don't
want
to
see
another
situation
like
power
up
where
we
get
a
great
feature.
J
Potentially,
that
just
is
it's
delivered
80
of
the
way
block
one
kind
of
didn't
have
that
holistic
approach,
because
they
never
got
into
the
wallet
space
seriously,
and
you
need
to
make
sure
we're
doing
that.
The
user
experience
is
so
critical,
both
from
the
technical
perspective
like
you
guys
were
talking
about
in
order
to
reach
faster
finality
and
from
like
the
actual
buttons
they
click
in
the
words
they
read.
So
it's
a
big,
complicated
process
that
we
need
to
see
through
end
to
end.
B
B
So
we
have
also
a
digital
Maniac
that
was
asking
is
IBC
and
trusty
VM
connected
in
this
case.
It
doesn't
have
to
be
because
essentially
like
electricity
VM
is
a
it's
kind
of
a
let's
call.
It
like
an
add-on
to
a
yes
to
be
able
to
execute
solidity
based,
or
rather
like
evm
based
smart
contracts,
but
since
it's
already
resting
upon
the
the
yasai
architecture
natively,
we
don't
have
to
use
it.
For
that
particular
particular
case
of
IBC.
B
D
In
this
particular
case,
I'm
talking
about
IBC,
can
you
touch
upon
any
because
I
I
know
you've
you've
done
some
back
and
forth
about
this.
But
can
you
touch
upon
certain
things,
for
example,
more
concretely
on
what
you'd
like
to
see
and
how
you'd
like
to
see
implemented
and
what
you
would
like
to
fulfill
as
a
role
to
ensure
that
that
user
experience
from
the
get-go
is
something
that's
taken
into
consideration
and
not
replicate
what
historically
onions
has
been
the
norm
and
more
so
to
that?
D
Do
you
think
that
it's
possible
to
within
the
current
learning,
for
example,
if
we
take
IBC
or
or
faster
finality
or
any
of
the
other
initiatives
that
we're
working
on?
Do
you
think
that
it's
possible
to
use
those
as
test
cases
to
document
so
that
going
forward
whenever
we
have
more
of
those
come
about
that
we
actually
have
a
mechanism
in
the
process
a
framework
around
what
else
is
required
and
what
should
we
we
be
looking
at
to
ensure
a
particular
successful
deployment
of
said
features?
J
Our
team
really
serves
two
audiences
out,
one
which
I
mean
I
think
everybody
is
most
familiar
with,
is
providing
like
wallet
interfaces
for
people
to
sign
transactions.
With
from
that
perspective,
when
I
looked
at
the
IBC
solution,
I
saw
things
like
you're
gonna
have
to
log
in
twice
one
for
each
blockchain
and
then
you're
gonna
have
to
perform
two
transactions,
one
for
each
blockchain
on
a
mobile
experience.
J
J
So
now,
we've
reduced
multiple
logins
down
to
one
there's
also
the
possibility
that
we
could
do
this
with
transactions.
With
the
EOS
IO
signing
request
protocol,
we
could
take
and
bundle
multiple
transactions
for
different
chains
into
the
same
payload.
So
that
way,
when
you
make
that
request,
it's
possible
that
you're
signing
two
things
for
two
different
blockchains
on
two
different
accounts
in
one
back
and
forth
operation.
J
So
at
least
with
these
types
of
systems,
we
can
maintain
the
status
quo
instead
of
kind
of
walking
backwards
and
making
you
do
more
to
interact
with
these
new
types
of
transactions.
So
again,
this
is
all
kind
of
fresh,
but
those
are
the
types
of
user
experience.
Things
I
think
are
needed
because
otherwise,
like
performing
these
transactions,
just
might
be
annoying
to
some
users.
We
already
know
that
even
just
signing
is
annoying
to
some
users,
so
so
yeah.
J
D
J
Keep
going
I
thought
you
were
done,
okay
and
then
the
other
audience
were
servicing.
We
have
been
for
a
while
now
and
we're
getting
to
an
even
more
with
the
SDK
proposal
is
developers
we
want
to
make
it
easier
to
build
applications
and
share
what
we've
learned
as
a
wallet
developer
as
an
app
developer
and
as
an
SDK
developer.
J
J
One
of
the
ideas
we
have
is
for
transaction
middleware,
which
is
so
that
way
an
application
can
say,
I
want
to
perform
this,
and
then
a
series
of
actions
is
taken
upon
those
transactions
to
either
mutate
them
or
to
append
to
them
or
do
something.
So
that
way
it
you
don't
have
to
figure
that
out
in
your
application,
exactly
the
most
common
use
case
and
I
think
the
reason
that
we
went
this
route
was
to
do
co-signing
and
provide
resources
for
users
for
free
or
for
a
fee.
J
Things
like
fuel
fuel
uses
this
technology,
and
we
do
this
kind
of
mutation
already
in
our
sdks.
But
the
way
it'll
be
built
is
so
that
other
developers
can
build
plugins
that
do
the
same
type
of
stuff
and
just
embed
it
in
their
application.
So
this
this
other
audience
where
we
are
serving
and
are
going
to
hopefully
be
serving
more
there's
a
lot
of
potential
design
implications
towards
how
we
build
the
sdks
or
more
things
we
could
build
for
the
sdks.
That
would
make
other
developers
lives
easier
when
they
want
to
use
IBC.
J
J
These
are
all
things
that
developers
will
be
able
to
do
immediately
upon
release
of
IBC
they're
gonna
have
to
know
how
it
works,
they're
going
to
have
to
do
it
by
hand
and
everybody's
going
to
be
doing
that
same
thing
over
and
over
again,
because
there's
no
tool
that
just
does
it
for
them.
So
I
do
think.
There's
a
real
opportunity
there
to
create
tooling.
That
could
make
IBC
that
much
easier
for
developers
to
adopt
and
then
on
the
flip
side,
for
users
to
use.
D
A
wholeheartedly
agree,
I
think
it
also
brings
up
something
that
we've
talked
about
on
a
few
Fireside
Chats.
Is
this
idea
that
what
you
just
described,
the
the
thought
process,
the
skill
set,
the
the
bringing
attention
to
or
the
thinking
of
that
user
experience
is
something
that
we
really
don't
see.
Much
skill
set
on
EOS
I
mean
there.
Is
it
not
to
take
away
from
from
those
working
on
that,
but
there
are
very
few
teams
that
are
putting
this
at
the
Forefront.
D
We
always
you
know,
of
gray
mask
that
is
doing
this
and
and
I
take
this
opportunity
kind
of
as
a
call
out
if
anything
of
what
Aaron
just
mentioned
resonates
with
you.
If
that
is
something
that
you
are
passionate
about
and
that
something
that
you
would
like
to
help
tackle,
there
definitely
is
a
need.
D
You
know
on
his
team
or
some
or
or
or
as
a
standalone
and
or
please
reach
out
to
the
enf.
We
do
have
the
grant
framework.
We
also
have
pomelo
I
mean
that
it
goes
back
to
this
idea
of.
We
need
more
people
working
on
that
ux
side
of
things
for
Eos,
because
it
doesn't
matter
if
we
have
all
of
these
really
great
features.
D
We
need
more
of
that,
and
so
please
feel
free
to
reach
out
to
Aaron.
Please
feel
free
to
reach
out
to
to
me
to
Zach
to
the
NF.
We've
got
funding
available
specific
to
ensure
that
the
usability
of
the
chain
is
is
definitely
a
focus,
and
that
again
is
something
that
was
never
put
at
the
Forefront
prior
to
you
know
somewhat
recently,
because
we've
never
had
the
capital
and
the
coordination
available
to
be
able
to
even
offer
this.
J
D
D
J
D
So
like
these
are
things
that
have
been
highlighted
in
the
blue
papers
and
so
there's
information
there.
It's
not
like
the
the
teams
are
starting
from
scratch.
Obviously
it
would
need
more
thought
process
into
it,
but
there's
already
something
there
for
people
to
get
a
sense
of
what
it
is
we
are
looking
for
and
whether
or
not
they
are
the
right
people
to
be
able
to
tackle
this.
J
D
Do
well,
this
is
where
you've
been
mentioning
multiple
times
right,
that
you've
been
juggling
between
taking
things
on
like
the
sdks,
but
then
also
continuing
the
maintenance
and
the
improvements
of
the
current
products,
which
are
key,
which
will
Leverage
The
sdks
and
are
currently
the
the
gateways
to
accessing
a
lot
of
the
these.
These
different
chains,
for
example,
Yep
they're,
building
the
roads
as
we
drive
yeah
exactly
so.
If
anybody
else
wants
to
be
a
rogue
Builder
yeah,
please
please
reach
out.
A
All
right
well,
that
was
great
thanks
for
everyone
who
participated
in
this
conversation
thanks
for
Guillaume
for
joining
us
I,
don't
know
if
you
guys
still
here
thanks
a
lot
young
that
was
great
anytime.
You
want
to
come
back
on
the
Fireside
share,
some
of
your
insights,
opinions
and
yeah.
We
we
love
to
hear
it
for
sure.
A
Yeah
yeah,
absolutely
we
we
peaked
at
almost
60
again
or
like
above
55
I
think
during
this
fascinating,
very
nerdy
conversation,
but
that
was
great.
I
I
was
able
to
follow.
Most
of
it.
I
will
say
so
good
job
on
the
speakers
for
for
keeping
it
accessible
to
the
whole
community
and
audience
foreign
all
right
cool.
So,
let's
move
on
to
some
quick
hitters
here,
I'll
give
a
little
pomelo
update.
A
We've
got
the
next
stage
of
the
pomelo
nft
promotion
going
on
this
week.
You
can
now
create
your
rocket
potions
and
claim
your
Rockets.
As
always,
you
can
go
to
harvest.pomelo.io
to
join
in
the
nft
festivities,
as
we
lead
up
to
the
launch
of
season.
Three.
So
again,
a
reminder,
that's
going
on
on
July
19th.
So
that's
when
applications
for
Grants
will
open
for
pomelo
season
three.
A
So
if
you
already
have
one
from
previous
Seasons,
then
you
can
share
that
one.
If
you're
a
new
new
to
pomelo
for
season
three,
then
we'll
ask
you
to
wait
until
you
actually
submit
your
Grant
application
in
order
to
get
on
this
Pitt
session
list,
so
some
additional
incentive
to
get
those
grants
written
prepared
and
published
as
early
as
we
can.
A
D
And
of
no,
we
definitely
look
at
this,
so
as
the
enf,
obviously
during
The
Far
Side
chats
those
who
participate
in
these
pitch
sessions.
Clearly,
in
my,
in
my
point
of
view,
get
a
lot
of
Advantage
in
in
the
in
the
funding
rounds
and
subsequent
engagement
rounds
and
so
I
invite
people
to
participate
in
this.
It's
a
huge
opportunity
that
you
guys
get
don't
drop
the
ball.
A
A
All
right,
moving
on
to
our
next
topic,
I
want
to
quickly
talk
about
the
blockchain
futurist
conference.
That's
going
to
be
going
on
in
Toronto.
This
is
basically
the
biggest
blockchain
Conference
of
the
year
in
Toronto,
and
you
know
that
area
in
Canada
we've
got
a
few
confirmed
superstars
from
EOS
that
are
going
to
be
there.
Eve
is
going
to
be
there.
Zach
is
going
to
be
there
from
the
enf
of
course,
and
we've
got
Daniel
Keys
as
well
from
EOS
nation
and
pomelo
team.
D
H
Overlaps
also
with
East
Toronto,
so
the
hackathon
Begins
the
day
before
the
conference
and
the
last
day
of
the
conference
for
the
blockchain
futurist
conference
on
the
main
stage
is
the
presentations
from
all
of
the
finalists
from
the
ethereum
hackathon,
so
pretty
excited
to
scope
out
some
new
Talent.
There
also.
D
A
All
right,
let's
see,
is
Chris
Barnes
still
with
us.
He
was
here
earlier.
We
might
have
missed
him.
I
wanted
him
to
talk
a
bit
about
the
Helios
Wave
4
incubator
that
was
just
announced
earlier
today
or
yesterday.
They've
got
10
10
other
teams
that
are
participating
in
this
incubator.
I
just
shared
the
Tweet
here
in
the
voice
chat.
A
A
A
Yeah
I
guess
we'll
keep
going
some
other
rapid
fire
news.
We
have
the
Mandel
3.1
release
candidate
2
released
today,
so
this
fixes
some
issues
with
history
Solutions,
which
is
required
for
for
Block
explorers
and
new
features
for
trust,
evm
I
know
it's
been
already
a
very
Tech
heavy
call
so
far
today,
but
if
some
of
the
tech
Superstars
want
to
share
a
little
more
context,
invite
you
to
do
so.
E
Yeah
so
I
mentioned
when
rc1
was
released,
that
we're
gonna
likely
have
a
couple
more
RCS.
So,
unsurprisingly,
we
release
rc2
today
that
addresses
some
of
those
issues.
Their
notes
around
details
on
the
release
notes
there's
some
fixes
to
ship
which
you're
referring
to
with
the
history
solution.
There's
also
some
changes
to
the
crypto
Primitives
protocol
feature.
E
A
All
right
next
up,
I'm
gonna
mention
the
Eden
election.
That's
coming
up
this
weekend
on
this
Saturday,
so
those
of
you
who
are
interested
in
participating
in
the
Eden
election
you're
invited
to
sign
up
at
least
24
hours
ahead
of
time.
So
that
means
night.
You
need
to
be
signed
up
by
9
A.M
Friday
morning
Eastern,
because
the
election
starts
Saturday
morning
at
9.
A
A.M
Eastern
I'll
share
the
site
where
you
guys
can
go
and
register,
and
also
note
that
the
number
you
will
see
on
this
site
to
register
for
the
union
election
may
not
be
accurate.
Oh,
it
may
not
be
accurate.
Earlier
today
was
showing
a
relatively
low
number
and
then
in
the
Eden
Channel.
Just
now
we
had
we
had
someone
update
the
stats
Edgar
from
yes,
Costa
Rica.
Also,
a
chief
delegate
right
now
said
that
there
were
52
members
correctly
registered
as
of
15
minutes
ago.
A
So
definitely
if
you're
interested
in
participating,
Eden
go
sign
up.
The
amount
of
rewards
that
are
being
distributed,
monthly
has
been
increased
from
five
percent
of
the
treasury
to
15
of
the
treasury,
so
yeah.
So,
there's
a
bit
more
a
bit
more
funding
available
for
people
who
get
elected
through
fractal
democracy.
K
K
Just
a
quick
update,
we're
we're
actively
working
with
faculty
team
right
now
to
fix
the
UI
bugs
that
have
happened
and
very
hopefully
soon
we'll
be
able
to
get
the
the
the
election
participation
stats
and
the
three
EOS
donation
for
new
members
sorted
out,
but
in
the
industry
in
the
interim,
please
work
on
getting
the
vote
out.
Eden
members,
it's
really
important
that
the
more
of
us
there,
the
more
Eden
members
there
in
the
election,
the
better
the
results
will
be.
A
L
K
I
A
All
right,
another
quick
hitter:
here
we
had
an
update
from
Lars
with
his
EOS
design
this
week
on
Twitter
I'm
gonna
share
this
tweet
here
from
him
and
yeah
I'm
gonna.
Just
quickly
read
it
out,
for
you
guys,
basically
just
getting
some
sneak
peek
at
the
pencil
art
that
himself
and
that
that
he
and
his
partner
are
working
on.
A
He
thanks
of
Course
tomelle,
Branson,
Yale's,
Network
Foundation
for
being
able
to
fund
this
and
yeah
so
volume
one
will
feature
comics
editorials
and
a
fractal
fiction
and
will
be
available
for
free
later
this
month.
So
that's
pretty
cool
love
to
see
some
some
results
from
the
projects.
You
know
that
apply
to
Pamela
grants,
of
course-
and
hopefully
we
see
Lars
come
back
to
season
three
and
continue
on
with
this
EOS
design.
Project
of
his
definitely
gonna
give
some
Emoji
love
to
that.
A
Okay
and
all
right,
we
got
just
a
few
topics
left
we
may
bust
a
two-hour
Mark,
but
that's
fine
bitum
increased
their
staking
rewards
this
week,
which
is
a
topic
that
we
talked
about
last
week
on
the
Fireside
Denny.
If
you're
still
with
us,
did
you
want
to
share
your
thoughts
on
on
these
increased
staking
rewards
yeah.
F
I
can
I
can
share
my
thoughts
so
yeah.
It's
very
positive
that
they're
adding
sort
of
an
increasing
their
staking
rewards.
That
is
a
great
sort
of
user
acquisition
strategy,
get
the
sort
of
the
sort
of
token
holder,
or
at
least
the
the
small
to
mid-sized
token
holders
excited
with
their
staking
rewards.
F
However,
I'm
sure
that
there's
going
to
be
some
sort
of
minimum
or
maximum
deposits,
so
their
current
apy
is
five
to
seven
percent,
so
seven
percent
on
the
maximum
five
percent
on
the
low.
But
what
we
see
is
we
do
see
people
or
exchanges
offer
high
yield,
but
for
a
limited
supply
of
of
assets.
Just
for
an
example,
binance
has
also
a
really
high
apy
locked
savings
account
and
it's
at
nine
percent,
but
only
on
40
EOS
per
account,
so
only
a
50
or
40-ish
dollars,
and
that's
also
120
day
staking.
F
So
some
of
these
programs
are
really
really
positive
to
get
those
sort
of
low
those
sort
of
early
users
on
the
platform,
but
it
is
for
a
limited
amount
of
assets.
So
it's
not.
You
know
seven
percent
on
maybe
10
million
EOS.
It
might
be
a
a
limited
Supply
and
it's
a
great
user
acquisition
strategy,
so
it's
really
positive
that
they
are
offering.
Those
rewards
I'd
be
curious
to
know
what
what
the
lot
size
is
and
how
many
pools
are
available.
F
F
F
A
I'm
gonna
share
the
article
here
with
you
guys
in
the
chat.
If
you
haven't
read
it
yet,
it's
really
nice
to
see
you
know,
executive,
director
and
founder
of
the
EOS
Network
Foundation
right
at
the
top
of
this
article.
On
such
a
prominent
platform,
there
wasn't
any
specific
EOS
examples,
but
it
does
talk
about
the
gaming
space.
You
know
game
five
space
in
general
and
how
it
will
likely
evolve
over
time.
A
A
Those
were
my
favorites,
and
you
know
the
this
article
got
me
thinking
of
the
ways
that
these
gaming
teams
are
going
to
evolve
in
the
future,
and
you
know,
I
was
I
attended,
actually
the
DOTA
International
in
2019
in
Vancouver,
which
is
a
big
DOTA
Esports
tournament,
and
you
know
it's
very
exciting
to
be
there.
Some
of
the
most
exciting
sporting
events
I've
ever
attended
and
I
was
imagining
in
the
future.
A
Where
these
events,
you
know,
will
be
attended
by
people
that
are
part
of
these
massive
decentralized
worldwide
guilds
and
I
I
I
can
just
imagine
how
how
more
exciting
and
engaging
these
events
are
going
to
be
so
yeah.
So
definitely
a
little
shout
out
to
Eve
for
this
great
work
and
for
getting
published
in
nasdaq.com.
F
And
to
add
to
that
is
the
the
gaming
industry
is
is
huge
in
in
Korea
as
well.
So
I
think,
like
you
were
saying,
League
of
Legends
is
probably
bigger
than
football
in
Korea,
so
some
of
the
the
top
talent
a
is
all
Esports
driven,
so
I
think
that
economy
can
thrive
in
and
sort
of,
Southeast
Asia
markets.
D
While
worldwide
gaming
is
one
of
the
only
Industries
during
the
pandemic,
That
Grew
instead
of
shrunk
in
terms
of
user
base
in
terms
of
money
being
poured
into
that
gaming
itself,
the
gaming
industry
is
far
greater.
It's
it's
I,
think
it's
four
or
five
times
larger
and
projected
to
be
even
greater
than
that
already
than,
for
example,
television
or
movies.
D
Yes,
so
we
are
definitely
positioning
these
articles
so
that
they
don't
necessarily
talk
about
EOS.
But
when
people
start
looking
into
this
and
they
start
looking-
oh
well,
who's
Eve
Who's,
the
enf,
then
they
start
coming
into
and
into
EOS.
So
definitely
the
the
direction
in
which
we're
going
with
this
type
of
article.
A
Shout
out
to
Brandon
for
this
clip
and
then
Daniel
posting
the
GIF
right
even
before,
without
knowing
love
it
yeah
Drew
blocks,
his
dags
are
kind
of
like
mining
pools
for
play
to
earn
as
he
interprets
it.
I
agree.
It
is
kind
of
like
mining,
pools,
absolutely
and
pretty
excited
to
see
how
it
all
develops.
A
You
know,
obviously,
on
EOS
we
have
two
huge
games
that
are
taking
advantage
of
the
functionalities
available
for
for
Games
built
on
EOS.
We
got
a
plan
and
we've
got
wombat,
which
is
not
one
specific
game,
but
obviously
a
whole
ecosystem
of
a
variety
of
games
and
Wombat.
Earlier
this
week,
tweeted
some
pretty
impressive
stats
about
adoption
on
their
platform,
so
they've
had
2.4
million
sign
ups
250
000,
active
monthly
users.
A
You
know
20
gaming
Partnerships
with
double
A
and
AAA
publishing
game
studios,
40
different,
double
a
triple
A
games
on
their
platform,
65
000,
daily,
active
users,
1.2
million
nfts
minted
for
wombat
partners,
and
they
currently
have
700
000
nfts
staked
in
their
dungeon
master
game.
So
wombat
is
really
leading
the
way
on
EOS
in
terms
of
building
a
very
wide
and
inclusive
gaming
ecosystem
and,
of
course,
a
plan
also
has
some
very
impressive
statistics
of
their
own,
which
I
don't
have
handy
right
now.
F
Yeah,
it's
some
really
impressive
stats
on
the,
especially
on
the
daily
active
users.
I
mean
if
anybody
is
is
running
back
ends.
You
know,
handling
65
000
users
per
day
is
is
quite
the
challenge
so
I
know
a
lot
of
their
effort
is
to
provide
robust
infrastructure
for
their
wallet.
Specifically.
I
know
that
team
for
gray
Mass
also
knows
how
much
you
know
how
hard
it
is
to
handle
large
loads
on
the
wallet
side.
F
A
And
I'm
not
sure
exactly
how
old
this
is,
but
at
one
point
wombat
was
creating
3
000
new
EOS
accounts
every
day,
so
I'm
not
sure
if
that's
gone
up
or
down,
but
that's
like
a
year
or
two
ago,
if
I
remember
correctly,
so
definitely
yeah
impressive
stats
all
around
and
we're
a
big
fan
of
wombat
in
general
they've
been
obviously
with
the
EOS
Community
from
the
start,
and
so
it's
been
great
to
see
them
thriving
and
growing.
Over
the
past
years
and
months.
A
A
A
Good,
okay,
guys
I,
think
I
think
we're
gonna
wrap
it
up
here.
So
thanks
a
lot
for
joining
yet
another
EOS
fireside
chat.
It's
been
a
good
one,
very
technical,
I'm
sure
we
are
all
learned.
A
lot
and
yeah
I'm
excited
to
see
all
those
faster
finality
being
shipped
on
EOS.
That's
going
to
be
a
really
exciting
time,
all
right!
Everyone
thanks
for
joining
and
go
EOS.