►
From YouTube: The Graph’s Community Talk #3
Description
The Graph’s Community Talk #3
This video was recorded: Tuesday, September 21 @ 8am PST, 2021.
Sections:
0:00 Intro
1:00 Community Updates
4:08 Update on Governance
5:00 Messari Mainnet
6:07 GRTIQ Podcast
9:09 Wave RFP ideas
12:25 Bubble T
24:55 Streamingfast Announcement
30:00 Questions
35:50 Graph Governance Process
45:30 Q/A
48:00 Outro
The Graph's Media:
Twitter: https://twitter.com/graphprotocol?s=20
Instagram: https://instagram.com/graphprotocol
LinkedIn: https://www.linkedin.com/company/theg...
Website: https://thegraph.com
A
B
Yeah,
so
so,
prior
to
the
graph
I
worked
at
a
fintech
company
called
m1
finance.
I
was
actually
the
first
hire
on
the
business
team
there.
So
my
title,
there
was
just
everything,
strategy
and
finance.
I
did
all
the
company
accounting
in
the
beginning.
You
know
help
with
fundraising
help
with
all
like
financial
modeling
anytime.
We
had
a
new
initiative
and
yeah.
B
So
I
you
know
I
I've
been
into
crypto
since,
like
late
2016
early
2017,
you
know
once
you
go
down
the
rabbit
hole,
it's
it's
hard
to
think
about
anything
else,
but
I
had
such
a
good
job
and
I
you
know,
was
tied
down
with
equity
that
for
me
to
leave,
I
would
have
had
to
have
an
insane
opportunity
and
you
know
that's
pretty
much
what
happened
with
the
graph?
What
excited
you
to
come
to
the
graph
yeah,
so
I
mean
there's
like
two
big
things:
one
is
it's
one
of
the
few.
B
A
B
Yeah,
so
I
think,
like
one
of
the
big
missions
for
the
graph
as
a
whole
is
just
like
making
data
more
accessible
and
more
available
to
people.
I
think
that's
important
at
a
global
level,
but
also
at
a
at
a
local
organization
level.
So
I
want
my
goal
to
be
at
the
graph
to
make
our
financial
data
anything
that
the
foundation's
financials
as
accessible
and
digestible
to
all
the
stakeholders
involved,
including
the
community,
including
any
decision
makers,
so
that
it
could
lead
to
better
decision
making.
A
Awesome
well,
thank
you
very
much
and
welcome
to
the
graph
george
I'm
going
to
be
excited
to
work
together
with
you
and
everyone.
Just
to
give
you
all
a
quick
reminder.
As
always,
we
have
slido
open.
If
you
have
any
questions
at
any
point
in
time
that
you
want
to
ask
you
can
post
them
in
slido,
including
any
questions
for
george,
and
we
can
get
back
to
that
later
on.
So
welcome
again,
george.
A
Thank
you.
Thank
you.
Okay,
let's
move
on
with
an
update
on
governance.
Many
of
you
know
about
a
feature
that
has
been
in
development,
which
is
deploy
and
signal.
I
want
to
just
take
the
opportunity
to
provide
a
quick
update
on
that.
It
is
in
fact,
in
the
final
stages
of
being
deployed.
It
has
been
reviewed
and
approved
by
the
council
in
snapshot,
vote
and
and
now
we
are
in
the
process
of
executing
it.
We
don't
have
a
specific
timeline
other
than
saying
it's
going
to
be
soon.
A
It's
really
at
the
last
state
at
this
point,
so
pretty
excited
to
hopefully
announce
soon
that
this
is
going
to
be
implemented
as
the
next
one
on
the
list.
We
have
missouri,
and
many
of
you
have
me
may
have
seen
a
lot
of
twitter
posts
about
missouri,
mainnet
and
martin
is
going
to
tell
us
a
little
bit
more
about
what
that's
all
about.
C
So
if
you're
around
the
event,
please
show
up
at
the
booth
and
there's
luck
to
get
I've
heard
their
socks
photograph
or
something
and
there's
also
talks
given
by
eva
and
tegan
and
from
engine
note
and
there's
also
joseph
from
figment
and
so
a
couple
of
people
from
the
community
going
around
and
and
yep.
That's
that's.
It.
A
A
Let's
talk
a
little
bit
about
the
latest
vrt
iq
podcast
that
we've
had
it's
been
unique
in
the
sense
that
it's
been
by
somebody
who's
been
with
the
graph
in
the
early
stages,
but
it's
not
necessarily
on
the
tech
side
of
the
business.
So
me
as
a
non-technical
person,
I
found
it
extremely
exciting
and
drt
iq.
Why
don't
you
tell
us
a
little
bit
about
the
experience
talking
to
carl
hargerling.
D
Well,
thank
you,
oliver
and
hello.
Everybody.
I'm
really
grateful
to
be
here,
and
I
appreciate
everybody
that
listens
to
the
grt
iq
podcast.
So
thank
you
for
all
your
support
in
planning.
For
today's
call,
we
just
discussed
talking
a
little
bit
about
episode,
28,
which
featured
carl
haggerling,
and
for
those
of
you
that
didn't
listen
to
that
episode.
It's
a
really
great
entry
into
the
graph
and
it's
non-technical
carl,
is
a
graphic.
D
I'm
sorry
he's
an
industrial
designer
by
career
he's
worked
at
some
incredible
companies
right
so
went
out
to
san
francisco.
He's
from
sweden
moved
to
san
francisco,
because
his
wife
had
a
job
out
there
and
while
he
was
there
really
got
involved
in
the
tech
scene
and
worked
at
facebook
had
an
opportunity
to
go
to
tesla
a
lot
of
really
cool
companies
and
opportunities.
D
So
he's
got
this
really
great
pedigree
professional
pedigree
and
he
talks
about
meeting
the
founders
early
on
of
the
graph
and
then
going
on
to
co-found
and
become
design
lead
at
edge
and
node.
So
that's
episode,
28
with
carl
hegerling
and
really
my
favorite
part
of
that
episode.
I
don't
know
about
you.
D
This
is
another
great
episode
and
then
just
by
way
of
information
episode,
29
came
out
just
shortly
after
that
one,
and
that
was
an
interview
with
curation
station,
which
is
a
stakeholder
group
here.
Building
a
community
around
curation
derek
with
data
nexus
has
been
featured
here
in
community
talk
before
and
he
was
joined
by
graph
god,
and
so
that
was
a
pretty
good
exploration
of
curation.
There.
I'd
love
to
give
a
teaser
for
this
friday.
D
A
E
C
A
F
Yeah,
hey
everyone,
nice
to
see
you
or
hear
from
you
today,
so
I
think
what
makes
the
graph
foundation
very
unique
from
a
lot
of
you
know
traditional
web
2
spaces-
or
even
maybe
you
know,
we're
seeing
this
a
lot
and
emerge
within
the
web.
3
space
is
that
we
don't
want
to
build
the
graph
on
our
own
and
we
want
to
provide
the
opportunity
for
all
of
you
to
get
involved.
F
We've
gotten
a
lot
of
ideas
from
from
a
grant
perspective
and
to
give
you
an
idea
of
how
that
works
is
once
a
team
or
an
individual
has
an
idea
that
they
want
to
post
to
the
foundation
that
maybe
we
haven't
thought
of
before
they
submit
a
grant
application.
Now
what
rfps
are
and
for
those
that
aren't
familiar
with
what
that
stands
for
is
request
for
proposal.
F
Think
of
it
like
a
little
job
posting
that
we
put
up
there,
that
actually
comes
with
the
details
and
requirements
and
the
outcome
of
what
your
responsibility
is
for
that
posting
we're
actually
looking
for
ideas
from
the
community
that
maybe
we
haven't
thought
of
to
put
up
as
proposals,
and
this
could
literally
be
maybe
shots
in
the
dark.
Now,
I'm
not
the
most
technical
person
ever,
but
I've
come
up
with
ideas
before
that.
F
So
yeah.
If
you
have
any
ideas,
I
mean
feel
free
to
post
in
the
forum,
if
you're
a
little
too
shy.
Hopefully
you
can
find
me
on
discord
and
you
can
also
ping
me
directly
and
then
we
can
have
a
further
discussion
about
it,
but
we
have
a
very
creative
community
and
and
would
love
to
hear
from
all
of
you.
A
Awesome,
so
this
is
another
example
of
progressive
decentralization
right
in
that
we
want
to
open
up
more
to
the
community,
as
it
relates
to
rfp
and
grant
ideas
that
we
want
to
rally
around
and
that's
really
what
the
spirit
of
this
post
is,
as
rim
has
just
described
you
you
do
see
me
having
posted
an
idea
this
morning,
which
I
had
come
up
with.
You
know,
on
the
heels
of
all
the
discussions
we've
had
around
decentralization
lately,
and
that
is
an
idea
for
a
graph
decentralization
dashboard.
A
Look
at
my
post
here,
not
as
a
foundation
member,
but
rather
as
a
community
member
right.
So
what
I
post
here
is
the
same
thing
that
everyone
else
is
invited
to
post
as
well.
You
can
comment
on
my
idea.
You
can
post
your
own
ideas
and
that's
really
what
it's
all
about.
We
want
to
get
more
community
involvement
around
these
things
that
typically
have
been
more
closely
managed.
You
know
by
the
foundation
in
the
past
awesome.
Thank
you.
Erin.
A
Okay,
that
concludes
our
community
updates
and
we
get
into
our
feature
segments.
Now
we
will
start
with
bubble
tea
and
bubble.
Tea
is
a
grantee
who
has
was
in
the
process
of
building
python
library
to
enable
developers
and
data
scientists
to
quickly
build
any
data
applications
on
top
of
the
graph
network.
G
Hi
everyone-
this
is
quan,
I'm
here
with
my
co-founder
cj
we're
based
in
new
york
city,
a
small
correction.
We
the
bubble.
Tea
is
a
developed
library.
It's
not
it's
not
designed
for
iphone.
It's
like
a
python
based
library.
Typically
right
now,
I
think
it's
very
much
focused
on
web.
Now
the
project
has,
although
it's
called
bubble
tea.
It
has
nothing
to
do
with
the
popular
drinking
asia,
but
it
has
everything
to
do
with
the
graph.
So
today
we're
gonna
like
sort
of
three
things.
G
First,
I
want
to
give
a
quick
high
level
overview
of
what
this
library
does.
I
know
not
everyone
on
a
call
is
as
developers,
so
we
will
try
to
stay
on
high
level
without
getting
to
take
any
details.
Second,
we're
going
to
show
you
some
demos
that
you
can
build
with
the
library.
Third,
I
want
to
share
with
you
sort
of
this
process
that
we
we
explore
and
how
we
would
like
to
prove
suggest
some
improvement
in
the
subgraph
system.
A
G
Cool
great,
thank
you,
so
so,
if
you're,
so
this
is
a
library
we
built
for
developers
who
are
building
try
to
visualize
data
under
the
graph
or
you
are
data.
Scientists
want
to
understand
using
machine
learning
models
to
analyze
data
through
the
graph
network
just
develop
this
develop
libraries
for
you,
so
in
this
library
we're
solving
sort
of
three
major
problems.
G
G
G
G
The
second
part
of
the
library
is
aggregation
now,
when
you
load
the
data
from
sub
graph,
if
you
want
to
build
a
daily
chart
weekly
to
an
hourly
chart,
we
have
this
function,
help
you
to
aggregate
data.
It
also
provides
a
more
generic
aggregation
function,
called
group
by
which
is
a
very
common
thing.
You
use
in
a
sql
query
like
database
will
help
you
to
group
data
by
a
specific
column.
G
I
think
this
features
were
gradually
offered
in
the
note
down
the
road,
but
at
this
moment
they
don't
exist.
So
we
want
these
tools
to
make
your
life
better.
The
third
piece
is
the
visualization
function.
Right
now
we
have
line,
chart
bar
chart
area,
chart
combo,
chart
and
and
we're
adding
more
as
we
speak,
and
this
is
built
on
top
of
this
graphic
library
called
altair.
G
Now
the
last
piece
is
called
a
this
templating
system
which
helps
you
to
build
a
dashboard
with
a
small
number
of
lines
of
code.
This
is
basically
we
leverage,
this
open
source
library
called
streamlift
so
and
you
can
install
it
from
you
know,
so
that
sort
of
overview
of
what
this
library
does.
It's
simple
and
that's
not
our
first
step
next
thing.
I
want
to
show
you
the
demos
what
you
can
build
with
the
demos.
G
G
First,
he
provided
api
of
the
url
of
the
api.
Secondly,
enter
your
query
and
then
you
just
load
the
subgraph.
We
take
care
of
all
the
pagination
bypass
api
limit
and
then
you
do
a
little
bit
like
data
frame
transformation,
which
is
documenting
your
documents,
and
then
you
call
this
function
to
visualize
it.
It's
it's
just
this
simple
now
let
me
show
you
something
more
sorry.
Go
ahead,
yeah.
A
Tell
us
a
little
bit
about,
maybe
if
you
envision
an
end
product
right,
end
product
even
being
something
as
simple
as
it
as
a
dashboard
of
sorts.
Is
it
that
that
bubble
tea?
If
you
maybe,
can
give
some
practical
examples?
What
what
is
it
that
probably
can
enable
developers
to
do
that?
We
can
all
benefit
from
in
the
community.
G
Sure
so
we
basically
that
leads
me
to
a
second
demo.
So
this
is
a
much
more
diverse
dashboard
where
you
can
actually
build
all
sorts
of
visualization
with
different
types
of
like
components
we
provide
and
if
you're
a
developer.
Let's
say
you
want
to
visualize
data
under
the
graph.
There
are
currently
just
lots
of
limitations
and
we
try
to
speed
up
process
for
you.
You
can
also
build
this
entire
dashboard,
like
everything
you
see
here.
G
A
G
Right,
that's
right.
We
basically
like
this
is
another
dashboard.
We
use
live
p.
As
an
example,
did
you
notice
the
state
picker
where
you
can
choose
data?
That's
just
one
or
two
lines
of
code.
You
can
put
in
your
putting
your
file
and
then
this
will
show
up
and
you
can
build
a
table
chart
for
these
data.
G
So
that's
a
very
good
question
that
leads
to
my
third
thing
on
my
agenda.
We
don't
have
specific
application
yet
because
we
currently
are
trying
to
build
some
very
useful
demo
and
we
rank
a
bunch
of
you
know,
sort
of
the
things
we
would
like
the
team
to
improve,
and
if
you
pay
attention
to
the
forum,
we
actually,
I
have
been
posting
lots
of
feature
requests
in
terms
of
how
do
we,
you
know,
load
data
faster.
How
do
we
provide
more
query
support?
G
One
of
the
interesting
I
think,
sort
of
the
biggest
thing
we
notice
is
the
sub
graphs.
We
definitely
need
a
more
improvement
on
the
subgraph,
how
to
query
it,
how
to
load
the
data
and,
more
specifically,
we
notice
most
of
subrav
today
under
the
graph
network.
Is
it's
a
very
political
specific
now?
Our
vision
for
the
graph
network
is
that
we
see
an
opportunity
to
build
a
different
type
of
data
analytics
company
on
top
of
this
decentralized
query
layer.
G
Now,
if
you
look
at
a
data
company
today,
like
checking
analysis,
doom
nansen,
they
all
built
on
centralized
database
now
in
order
to
compete
with
this
company
and
even
do
better
than
them.
We
need
actually
much
more
capability
in
the
subgroup
which
allows
us
to
not
only
efficiently
index
data
but
also
allows
us
to
reindex
existing
subgraphs,
pulling
data
from
off
chain
data
source
on
chain
data
source
mix
them
together.
So
that's
how
we
think
a
big
component
to
build
a
data
new
data
analytics
product
on
top
of
this
decentralized
layer.
G
A
B
A
G
A
A
C
Just
wanted
to
sorry
oliver,
I
just
wanted
to
add
that
this
sort
of
project
that
quan
built
is
indeed
very
interesting.
We've
seen
multiple
subgraph
developers
requesting
these
sort
of
features
in
in
the
past
for
to
do
better
that
aggregation
and
to
build
new
to
basically
do
analytics.
On
top
of
all
of
these
data
that
we
are
indexing
and
serving.
C
G
A
Very
good,
okay,
let's
move
on
to
another
innovative
announcement,
we've
seen
in
the
community
about
a
couple
of
weeks
ago,
and
it
came
out
from
streaming
fast.
300X
is
the
key
message
here
and
I
said
in
the
forum
post:
it's
not
the
sequel
to
the
movie
300,
but
incredibly,
exciting
as
well,
and
what
it
means
is.
We
have
been
given
by
streaming
fast,
more
speed
to
the
network
using
two
foundational
innovations
called
fire
hose
and
sparkle,
and
josh
from
swimming
fast
explains
us
what
this
is
all
about
in
more
detail,
josh,
take
it
away.
E
Thanks
oliver,
so
what
I'll
do?
First
I'll
kind
of
take
a
step
back
and
kind
of
give
a
a
simplified
version
of
what
is
firehose?
What
is
sparkles
oliver
just
mentioned.
The
first
thing
to
know
is
firehose,
so
firehose
is
a
different
way
to
ingest
data
from
the
blockchain
into
the
the
database
that
the
graph
node
would
read
from
so
right
now,
if
you're,
using
different
clients
on
ethereum
or
on
other
networks,
it
may
unpack
the
data
from
the
blockchain
in
a
different
way.
E
Sometimes
it
might
not
unpack
all
the
data,
which
is
a
problem
because,
as
the
graph
we
want
to
be
able
to
supply
all
of
the
data
that
a
developer
might
want,
so
we
basically
instrumented
fire
hose
as
a
way
to
unpack
all
the
data
from
a
transaction.
So
someone
passes
a
transaction.
You
know
what
tokens
were
sent
from
a
to
b
or
what
action
was
taking
a
voting
action.
Whatever
may
be,
how
much
gas
was
consumed?
What
was
the
price
paid?
What
are
the
deltas?
So
what
is
the
change?
E
Not
just
you
know
what
was
paid
out,
but
what
was
the
first
balance
was
the
ending
balance,
because
sometimes
that
makes
it
easier
to
do
the
data
aggregation
later
on.
So
we
want
to
make
it
everything
unpacked
as
much
as
possible
so
that
later
on,
we
can
do
much
quicker
calculations
on
that
or
load
it
into
a
database
in
a
much
faster
way.
So
that's
that's
what
we
call
the
fire
hose.
E
So
that's
in
its
own
right,
even
without
anything
else
going
on.
We
believe
that
would
be
somewhere
to
let's
say
a
5
to
10x
increase
in
speed.
So
with
no
other
changes,
no
sparkle,
which
was
the
next
thing
I'll
discuss.
We
should
already
see
a
good
increase
in
speed
and
now
so
sparkle
is
the
way
that
we
do
parallelization.
E
So
it
really
speeds
up,
and
that's
where
we
see
like
that
big
300x
increase
in
speed,
because
we
can
go
through
all
that
data
very
very
quickly.
So
the
300
specifically
is
we've
been
working
with
the
sushi
swap
team
because
they
want
to
make
sure
that
you
know
an
indexer
can
provide
that
data
in
you
know
in
a
readily,
in
a
timely
fashion.
Right
now,
indexes
are
saying
it
takes
them
three
to
four
weeks,
maybe
to
index
sushi
swap,
which
is
very
long.
So
now,
if
sushi,
the
team
wants
to
make
a
change.
E
Well,
maybe
it's
another
month
behind
until
they
can
offer
that
new
data.
So
we
were
actually
able
to
do
it
in
about
two
hours
and
after
about
30
to
35
minutes
we're
already
able
to
inspect
the
data,
because
we've
already,
you
know
downloaded
all
the
data
that
we
needed.
We
can
inspect
it
and
make
sure
there's
no
bugs,
and
if
there
are
we
would,
you
know,
just
lose
half
an
hour,
so
we
can
iterate
very
quickly
whereas
as
it
is
currently,
it
would
take
that
full
month
of
indexing
and
then
you
can
inspect
the
data.
E
The
big
thing
to
know,
because
we
always
like
to
temper
expectations
that
parallelization
and
sparkle
is
not
something
that's
part
of
the
graph
core.
Yet
it's
something
that
we've
built
externally
we're
working
to
integrate
it.
But
there
are
a
lot
of
things
we
have
to
figure
out
with
engine
node
with
figment.
How
are
we
going
to
integrate
this
so
that
it
makes
sense
and
is
deterministic
in
a
way
that
every
indexer
can
run
this?
E
So
I
just
want
to
make
sure
that
that
expectation
is
set,
that
it's
not
something
that's
coming
out
tomorrow
or
next
month.
It.
There
is
a
lot
of
work
that
still
needs
to
be
done
to
be
able
to
bring
that
kind
of
advancement
to
the
decentralized
network.
However,
I
mean
the
sushi
team
is
very
happy
to
see
it
that
there
is
a
lot
of
hope
right
now,
even
if
sparkle
doesn't
come
anytime
soon,
firehose
seems
like
it's
a
lot
closer
in
the
time
horizon,
so
they
will
see
some
big
advancements.
E
So
let's
say
we
were
to
be
able
to
give
them
five
to
10x
increase
in
speed,
maybe
that
three
to
four
weeks,
maybe
now
down
to
you,
know
two
three
four
five
days,
so
they
can
at
least
you
know,
keep
up
a
lot
faster.
So
that's
a
big
thing.
All
of
this
is
open
source.
So
any
teams
that
want
to
work
on
this
please
feel
free
to
reach
out.
You
can
join
on
the
the
discord.
E
A
server
we
have
a
channel
for
index
or
fire
hose
feel
free
to
try
out
the
camassa's
questions,
we're
always
happy
to
work
with
people
and
yeah.
The
big
thing
is
that
we
just
want
to
continue
to
innovate,
so
we
can
make
sure
more
daps
are
serviced
by
the
graph,
especially
on
these
really
really
fast
chains
that
just
creates
so
much
data.
How
do
we
serve
them?.
G
E
So
so
that's
that's.
A
very
good
question
salon
is
something
we've
worked
on
in
the
past.
About
a
year
ago,
we
were
doing
some
work
on
solana
for,
like
serum
decks
and
indexing
that
we
had
built
a
service
that
was
able
to
provide
historical
transactions
for
serum
and
like
right.
Now,
if
you
were
to
go,
do
a
trade
on
serum.
You
know,
after
you
know
a
few
hours,
good
luck
finding
that
trade
history,
it's
it's
salon
is
a
very
fast
chain
and
they
have
don't
have
any
reliable
history
solutions
as
it
stands.
E
Currently
it
does
not
service
solana
completely.
We
know
we
can
tackle
parts
of
it
and
we
it's
part
of
our
road
map
in
the
very
near
future,
we're
hoping
by
maybe
october
november,
we'll
be
back
on
working
on
solana,
because
we
would
really
like
to
bring
solana
to
the
graph
as
soon
as
possible.
So
I
don't
want
to
make
any
commitments
or
any
other
promises
on
when
it
will
happen,
but
it
is
something
that's
really
on
our
mindset.
We've
actually
been
spending
the
team
streaming
fast.
E
We
like
to
do
hackathon
projects
internally,
so
we,
you
know
deep
dive
into
certain
different
protocols
or
different
ideas,
and
this
past
week
we've
just
kind
of
been
working
on
solana
specifically,
so
we
get
ourselves
better
acquainted
with.
What
is
the
developers
dilemma
right
now
in
solana
and
how
do
we
better
solve
it
for
them?
So
it's
definitely
something
that's
really
top
of
mind
for
us.
C
Yeah
I
dropped
one
in
the
chat
but
I'll
I'll
say
it
out
loud,
derek
silva
here
josh,
I'm
just
wondering
if
you
think
this
approach
can
be
replicated
against
other
other
complex
subgraphs.
You
know,
uniswaps
is
obviously
huge.
You
know
a
lot
of
nft
subgraphs
are
probably
generating
a
ton
of
data
right
now
and
based
on
a
thread
I
saw
earlier
today.
C
E
Yeah,
so
I
mean
you
bring
up
a
good
point
there
at
the
end.
Is
that
sometimes
the
way
that
the
smart
contract
is
built
by
the
dap
itself
has
a
lot
of
calls
that
we
can't
actually
change,
because
that's
how
it's
already
built
so,
unfortunately
can't
help
in
that
regard,
and
in
some
ways
fire
hose
might
actually
be
a
little
slower
than
what
they've
built,
because
they've
built
a
kind
of
work
around
so
to
speak,
rather
than
building
it
for
data
aggregation
after
the
fact.
E
So
they
want
to
try
to
port
their
contracts
to
work
within
this
framework
so
that
there
we've
been
in
close
contact
with
quite
a
few
indexes,
especially
because
texas
have
tons
of
data
going
back
and
forth.
The
main
thing
to
know
is
that
our
sparkle
integration
right
now
it's
written
in
go
so
we've
actually
gone
through
and
we're
rewriting
when
we
did
the
pancake
swap
or
right
now,
we're
working
with
sushi
swap
we're
rewriting
their
sub
graph
in
a
different
language.
E
In
go
so
that
it
can
work
with
our
framework,
we
would
like
to
not
have
it
be
and
go
eventually.
So
that's
part
of
the
road
map
as
well
to
make
it
integrate
well
with
the
graph
node
and
how
it
would
work.
So
it's
kind
of
on
a
case-by-case
basis,
we're
talking
to
some
subgraph
developers
as
well
and
if
anyone
else
wants
to
reach
out
to
us
who
might
want
to
take
on
helping
to
write
some
graph
transliterate
the
subgraph
into
another
language.
E
For
now,
until
we
get
to
the
point
where
indexers
can
run
everything,
our
goal
is
not
to
be
a
another
hosted
network
for
the
graph.
Our
goal
is
to
empower
all
the
indexers
to
do
all
this,
so,
while
we'd
like
to
go
and
help
everyone
one
by
one,
we
know
that
won't
scale.
We
want
to
make
sure
all
the
indexers
can
can
do
the
scaling
for
us,
because
that
means
all
the
delegators
get
the
rewards.
The
carriers
get
rewards.
We
want
to
drive
as
much
as
we
can
into
the
centralized
network.
C
E
I
don't
know
the
numbers
offhand,
but
if
you
go
into
the
discord
channel
index
or
fire
hose,
that's
where
a
lot
of
that's
being
talked
about
from
mine,
heart
soul
is
has
given
a
lot
of
numbers
in
there.
You
know
how
big
is
this
bsc
node
after
you
know
running
fireballs,
for
that,
so
you
get
an
idea
from
there
and
then
in
terms
of
the
specifics,
for
let's
say
sushi
swap
I
don't
know
off
hand,
but
I
can
get
that
data.
If
you
ping
me
on
discord,
I
can
definitely
get
you
that.
C
A
A
Very
good,
thank
you
josh
for
that
explanation
and
again,
any
other
questions
coming
up
at
a
later
point
in
time,
just
post
them
in
slido
and
we'll
get
back
to
it.
Okay,
for
our
last
segment.
Today,
before
we
switch
to
q
and
a's,
we
are
going
to
talk
a
little
bit
about
the
graph
governance
process
and
I
will
lead
the
moderation
of
that
segment
feel
free
to
ask
questions
at
any
time
throughout
the
segment.
A
How
can
we
all
engage
in
the
governance
process
in
a
way
that
allows
us
to
help
shaping
changes
to
the
protocol
that
lead
to
improvements
and
the
place
where
that
happens
is
called
the
forum?
It's
this
address
up
here,
forum.thegraph.com,
that's
where
we
post
all
the
specific
proposals
to
enhancements
of
our
protocol.
A
We've
just
seen
the
web
3
rfp
and
grand
ideas,
so
that
was
posted
by
rheem.
This
is
not
an
actual
governance
discussion
where
we
talk
about
protocol
changes,
but
this
is
about
grants
and
initiatives.
So
you
can
see
up
here.
Every
post
has
sort
of
a
tag
label
and,
as
it
relates
to
governance,
related
topics,
they
fall
typically
under
the
governance
and
gip's
tag.
So
this
is
how
you
can
essentially
start
looking
for
different
sort
of
categories
and
start
filtering
for
them
to
see.
A
Where
are
the
discussions
that
are
relevant,
that
you
might
want
to
keep
track
of
and
see
what's
happening?
Let's
talk
about
one
interesting
proposal
that
we
have.
That
is
actually
pretty
deep
in
sort
of
what
we're
discussing
here,
but
it
all
boils
down
to
a
concept
where
we're
looking
for
evaluating
changes
to
our
current
cap,
that
an
indexer
has
to
16x
a
static
16x
number
and
on
the
heels
of
decentralization
discussions
we
were
talking
about.
Okay.
A
How
can
we
change
that
to
a
more
dynamic
number
that
changes
based
on
index
or
size,
and
that
makes
it
for
larger
indexes
comparatively
smaller
and
for
smaller
indexers,
comparatively
larger
idea
being
that
that
would
then
lead
to
a
more
decentralized
stake.
Distribution
in
our
network,
as
smaller
indexers,
have
comparatively
speaking
more
cap
relative
to
their
stake,
a
self-stake.
A
A
Where
we
look
at.
Do
we
end
up
at
a
proposal
where
we
do
feel
many
folks
in
the
community
have
expressed
support?
So
one
example
would
be
this
one
right
here
where
we
talk
about
the
index
of
cut
simplification
proposal.
So
this
is
a
proposal
where
we're
looking
to
improve
for
both
the
indexers
and
delegators.
A
The
way
we
interpret
and
manage
reward
cut
settings
right
now.
You
know
that
we
have
the
reward
cut
setting
and
then
the
effective
cut
that
is
more
relevant
with
regards
to
understanding
what
the
projected
apy
is
and
it's
confusing
right
now.
I
think
everybody
agrees
on
that
and
a
proposal
is
put
out
here
that
simplifies
that
process,
for
both
indexers
and
delegators
alike.
There's
a
lot
of
benefits
associated
with
it.
So
you
can
see
you
know.
A
A
We've
been
following
this
process
for
for
about
nine
months
right
now,
and
we
have
come
together
lately
with
the
group
just
to
get
sort
of
like
reflection
on
it,
put
our
head
up
and
say:
how
well
is
this
process
working
right
now
and
we
have
identified
that
a
number
of
things
you
know
are
not
working.
So
well,
right
now
that
we
can
think
about
how
how
to
improve
them.
One
is
the
simple
transparency:
the
post
that
I've
just
shown.
You
has
had
a
lot
of
engagement
over
the
last
few
weeks.
A
So
part
of
what
we've
done
when
we
put
together
the
prioritization
list
for
delegation
experience
enhancements
was
in
response
to
the
fact
that
we've
had
a
number
of
posts
in
you
know
build
up.
You
know
in
the
forum
that
we
wanted
to
provide
visibility
around
to
also
make
sure
under
the
community
understands
they
have
not
been
forgotten
about,
but
we
also
have,
I
think,
an
area
of
improvement
to
just
improve
our
consistency.
A
But
two
key
takeaways
just
from
this
segment-
and
I
will
conclude
here
shortly-
is
this-
is
the
place
where
you
can
engage.
I
describe
how
you
can
engage,
feel
free.
Nobody
is
restricted
or
limited.
Everybody
can
can
jump
in
and
share
their
thoughts
on
active
discussions
that
we
have
in
fact,
as
a
decentralized
network.
This
is
how
we're
going
to
do
it,
and
this
is
what
we
want
to
do
more
of
in
the
future.
A
We
want
the
more
engagement
we
get,
the
more
confident
we
are
that
this
is
really
something
that
the
community
supports,
so
everybody
is
invited
and
it
is
a
great
way
to
connect
with
people
to
get
to
know
them
better
and
to
also
introduce
yourself.
That
is,
I
think,
another.
You
know
key
point
here
so
with
that.
G
A
Not
responding,
so
let
me
give
you
my
answer
and
I'm
not
engaged
in
the
core
development
piece,
I'm
from
the
foundation,
but
eventually,
yes,
we
are,
you
know
the
goal
is
to
have
everything
on
the
decentralized
mainnet.
As
to
the
timing
of
things,
I
can't
tell
you
what
what
to
expect
what
the
expected
timelines
there
are.
It
is
correct
that
right
now,
mainnet
supports
evm
chains
and
you
know
our
path
to
get
everyone
up.
There
is
something
you
know
from
a
timeline
perspective.
I
can't
speak
to
that.