►
From YouTube: Coalition4
Description
DESCRIPTION TEXT
Timestamps
00:00:00
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://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
All
right
here
we
go
yeah
excellent
thanks.
So
welcome
to
today's
meeting
we
got
quorum
here.
We
got
all
chains
represented,
which
is
great.
So
from
that
perspective,
since
we
know
that
jesse
needs
to
leave
early,
I
would
propose
we
directly
move
into
the
discussion.
Slash
voting
on
the
on
the
two
rfps
that
we
that
are
prepared
so
jeff.
Maybe
you
want
to
outline
the
content
of
those
and
where
we
stand.
B
Well
sure,
let's
start
with
the
faster
finality
rfp
that
was
sent
out
over
the
telegram
channel
earlier,
and
I
did
see
a
number
of
reactions,
but
I
think
that's
all
I
need
to
say:
there's
not
been
updates
to
it.
It
was
ready
for
your
review
this
week
and
are
there
any
last
minute
comments
concerns
nobody
contacted
me
during
the
week
with
comments
concerns.
So
hopefully
everything
looks
good
in
there.
C
B
A
E
D
C
E
C
E
This
is
explaining
whose
entity
he
is
that
you
would
contract
with
and
is
giving
an
overview,
yeah,
okay
and
it
does
say
eosio
plus
coalition,
in
the
question
section
below.
So
it's
pretty
clear.
Okay,
that's
my
only
thing
just
to
make
sure
that
this
is
how
we
want
it,
which,
if
you're,
if
you're.
Okay
with
that
I
mean
that's
the
no
it's
it's
it's
fine
with
me.
E
E
A
So
from
that
perspective
it
doesn't
need
to
be
more
specified
and
more
detailed
specified
to
more
detail,
because
we
assume
that
the
team
that
has
written
all
this
and
will
develop
all
this
most
likely
does
not
need
to
kind
of
more
specify
this
information
and-
and
the
assumption
is
that
we
would
we
would
hand
this
package
to
to
grammars
anyway.
So
if
we
look
at
the
the
faster
finality,
one,
which
is
far
more
detailed
to
an
extent
kind
of
the
the
requirements,
though,
are
too
complex.
A
And
what
we
also
discussed
is
if
we
would
give
like
an
amendment
to
the
rfp,
which
is
a
part
of
the
blue
paper
that
does
not
indica
include
the
actual
cost
indications
that
have
been
done.
There
could
to
not
distract
the
the
free
calculation
of
the
partners
that
we
might
want
to
want
to
pitch
this
one
to.
B
Well,
I
just
you
know,
I
think
both
of
your
points
were
very
valid
and
I
think,
as
we
iterate
through
the
next
one
and
the
next
one
as
a
coalition,
we
will
get
better
at
figuring
out
what
the
right
level
of
detail
for
testable
requirements
are,
because
I
think
we
you're
correct.
We
have
two
extremes
here
or
close
to
extremes,
two
different
approaches,
but
I
I
think
it's
okay
for
both
of
these,
as
we've
discussed
and
others
have
discussed.
B
A
D
Yeah
ted
it's,
this
is
minor,
but
I'm
assuming
at
some
point.
We
may
get
some
some
rfp
responses
from
other
countries
and
the
address
is
kind
of
assuming
the
united
states
says:
city-state
postal
code.
We
could
add
a
box
and
there's
enough
room
on
the
page
for
country,
but
it's
almost
like
city
state,
slash
province,
postal
code
or
something
it's
where
it's
a
little
more
global
aspect
of
what
addresses
look
like,
because
nowhere
does
it
ask
for
their
country.
I
don't
know
if
that
matters
to
people.
C
D
D
Yeah
there
must
be
some
standard
somewhere
that
talks
about
international
addresses
that
everyone
that
reads
it
kind
of
gets.
Okay,
because
addresses
look
so
unusual
in
some
countries
for
at
least
for
people
in
the
us.
It's
like
even
the
address
of
the
enf
is
odd
to
me,
because
I'm
not
sure,
what's
the
street
number
and
what's
the
apartment
number,
it's
the
whole
bunch
of
numbers
on
a
line.
A
A
Okay,
awesome,
so
that
means
that
the
document
is
approved
and
can
therefore
be
forwarded
to
aaron.
Well,
he
does
have
it,
but
we
give
aaron
the
information
that
he
can
now
start.
Please
start
with
the
rejection,
creating
the
proposals
and
and
submit
those
proposals.
My
assumption
is
that
we
will
not.
We
will
not
have
many
questions
from
his
side
in
in
the
approval
process
or
in
the
process.
So
that's
the
clear
assumption.
A
E
E
So
I
was
just
going
to
suggest
that,
if
possible-
and
it
seems
like
there's
not
other-
you
know
if
we
pass
the
application
period
and
we
only
have
one
applicant
and
we're
confident
in
them
being
selected
that
we
could
shorten
that
because
july
1st
I'd
love
to
see
faster
finality
at
least
get
the
ball
rolling
before
july
1st
and
same
with
the
wallet
sdk.
So
likewise,
I
think.
B
As
a
I
think,
as
a
group
we
should
see,
the
timeline
is
the
that
is
to
maintain
equity
and
fairness.
If
multiple
groups
are
bidding,
but
it
doesn't
mean
we
need
to
check
our
brains
at
the
door
and
if
you
know,
if
it
looks
like
oh
aaron's
got
this
he's
going
to
run
with
it,
we
can
get
a
bid
faster.
We,
as
a
group,
should
understand
that
if
nobody
else
is
being
harmed
by
it,
then
we
can
choose
to
move
the
whole
timeline
as
fast
as
possible.
E
A
H
A
C
B
One
point
of
information
that
tomorrow
zach
brandon
and
I
are
meeting
and
we
are
going
to
evaluate
and
document
a
public
rfp
release
process,
including
identifying
all
of
the
places
it
is
going
to
go.
I
mean
again,
I
think
you
know
zach
and
brandon
have
a
lot
of
this
stuff
in
their
head
already,
but
or
maybe
even
written
down,
but
we'll
make
sure
we
formalize
that
and
make
sure
everybody
is
aware
of
what
we're
doing
and
then
we
can
also
get
input
from
the
other
chains
on
that
process
as
well.
A
C
F
B
I
don't
believe
we
will
lose
time
by
doing
that,
because
guillaume
you'll
be
putting
your
proposal
together
start
I
mean
you
might
have
already
even
started
that,
but
I
can't
imagine
you
having
something
solid
and
locked
up
within
five
days.
I
mean,
maybe
I'm
wrong
on
that.
So
when
the
open
intention,
the
bid
closes
a
week
later
and
we
find
you're
the
only
one
standing.
What
we've
done
is
we've
communicated
to
the
world
that
hey
we're,
giving
out
money
if
you're
interested,
maybe
not
on
this
one.
B
A
Okay,
fine,
I
just
wanted
to
raise
that
question
to
me.
That's
good
before
okay
dog
awesome,
that's
great
though
so
we
have
those
two
things
on,
so
we
we
have
the
timing
for
those.
This
is
great,
so
jeff
was
kind
enough
to
adjust
the
actual
status
report
for
for
all
the
blue
papers.
So
jeff.
Maybe
you
want
to
guide
us
through
that.
B
Sure,
okay,
so
what
we
have
in
the
first
column?
Well,
each
row
is
the
general
programs,
so,
for
example,
the
top
one
is
the
wallet.
We've
got
three
projects,
one
request
of
permission
hasn't
started,
whereas
application
registry,
the
work
group-
is
reviewing
it
now
with
and
approving
it
to
see.
If
that
can
then
come
to
this
group
the
following
week
and
then
the
sdks
you
just
saw
kirsten
move
that
from
the
review
you
guys
voted
now.
We
will
officially
put
that
in
the
bidding
process.
B
B
B
B
That's
true:
the
board
was
accurate
as
of
yesterday
afternoon,
but
good
news
is:
we've
moved
another
one
forward,
so
yes,
the
trustless
cross
chain
ibc,
as
guillaume
just
mentioned,
we've
got
a
good
framework
for
that.
The
scalability
meeting
on
tuesday
we'll
be
going
over
that
and
flushing
it
out
in
even
more
detail
so
that
we
can
plug
that
into
the
rfp.
A
A
A
C
I
like
that
idea,
I
like,
having
somebody,
be
kind
of
a
bug
bounty
in
a
way,
but
a
formalized
testing
framework
that
could,
I
guess
my
one
concern
is
that
it
doesn't
overburden
the
process,
but
I,
like
the
general
idea
of
being
able
to
each
time
that
we
have
something
new
people
are
able
to
raise
their
hand,
get
compensated
in
order
to
really
deep
dive
into
the
code
test
it
out
in
a
live
environment.
I
really
like
that.
C
I
A
We
we
haven't
really
discussed
that,
so
obviously
we
we
have
various
bps
that
are
on
various
change,
so
that
it
would
actually
make
sense
to
to
have
some
of
those.
But
I
would
leave
this
open
and
say:
well,
we
haven't
further
discussed
that,
so
we
could
say
three
bps
in
total
and
it
would
be
great
if
they
cover
more
than
one
chain
each,
but
we
haven't
discussed
that.
So
this
is
something
that
we
can.
We
can
bring
up
for
for
the
concept
when,
when
we're
working
on
that.
B
Yeah,
I'd
also
point
out
that
I
think
we're
putting
together
a
guideline,
but
each
project
we'd
have
to
like
make
sense,
because
some
projects
will
be
much
bigger
and
more
critical
in
nature.
So
we'd
probably
want
more
testing
and
encourage
that
some
are
going
to
be
really
lightweight
and
the
idea
of
like
paying
potentially
12
bps
to
go
in
and
test
like
some
small
thing.
B
C
It
would
be
the
guinea
pig
as
well.
I
guess,
because
more
liquidity
was
there,
and
so
if
there
were
people
to
try
and
attack
one
of
them,
then
it
was
kind
of
an
obvious
target.
Do
we
want
to
continue?
It
was
that
was
never
formal.
This
process
was
never
formalized.
Do
we
want
to
always
pick
the
same
test
net
where
we
would
be
deploying,
or
do
we
want
to
alternate
between
test
nets,
or
I.
F
F
I
I
think
that
worked
well
in
the
past.
I
don't
see
why
we
would.
We
would
change
that.
I
mean
it
it.
It
prolongs
the
timeline,
I
guess,
but
it
is,
it
is
making
it
a
little
bit
more
safe,
because
you
know
any
sort
of
security,
audits
or
vulnerabilities
could
be
first
found
on
the
first
main
net
deployment,
and
then
we
can
learn
from
that.
Do
any
sort
of
patches
that
need
to
be
done
and
then
follow
through.
C
I
would
say
that
from
end
to
end,
the
process
would
probably
be
faster
than
what
we've
seen.
What
I
mean
by
that
is,
after
the
code
is
out.
After
then,
the
code
is
tested
and
deployed
on
the
main
net,
the
time
in
between
historically
anyways
time
in
between
eos
main
deployment
and
other
mainnet
deployments
has
been
rather
large
depending
on
on
the
chain.
I
would
imagine
that
now
that
we're
working
all
together
and
we're
really
going
at
this
all
together,
the
end
to
end
might
be
much
shorter
than
it
has
been
historically
agreed.
C
D
F
D
A
C
A
C
D
A
D
A
B
A
B
We
are
gonna
have
to
address
this
pretty
soon.
I
don't
know
that
I'm
prepared
to
present
something
today,
though,
because
the
two
rfps
we
just
voted
on,
I
know
we
we
will
have
at
least
you
know
a
week
or
two
assuming
we
don't
already
know
who
gets
selected,
but
I
do
think
this
is
a
high
priority
on
our
list,
so
we
need.
A
Okay,
then,
we
also
discussed
because
there
are
effectively,
we
don't
have
work
groups
anymore.
So
we
had
the
discussion
that
we,
we
basically
need
a
steering
committee
by
program,
so
somebody
that
is
leading
the
program
initiatives
on
a
technical
side
and
have
like
a
committee
or
additional
resources
and
skills
to
judge
on
what
is
being
delivered.
A
So
the
question
is:
do
does
everybody
agree
that
we
need
this
kind
of
steering
committee
by
program
and
if
so,
how
would
be
leading
those
kind
of
committees
or
steering
steer
codes
from
your
perspective?
So
we
I
discussed
that
with
jeff
too,
and
we
thought
we
would
love
to
bring
this
up
for
for
discussion
here,
because
we
we
do
need
to
have
some
authority.
C
D
D
It's
sort
of
what
jeff
and
you
and
I
discussed
earlier
today,
and
the
issue
is:
who
has
got
the
time
to
be
that
or
is
it
just
something
that
we
again
that
we
eat
each
of
the
chains
takes
the
responses
back
to
their
technical
people
on
the
chain?
So
you
know
telos
takes
it
back
to
their
technical
people
to
look
at
it.
This
response.
We
take
it
back
to
our
technical
people,
etc,
wax
and
ux,
and
then
there
comes
back
a
voting
right
and
to
decide.
D
I
don't
think
we,
otherwise
we
have
to
try
to
put
together
five
steering
committees
and
have
people
sitting
on
steering
committees
waiting
to
do
this
when
in
reality
there
are
five
programs
that
are
running.
But
as
these
responses
come
in,
in
my
opinion,
they
can
just
be
brought
back
to
the
the
chain
owners
read
them
obviously,
and
the
technical,
the
staff
on
the
chains
read
them
and
that's
how
they're
going
to
do
their
voting
and
that's
how
they're
going
to
decide
it
may
be
decided.
None
of
these
responses
are
adequate.
D
You
know
enough
here
to
be
discussed,
let's
appoint
the
technical
leaders
of
these
ad
hoc
committees
and
it's
not
clear,
even
in
our
case
per
rfp,
which
of
bucky
r.
You
know
that
we
would
say
they're
going
to
represent
this
rfp
response
or
same
thing,
I'm
sure
with
telos
or
wax,
or
you
know,
and-
and
we
can
also
invite
you
know
non-bidding
members
of
the
community
as
well.
C
C
With
that,
I
think
at
some
point
as
we
get
larger,
as
there
are
more
programs,
as
there
are
more
initiatives
under
those
programs
running
my
concern
for
that,
and
I
agree
with
what
you
just
said.
I
think
it's
too
early
too
much
and
I'm
not
even
sure
we
have
the
resources
to
be
able
to
do
that,
but,
like
the
people
there's
just
not
enough
people
there's
not
enough
time.
C
I
Yeah,
I
think
kind
of
like
he
was
saying
with
regards
to
how
many
people
can
actually
be
available.
I
might
might
be
the
challenge,
so
I
think
I
think
responsibility
falls
back
to
the
chains
how
they
deal
with.
That
is
up
to
them.
I
know
on
our
end,
for
example
like
I,
I
can
spare
maybe
a
few
more
people
to
to
help
out
on
part-time
basis,
looking
at
say,
sdk
stuff
and
things
like
that,
but
I'm
not
sure,
like
delos
has
been
having
difficulties
attending.
I
A
Yeah,
okay
makes
sense,
so
then,
then
we
would
move
that
back
to
the
to
the
backlog.
So
we
have
it
in
mind
at
some
point
of
time
and
discuss
that
and
and
move
on
the
way
that
we
did.
It's
just
my
fear
is
that
currently
it's
easy
to
it's
easier
to
manage,
obviously
jeff
and
ted
you.
You
do
a
lot
of
a
lot
of
those
things,
so
it's
easier
to
manage
because
not
everything
here
is
is
currently
being
worked
on,
so
we
have
a
lot
of
things
on
the
left
side.
D
D
You
know
we'll
get
the
work
done,
we'll
put
it
through
the
workflow.
The
chain
heads
will
be
responsible
for
making
sure
they
get
a
technical
analysis
and
yeah.
I
do
think
we
should
put
it
on
the
backlog
because
we
do
hope
to
get
bigger
and
have
enough
staff
at
some
point
that
we
could
say
this
person
is,
is
sitting
on
each
of
these
steering
committees.
But
I
mean
there
are
more
steering
committees
with
the
five
programs
than
we
have
engineers
in
our
entire
organization.
Right,
yeah,.
A
Makes
sense
absolutely
okay
good,
then
one
thing
that
we
would
like
to
mention
or
question
is
the
identification
and
proposal
of
developer
teams
for
open
tenders.
So
obviously
everybody
here
has
got
like
a
huge
network
of
eos
io
programmers,
either
being
on
their
own
or
having
teams
themselves.
So
the
question
is:
if
we
would
give
something
to
open
tender,
we
wouldn't
just
post
it
on
a
website
and
say
hey.
We
got
this
if
you
feel
feel
you
would
be
interesting
to
to
kind
of
build
this
just
approach
us.
A
I
I
personally
would
envision
that
we
outreach
to
developers.
We
know,
have
the
skills
to
do
these
kind
of
things
and
I'm
wondering
if
we
can
kind
of
build
a
database
or
like
an
excel
file
with
those
teams
with
their
skill
sets.
If
we
know
them
so
we
can
kind
of
identify
them
and
proactively
approach
them
and
say
hey.
This
is
an
open
tender.
A
D
I
think
it's
a
great
idea,
I
think
honestly,
the
way
I've
been
looking
at
it,
because
I
agree
with
exactly
what
you're
saying
is
for
the
most
part.
Like
eve
knows,
the
eos
ecosystem,
the
best
that-
and
so
you
know,
he
knows
which
block
producers
can
do
work.
You
know
that's
how
the
blue
papers
got,
you
know
written
he
reached
out
to
people,
he
knew
had
those
skills
allowed
them
to
bid
on
it.
D
Things
like
that,
I'm
sure
you
know
lucas
knows
the
wax
ecosystem
and-
and
you
know,
jesse
and
you
and
and
douglas
know
the
telos,
and
so
once
we
get
to
each
one
of
these
stages.
I
think
it's
you
know
we
can
either
just
do
it
ad
hoc,
then
versus
trying
to
have
a
meeting
where
everybody
throws
every
name
you
can
think
of
in
a
database
and
then
starting
to
tag
them
with
all
the
tags
that
might
be
future
relevant.
D
It
might
just
be
easier
honestly.
I
know
this
probably
sounds
like
my
last
answer,
but
it
might
be
easier
to
just
do
it
ad
hoc
as
it
comes
up
and
say
all
right
eve
who
do
you
know
that
would
be
a
reasonable
team
to
bid
on
p2p
networking
rewrite
and
he'll.
He
can
go
back
and
say
well
he's
been
working
in
the
u.s
ecosystem
since
2017.
D
D
If
we
lean
on
it
too
heavily
and
it's
not
constantly
updated
and
the
tags
adjusted
we'll
we'll
end
up
missing
an
obvious
candidate.
Had
we
just
thought
to
you
know
at
least
I
don't
know,
maybe
it's
not
as
easy
to
work
with
everyone
as
it
is
to
work
with
eve,
but
he
never
complains.
When
I
bug
him
too
much.
C
B
C
I
know
I
agree
with
that.
I
think
so.
I
agree
with
what
you
mentioned
kirsten
at
the
onset,
which
is
likely
when
we've
got
something
going
up.
I,
I
think
all
of
us
kind
of
as
a
duty,
even
because
we
don't
have
the
time
to
waste,
should
go
out
to
our
respective
networks
and
say
by
the
way,
there's
going
to
be
an
rfp
out.
C
I
would
hope
that
at
some
point
we're
gonna
we're
going
to
be
in
a
position
where
we
can't
do
that
anymore
and
a
lot
of
externals
that
we
don't
know
start
applying.
That
would
be,
I
think,
a
win
that'd
be
great
at
this
time
in
the
process.
Again,
I
think
like
getting
a
database
built
at
this
time.
I
think,
is
a
little
too
early.
I
think
let's
build
the
database
as
we
do
these
and,
as
we
start
encouraging
people
they
want
to
say
by
the
way
we
sent
it
out.
C
D
I
have
a
question:
it's
not
clear
to
me
for
the
public
tender
how
we
would
communicate
other
I
mean
I
guess
we
have
the
enf
website
now,
but
how
will
we
communicate
like
hey?
We
have
these
rfps
open
for
bid.
I
mean
there
is
a
a
way
we
could
do
it
with
the
grant
framework.
I'm
not
asking
I'm
not
saying
that's
the
best
way,
but
the
question
is:
how
do
we
put
these
out
there
and
say
hey
these
are
now
open
for
bid.
D
Would
we
would
we
put
them
somewhere
and
then
point
at
them
from
the
enf
website?
How
do
we
like
broadcast
to
the
world
if
you
think
you've
got
great
blockchain
programmers
and
you
want
to
take
something
on
here?
You
know,
and
I'm
wondering
is
that
even
reasonable,
because
truthfully,
if
you
really
haven't
been
involved
in
the
eosio
ecosystem,
it's
unlikely,
we
would
ever
pick
you
to
try
to
take
your
first
shot
at
building
something
with
zero
experience
right.
So
I'm
wondering:
does
the
marketing
thing
even
help?
Is
that
the
way
it
would
work
or
really?
D
Is
it
an
outreach
program
where
we're
all
taking
from
the
chain
heads
are
all
reaching
through
their
networks
and
their
extended
networks
to
people
that
they
know
that
have
skills
in
the
eos
ecosystem
and
eosio
ecosystem
and
apologize
and
and
that's
how
it's
brought
in?
And
I
I
just
don't.
I
don't
know
what
the
current
plan
was
for
that.
B
So
that's
the
meeting
that
I
was
referring
to
tomorrow
that
actually
you
summarize
what
I'm
hoping
we
can
work
through
with
zach
and
brandon
to
at
least
start
getting
some
of
these
locations
to
target
processes
that
are
going
to
be
as
lightweight
as
we
can
right
now,
but
still
enough
to
make
sure
that
they
have
thought
through
it.
Then
we
also
need
the
same
thing
from
the
other
chains
as
well.
Well,.
C
C
I
was
also
planning
on
once
the
pomelo
bounty
section
is
built,
then
to
put
them
on
the
pomelo
bounty
section.
I
also
thought
that,
as
a
coalition,
we
may
leverage
the
the
adam
the
dlt
detroit
ledger
technologies,
rfp
platform
that
eventually
and
having
that
out
there,
but
I
think
at
the
early
onset
we'd
just
be
leveraging
as
many
of
our
own
systems
as
we
have
like.
C
I
would
imagine
that
luke
lucas,
through
wax
will
leverage,
maybe
their
wps
system,
that
they
have
like
just
let's
put
it
out
there
as
much
as
possible,
there'd,
be
a
duplicate
and
then
maybe
over
time.
We
have
something
a
little
bit
more
formal,
that
is
the
coalition
itself,
but
again
too
early
to
create
something.
D
D
I
mean,
I
think,
the
job
that
zach
and
brandon
have
done
is
outstanding,
but
would
we
would
we
just
put
the
rfps
directly
on
the
website
like
here's,
this
rfp
we're
looking
for
or
we
would
be
making
an
article.
You
know
saying:
hey
we've
got
a
series
of
rfps
look
here
like
how,
because
I
mean
it
would
be
we're
going
to
put
pump.
C
Well,
currently,
brandon
does
every
two
weeks
a
a
communication
from
the
coalition
right,
so
we've
leverage
that
we'd
also
I
mean
I
can
only
speak
from
eos's
point
of
view,
we'd
likely.
Also,
then,
just
do
our
own
thing
that
we
do
with
the
enf
tweets.
We'd,
probably
publish
it
on
our
website
point
to
that
as
well.
Talk
about
it
in
the
fireside
into
basically
using
the
same
methods
of
communication
that
we're
currently
leveraging.
Just
now,
we've
got
another
item
to
talk
about.
I.
H
I
think
a
easy
way
to
do
it
initially
would
be
we're
doing
these
blog
posts
every
two
weeks.
So,
just
like
we
copy
and
paste
the
same
footer
into
every
post,
all
of
the
active
rfps
we
would
just
put
them
into
all
of
the
updates
and
then
once
the
rfps
got
pulled
off
the
board,
we
just
have
to
go
back
and
edit
the
posts
and
remove
them.
H
That's
not
a
great
long,
long-term
solution,
but
short
term.
It
should
be
fine
and
then
having
a
dedicated
post,
also
for
just
all
of
the
rfps,
a
page
that
just
lists
them
all,
but
as
constant
reminders,
I
don't
know
how
long
the
open
season
will
be
that
we'll
be
taking
applications
once
an
rfp
is
published.
Do
we
have
an
idea
of
how
long
we'll
be
accepting
them
before
we
close
the
round?
B
We
give
everybody
a
week
to
respond
to
us
to
say
we're
interested
in
doing
this
and
then,
if
they
say
yes,
then
they
have
time
to
answer
questions
and
actually
write
the
rfp.
So
but
it's
that
one
week
window
right
now.
That
is
the
most
concerning,
because
if
they
don't
find
out
about
it
until
that
till
after
the
windows
closes,
then.
H
All
right,
so
I
think
what
we
need
is
for
every
rfp
have
some
kind
of
call
to
action
of
how
to
submit
the
intent
and
then
every
chain
just
needs
to
kind
of
leverage,
their
socials
and
their
telegrams
and
their
discords
to
kind
of
get
the
word
out
and
then
point
back
to
the
call
to
action
wherever
that
may
be.
But
I
don't
initially,
it
would
just
be
a
a
post
until
we
can
get
a
page
designed
for
it
like
a
landing
page
with
all
the
rfps.
But
it's
easy
to
throw
the
rfps.
H
D
Continuously
I
mean
I'm
not
saying
use
the
grant
framework
repo
we
could,
but
that's
enf
based.
We
had
a
repo
we
had
been
using
for
a
while
called
eosio
plus,
and
that
would
just
be
a
spot
that
you
could
stick
all
the
rfps
under
there
I'd
put
a
directory
called
rfp.
We
stick
all
the
rfps
there
when
the
rfps
are
done
like
once
someone
is
once
the
deadline
for
bidding
is
passed.
We
pull
the
rfp
down,
so
we
say:
look
in
the
rfp
directories
for
any.
I
like
that.
D
C
D
Yep
and
and
posts
can
again,
you
know
the
every
the
bi-weekly
posts
or
whatever
the
weekly
post
can
know,
hey,
there's
a
new
rfp
out
there,
etc.
It's
just
one
directory
that
they
always
live
at
and
as
soon
as
the
deadline
passes,
we
pull
it
down
out
of
github.
So
then
they
know
like
nope
this
one's
not
available
anymore.
You
know
they
still
have
the
record.
C
B
Actually,
a
suggestion
to
tweak
that,
for
so
some
marketing
stuff
is
instead
of
pulling
it
down.
We
rename
the
file
with
like
closed
and
then
on
the
title
screen
we
put
like
closed
by,
leaving
it
up
eventually
it'll
start
creating
the
impression
that
we
are
giving
away
a
lot
of
money.
You
guys
need
to
be
coming
back
here,
often
because
you're
missing
this
stuff.
D
A
A
I
just
seen
it
he
dropped
yeah.
Okay,
so
that's
that's
fine!
So
so
we
we
move
on
with
that
and
then
find
an
information
kind
of
schedule
with
with
us,
our
social
teams,
to
to
communicate
that
and,
as
we
talked
about
budgets,
I
I'd
add
a
point.
Do
we
have
like
who
would
actually
do
like
budget
reporting
at
the
moment.
C
Yet
I
guess
by
default
that
would
likely
be
us
at
this
stage.
I
mean
unless
anybody
else
wants
to
donate
anybody.
We
seem
like.
We
are
the
largest
staffed
entity
of
the
four
I
mean
I
would
love.
If
somebody
else
could
raise
their
hands,
we
are
trying
to
hire
more
people
more
faster,
but
the
work
is
piling
up
faster
than
the
people
are
showing
up.
C
C
But
yes,
if
you
guys
want
to
hire
somebody
to
help
jeff,
please
feel
free
or
hire
more.
I
did
jeff
is
getting
help.
There
are
two
somebody's
starting
next
monday
and
somebody's
starting
the
monday
after
so
ted
and
jeff
will
be
getting
some
help.
But
yes,
if
you
know
of
anybody
else,
please
send
them
to
ted
and
jeff,
and
we
can
do
some
interviews.
C
I
guess
a
payment
coming.
We
will
have
the
final
payment
or
the
second
payment
of
the
branding
agency.
That
should
be
coming
up
shortly,
so
it
will
be
relevant
sometime
soon,
but
I
wouldn't
say
that
we
need
to
like.
I
wouldn't
formalize
a
report
every
two
weeks
at
this
point,
because
there's
no
expenditures
again
too
early
too
soon.
I
think
yes.
C
A
Guess
so,
yeah
okey-doke,
then
what
I
extracted
from
the
telegram
chat
was
was
shintai
participation?
Well,
shout
out
to
them.
They
saved
my
back
a
lot
of
times
with
their
resources
in
in
eos
times.
So
when
I
was
still
very
active
on
eos,
they
saved
my
ass
a
lot
of
times
so
with
their
resources.
So,
but
what?
What
is
the
position
on
on
this?
I
mean
we
have
discussed
this
various
times
for
other
chains.
C
Well,
I
think
this
what
we
currently
still
have
quorum,
if
you
are
the
proxy
for
jesse.
Yes,
we,
if
I'm
not
mistaken
and
guillen,
can
confirm
we've
invited
them
to
next
week's
scalability
call
I
I
guess
they
were
not
able
to
make
this
week's
call,
and
then
we
would
reassess
next
week
in
terms
of
membership,
full-on
membership.
My
understanding-
and
I
guess
my
position
as
well-
is
that
at
this
stage
I
don't
believe
that
the
coalition
should
be
looking
at
or
accepting
new
formal
voting
members.
C
We
should,
you
know,
keep
our
groove
going
at
this
stage,
because
we
still
really
don't
have
a
agree.
We've
got
some
somewhat
of
a
groove
but
bringing
the
discussion
of
having
a
new
member.
How
much
would
that
you
know
what
would
be
essentially,
what
would
be
the
fee
to
join?
What
would
be
the
governance
and
the
voting?
C
C
We've
got
30
or
so
something
people
on
this
invite,
and
there
were
only
eight
people,
and
it
really
is,
you
know
the
coalition
members,
so
people
are
free
to
join
this
call
people.
If
we
record
this,
we
can
publish
this.
I
it's
apparent
by
now
that
either
people
don't
have
the
capacity
or
they
would
prefer
waiting
until
we
can
showcase
what
the
coalition
is
capable
of
doing
over
the
next
period
of
time,
and
then
they
may
come
back
at
that
stage.
C
A
I
Yeah,
so
just
to
confirm
I
did
invite
them
for
next
week's
scalability
call.
I
also
had
invited
them
to
this
week's,
but
maybe
on
a
short
notice
like
less
than
a
day
notice,
so
they
not
attend.
I
think
I
think
either
way.
I
I
believe
once
I
mean
when
you
ask
them
what
was
the
purpose
of
the
desire
to
attend,
they
said
like
just
to
keep.
I
I
We
don't
necessarily
need
to
attend,
so
I
would
make
sure
that
they
are
aware
that
these
videos
are
being
published
and
that
they
they
are
very
welcome
to
to
view
them
if
they
have,
if,
if
that's
all,
they
they
require,
and
if,
if
so
I
mean
like,
I
said
as
a
special
one
time
off,
I'm
I'm
okay
having
them
listening
these
calls.
But
I
don't
think
I
don't
think
it's
it's.
C
So
shintai
did
join
the
eos
fireside
chat
yesterday
and
which
is
the
the
weekly
wednesday
fireside
chat.
Qintai
is
running
their
own
private.
Yes,
I
o
iteration,
and
they
did
make
changes
to
the
code
in
order
to
be
compliant
for
their
particular
use
cases.
And
so
what
is
difficult,
though,
is
very
similarly
to
other
discussions.
C
We've
had
in
the
past
that,
because
the
code
is
closed
source
and
we
don't
have
access
to
it
even
being
able
to
be
cognizant
of
whether
or
not
anything
we're
talking
about
or
thinking
of
doing
will
affect.
Them
is
very
it's
impossible
because
we
don't
know
so
unless
they
don't
join
or
unless
they
don't
chime
up,
really,
there's
not
much
that
we
can
do
on
our
end.
A
And
move
it
over
to
done
so
we
discussed
that
they're
welcome
to
the
teams
and
hoping
for
them
to
to
join
into
the
discussions.
That's
that's
great.
Okay.
I
would
leave
this
out
for
the
discussion
for
early
next
week
when,
when
we
haven't
started
the
recording,
we
did
kind
of
come
up
with
an
hourly
rate
that
we
would
like
to
discuss
internally
before
we
kind
of
publicize
this
so
this.
But
since
I
I
wouldn't
vote
for
my
own
rate,
we
we
still
wait
for
jesse.
A
Obviously
jesse
is
is
in
alignment
with
that,
but
it
feels
strange.
So
we
do
that
next
time.
So
then,
going
there
quality
assurance.
We
had
that
testing.
We
discussed
that.
I
think
for
the
program
project
reporting.
We
had
this
already,
so
so
maybe
next
time
jeff,
if
you
want
to
next
time,
show
the
the
excel
the
excel
reports.
I
think
that
that
would
be
good
compensation.
We
discussed
that
everybody
agreed
that
we
should.
That
should
do.
That.
A
B
A
B
B
D
Sense
and
there's
there's
now
two
versions
of
github
projects,
there's
a
bait
out,
which
is
got
a
lot
of
bells
and
whistles
the
old
one
is
a
fine
kanban
board
and
works
very
well
and
links
up
to
issues
very
nicely,
and
the
nice
thing
is
it's
just
at
a
url
mira
is
kind
of
hard
to
find
stuff.
You
have
to
know
the
specific
url
where
you
can
navigate
in
github.
You
just
know
it's
under
eos
network
foundation
under
eosio
plus
and
boom.
There's
the
project,
and
it
just
makes
it
easy.
A
D
A
C
Yep,
so
we
were
thinking
that
we
may
be
able
to
present
today.
So
the
group
yesterday
met
we
actually
got
names,
so
we've
got
a
short
list
of,
I
believe
six
names
and
the
group,
so
that
was
in
attendance,
but
everybody
was
there
so
justin
aaron
douglas,
and
I
have
shorten
it
to
three.
So
we
actually
have
three
names.
C
And
then
the
idea
would
be
that
when
we
present
that
we
would
go
in
camera
so
that
everybody
on
the
call
would
be
able
to,
and-
and
I
suggest
that
we
start
with
that-
because
we
know
that
lucas
usually
has
to
drop
off
and
then
we
would
talk
about
what
the
process
is
afterwards.
How
do
we
vote?
How
do
we
bring
it
back
to
the
communities
where
we,
where,
where
do
we
go
with
this,
but
we
are
essentially,
we
do
have
the
three
names
and
we're
really
excited
to
share
them
with
everybody.
C
C
C
It
won't
be
made
public
right
away
because
we
need
to
secure
the
domains
we
need
to
talk
about
which
domains
we'd
want.
We,
we
they've
done
an
initial,
so
what
we
did
get
yesterday
was,
let's
say
the
name.
We
got
a
very
basic
scrape
of
which
domains
would
be
accessible
and
for
those
that
have
costs
or
kind
of
an
idea
of
the
costs,
but
we've
got
multiple
iterations
of
them.
C
We
also
got
a
basic
madrid
protocol,
a
trademark
which
classes
and
how
many
trademarks
there
are
and
whether
or
not
they'll
be
open
and
such
so.
What
we
are
presenting
should
be
good
and
and
fill
all
the
checkboxes,
but
still
we
wouldn't
be
paying
for
the
trademarks
that
we
wouldn't
be
paying
for
the
domains
yet,
and
so,
if
it
does
become
public,
somebody
will
go
and
just
you
know
get
all
of
them.
So
we
weren't
we,
we
can't
make
those
public
at
this
stage.
C
On
and
this,
I
guess
is
what
we
need
to
talk
about.
We
talk
about
it.
Now
is
what
will
be
the
process
afterwards,
so
you
know
each
chain
or
each
each
of
the
four
coalition
members.
How
will
they
go
about
seeking
feedback
from
their
community
as
to
which?
How
will
they
come
about
voting?
And
that
would
be,
I
guess,
an
individual
decision
by
by
a
coalition
member
as
to
how
they
want
to
do
that
is
two
weeks
enough.
I
have
no
idea
up
for
grabs.
C
I
guess
it's
a
tricky
one,
because
if
you
go
about
for
feedback,
then
obviously,
then
the
information
is
made
public.
So
you
need
to
secure
the
domains
beforehand
and
some
of
the
domains
might
be
cheap,
but
other
domains
are
quite
expensive
and
the
group
as
a
whole
and
that's
why
I
think
next
people
see
whether
or
not
the
group
as
a
whole
gravitates
to
one
of
the
options
and
if
they
all
gravitate
to
one
of
the
options-
and
that
happens
to
be
an
expensive
domain-
that's
attached
to
it.
C
It's
it
it's
tricky,
I
I
don't
have
an
answer
for
that
one
or
do
we
you
know.
Do
we
make
the
decision
as
the
coalition,
because
that's
what
we
were
assigned
to
do
and
then
we
or
do
we,
you
know,
do
we
dwindle
it
down
to
two?
I
think
it
was
zach
shared,
I
think.
Was
it
polygon
zach
that
did
something
or
was
it
polygon
or
solano?
That
was
polygon.
C
C
I
would
imagine,
secure
the
trademark,
secure
the
domains
for
those
and
then
absorb
the
cost
of
which
one
wasn't
chosen.
Essentially,
maybe
that's
something
we
want
to
do,
but
that
also
adds
quite
a
lengthy
period
of
time.
If
we,
you
know,
do
this
formally
for
a
month
or
so,
and
how
do
we
calculate
all
the
tokens
from
different
chains?
What
does
that
represent?
I
guess
each
one
of
you
would
do
your
own,
but
I
don't
have
an
answer
for
that.
I
I
think
I
mean
lucas
was
like
volunteered
to
lead
that
effort.
I'm
not
sure
if
he's
done,
what
he's
done
so
far,
there
is.
There
is
again
like
there's
this
paper
that
we
started
writing
at
the
beginning.
But
now,
since
eric
was
requesting
these
mathematical
proofs
for
faster
fidelity
to
be
part
of
the
of
the
solution,
I
I
don't
know
if
it
doesn't
really
make
sense
to
to
publish
it
for
outside
the
context
of
a
bid.
So
I
kind
of
put
that
on
hold.
C
Yeah,
I
would
suggest-
maybe
we
because
lucas
isn't
here
right
now,
maybe
we
could
start
with
that
as
well
next
week,
so
we
do
branding
and
this
item.
I
believe,
last
week,
lucas
asked
that
this
item
be
brought
earlier
in
the
discussion
that
way
he
could
give
it
an
update
yeah.
From
his
point
of
view,
I
don't
think
there's
much.
We
can
do
today
on
this
item.
A
G
A
J
I
don't
know
if
this
is
the
what
that
item
is
referring
to,
but
yeah.
This
will
be
the
last
meeting
before
we
produce
the
next
update
for
the
bi-weekly
update.
So
apart
from
the
notes
they
already
have
and
the
group
and
then
we'll
discuss
tomorrow,
jeff
may
develop
some
like
technical
things
to
announce
as
part
of
the
report,
but
if
anyone
has
anything
that
they
say
for
sure
should
be
included
in
the
weekly
or
the
bi-week
weekly
update
now
would
be
a
good
time
to
just
blurt
it
out.
A
So
so,
if
we
could
have
like
a
paragraph
for
that
that
that
would,
I
think,
be
nice
to
kind
of
pre-warn
people
that
we
are
actually
going
to
send
out
rfps
now
in
a
frequent
and
on
a
frequent
basis
and
ex
and
wait
for
developers
to
kind
of
apply
to
to
raise
those
to
us.
I
think
that
would
be
great
to
to
start
this
kind
of
communication.
A
C
Yeah
in
the
rfp
there's
an
email
that
you
apply
to,
that
is
a
that
is
a
foundation
email
but
yeah,
there's
a
there's,
a
method,
and
especially
if
we
also
go
the
route
of
placing
the
rfps
in
github
as
well
as
a
as
in
the
repo,
then
they
could.
Alternatively,
I
guess:
we'd
have
the
record
there,
but
by
email
is,
is
her
process?
C
H
C
H
I
just
did
like
a
global
search
of
the
link
from
the
last
coalition
report,
and
it
doesn't
look
like
it
got
shared
in
talos
or
ux.
Wax
is
only
on
discord,
so
I
don't
really
expect
it
there,
but
I'm
just
wondering
what
the
distribution
is
for
the
other
chains
to
make
sure
the
eos
io
coalition
reports
like
we're.
Putting
a
lot
of
time
into
writing
these,
but
they're
not
being
shared.