►
From YouTube: The Graph | Core R&D Call #14 [Jun 30th, 2022]
Description
_The Graph is an indexing protocol for querying networks like Ethereum and IPFS. Anyone can build and publish open APIs, called subgraphs, making data easily accessible._
*The Graph Core Devs coordinate work using the publicly accessible The Graph Core R&D Workspace: https://www.notion.so/thegraphfoundation/The-Graph-Core-R-D-5dca927e67eb4e459539f5bd6d0a7fb8*
------
*Core R&D Call #14 - Jun 30th, 2022*
*Timestamps*
00:00 Intro
03:46 New core dev grant: Messari
10:14 New core dev grant: GraphOps
15:05 Sunsetting the hosted service (timeline and more details)
23:10 Update on multi-chain indexing rewards (GIP "Epoch Block Oracle")
28:35 Arweave support on the hosted service
31:17 Update on file data sources (GIP)
35:13 L2 scaling proposal (GIP)
Link to GIPs mentioned in the call:
GIP-00xx: Epoch Block Oracle (https://forum.thegraph.com/t/gip-epoch-block-oracle/3323)
GIP-00xx: File Data Sources (https://forum.thegraph.com/t/gip-file-data-sources/2721)
GIP-0031: Arbitrum GRT bridge (https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305)
GIP-0034: The Graph Arbitrum devnet with a new rewards issuance and distribution mechanism (https://forum.thegraph.com/t/gip-0034-the-graph-arbitrum-devnet-with-a-new-rewards-issuance-and-distribution-mechanism/3418)
------
Need help migrating subgraphs to the network? Here's a complete tutorial: https://thegraph.com/blog/how-to-migrate-ethereum-subgraph
Feel free to reach out if you need help: migration@thegraph.foundation
------
Follow The Graph on social media
Twitter: https://twitter.com/graphprotocol?s=20
Instagram: https://instagram.com/graphprotocol
LinkedIn: https://www.linkedin.com/company/thegraph/
GitHub: https://github.com/graphprotocol
Website: https://thegraph.com
A
All
right,
hey
everyone,
welcome
to
the
call
it's
our
14th
core,
rnd
call.
As
you
know,
the
purpose
of
these
calls
are
for
court
contributors
to
present
what
they've
been
working
on
updating
the
community
on.
What's
coming
and
brainstorming
with
core
working
groups
and
community
members
like
you
to
bring
you
the
news.
A
In
the
chat
and
show
notes
a
link
to
the
graphs
ecosystem
calendar,
that's
the
link,
you
should
use
to
be
subscribed
to
future
calls
and
I'll
just
face
it
here
in
a
moment
and
yeah.
So,
as
you
guys
know,
last
month
we've
talked
about
graph
day
and
graphic
two
successful
events
organized
by
the
graph
in
san
francisco.
A
A
We've
also
had
this
major
announcement
on
the
hosted
service
that
there's
also
a
blog
post
will
be
some
setting,
and
we
have
dizzy
with
us
on
the
call
that's
going
to
walk
us
through
this
plan,
but
also
we
can
talk
about
how
we
can
then
make
sure
that
the
decentralized
network
will
be
supporting
this
change
with
the
proper
keyword
qos.
That
is
quality
of
service.
A
Substrings
is
a
new
paradigm
that
brings
massive
boosts
in
indexing
performance
of
up
to
100x,
leveraging,
parallelization
and,
and
it's
still
early
days
for
sub
streams,
but
it's
a
very,
very
promising
tech,
and
we
did
take
some
time
yesterday
or
two
days
ago,
I
believe,
to
go
over
substrings
during
the
index
office
hours
episode.
So
if
you've
missed
that,
please
get
on
youtube
search
for
index
or
office
hours,
and
you
can
hear
from
alex
from
streamingfast
on
what
this
thing
actually
is.
A
Last
but
not
least,
we've
also
mentioned.
Are
we
support
in
the
hosted
service
in
beta?
We
have
we've
had
sam
from
rv
joining
rough
day,
and
talking
talk
talk
about
this.
It's
still
in
beta
for
now,
but
yeah
we'd
love
to
get
some
feedback
from
the
community
cool.
That
was
a
lot
so,
as
I
said
today,
we're
going
to
be
talking
about
all
of
these
and
hearing
more
from
core
for
devs,
not
specifically
substreams,
as
mentioned
we've
been
covering
these
over
different
channels.
A
So
we're
not
we're
not
going
to
be,
do
so
be
doing
that
today
and
yeah
so
that'll
be
hosts.
Some
setting
hosted
service,
multi-chain
indexing,
rewards,
epoch,
block
oracle
protocol,
my
migration
to
arbitrarily
and
our
weave
and
better
support
for
file
data
sources.
So
it's
a
lot.
Let's
get
started.
Do
we
have
vincent
from
asari
on
a
call
vincent?
Do
you
want
to
say
hi
and
talk
about
this
new
core
dev.
C
Yeah
first,
thank
you
pedro.
My
name
is
vincent.
I
lead
the
on-chain
data
team
at
missouri
and
for
those
who
don't
know,
missouri
is
one
of
the
leading
research
and
data
analytics
firms
in
the
and
web
theory
space.
So
we
are
super
excited
to
be
a
part
of
the
graph
ecosystem
to
be
a
one
of
the
core
teams
and
and
before
going
into
the
grant,
I
want
to
talk
a
little
bit
about
our
mission.
Mazari
shares
the
same
vision
as
the
graph,
and
that
is
to
to
build
the.
C
No
worries
anyways
to
build
an
open
and
decentralized
internet.
We
need
permissionless
and
accessible
data,
and
today
the
data
is
open
and
missionless,
but
they
are
not
very
accessible,
meaning
that
it
takes
a
lot
of
effort,
a
lot
of
work
to
get
the
raw
data
out
of
the
blockchain
and
make
meaning
of
them,
and
the
graph
does
a
very
good
job
at
solving
that
problem
with
all
the
subgraphs
that
are
acting
as
mini
data
pipelines
and
makes
it
very
easy
for
people
to
carry
them
using
graphql.
C
So,
with
the
12.5
million
dollar
grant,
we
want
to
build
200
subgraphs
over
the
course
of
next
two
years
and
the
the
key
here
is
to
focus
on
standardization
and
and
to
elaborate
on
that
a
lot
of
the
subgraphs.
Today
they
are
they're
built
in
different
ways.
They
have
different
kind
of
schemas.
They
have
different
kind
of
definitions.
C
C
Will
also
have
the
same
metrics
and
each
metric
will
be
defined,
aggregated
and
normalized
in
the
same
way,
such
that
the
end
user
is
very
easy
to
use
that
data,
you
don't
need
any
additional
transformation
additional
tweaking
on
your
end.
You
can
use
it
right
away.
So
with
that
I
want
to
show
I
want
to.
I
can
share
my
screen
right.
C
E
C
A
C
A
C
Yeah
anyways,
so
so
this
is
the
schema.
Every
single
subgraph
in
that
category
will
follow
that
schema.
So
what
I've
showed
was
the
dax
emm
schema?
As
you
can
see
here,
we
have
like
the
list
of
I
don't
know
close
to
20
dexes,
that
that
photo
exact
schema.
Some
of
them
are
designed
very
differently
like
curve
uni
swap
balance
and
banter
they're
all
very
different
dexes,
but
now
with
the
standardization,
you
can
carry
them
in
exactly
the
same
way
and
the
same
apply
for
for
landing
protocols.
Cdp's
yield
aggregators,
all
of
them.
C
Everything
that
has
like
this
symbol
is
already
built.
You
can
click
into
it.
For
example,
it
will
take
you
to
the
to
the
subgraph
and,
of
course
you
can,
you
know,
look
at
all
the
all
the
stuff
using
the
the
sub
subgraph
playground
and
furthermore,
we
actually
built
this
little
website
subgraph.xyz,
where
it
will
allow
you
to
visualize
all
the
data
in
in
your
subgraph
and
because
of
the
standardization
oops
yeah
anyways,
I'm
pretty
much
done
so,
basically
because
of
the
standardization
work.
C
We
have
close
to
30
amazing
subgraph
contributors,
and
some
of
them
are
on
the
call.
Today
I
can
see
there's
a
0x
e1
chris
dylan
harsh
and
a
huge
shout
out
to
these
guys
for
the
amazing
work
in
the
past
couple
months
and
yeah
and
all
the
subgraphs
we
built
are
are
free
open
and
they
are
open
source.
You
can
look
at
the
source
code
yourself,
you
can
start
using
that
data
start
contributing
and
give
us
any
feedback.
A
E
Can
you
guys
hear
me
perfectly?
Yes,
wonderful,
I
was
just
having
some
issues
there.
Thank
you
so
much
for
the
introduction
and
yeah
I'm
excited
to
be
here
and
excited
to
get
into
it.
I'm
gonna
try
not
to
share
my
screen
because
of
the
issues
we're
having,
but
we'll
rock
and
roll.
So
I'm
able-
and
I
am
from
graphops
and
I'm
incredibly
excited
today,
to
talk
to
you
guys
about
the
grant
we've
received
from
the
graph
foundation.
E
So
we
are
super
mission
aligned
with
the
graph.
A
lot
of
what
vincent
was
saying,
we
definitely
echo,
and
we
are
excited
about-
is
a
very
sophisticated
protocol
in
the
web3
ecosystem,
and
nowhere
is
that
more
true
than
the
concentration
of
bigger
brains
that
we
have
amongst
the
core
developers
and
we're
fortunate
to
be
able
to
join
the
ranks
of
core
developers.
So,
just
to
give
you
guys
an
idea
of
some
of
the
things
that
we're
going
to
be
working
on
as
a
part
of
the
grant
that
we've
received.
E
So
if
you
haven't
already
seen
in
the
theme
of
today's
conversation,
a
lot
of
the
work
that
we're
going
to
be
doing
is
around
indexers
and
the
third
and
final
piece.
Indexer
experience
is
kind
of
where
we're
going
to
spend
a
lot
of
energy
and
effort,
so
we'll
be
launching
some
kubernetes
centric,
kubernetes,
centric,
automation
and
tooling.
For
indexers.
E
We
believe
that
helping
indexers
run
better
operations
will
overall
increase
the
quality
of
service
of
the
network
and
therefore
make
the
graph
an
even
more
credible
option
for
people
who
are
looking
to
get
data
from
blockchains
in
the
near
term,
we'll
be
focused
on
the
kubernetes,
centric,
automation,
tooling,
and
the
gossip
network
so
make
sure
you
keep
an
eye
out
for
that.
We're
going
to
be
launching
some
grc's
to
kind
of
solicit
some
feedback
from
the
community
and
get
and
get
certain
perspectives
we'll
be
continuing
index
office
hours.
E
So
I
linked
a
a
video
that
pedro
mentioned,
which
was
a
recording
of
the
substreams
episode.
We
did
this
tuesday.
We
believe
that's
an
important
venue
for
educating
the
indexers
that
exist
in
the
ecosystem
and
also
encouraging
new
indexes
to
join
the
ecosystem,
to
again
increase
that
quality
of
service.
For
us,
indexers
are
our
main
constituent
and
we
we
will
be
working
incredibly
hard
to
improve
everything
that
is
around
the
indexer
experience
and
the
index
of
stack.
So
thank
you
all
for
listening
to
this
short
introduction
about
us.
E
A
Thanks
abel,
thank
you
so
much
very
cool
okay,
so
I
am,
I
do
have
more
more
duration
controls
now.
So
if
you
guys
want
to
speak
to,
let
me
know
in
the
chat
I
try
to
disable
screen
sharing
and
whiteboards.
Hopefully
this
will
go
well.
So
next
we're
going
to
be
talking
about
deprecating
the
hosted
service
as
mentioned,
so
I
will
give
dizzy
the
opportunity
to
speak
about
this,
and
then
we
can
have
also
adam
talking
about
the
epoch
block
oracle,
and
now
we
can
get
multi-chain
indexing
rewards
on
the
decentralized
network.
A
B
A
C
B
All
right
so
we're
just
going
to
talk
briefly,
there's
actually
only
two
or
three
slides,
but
it's
helpful
to
see
it
versus
me
talking
through
it
and
sort
of
trying
to
remember
it.
We
are
working
at
sunset,
service
and
transition,
all
the
traffic
over
to
the
network
where
it
belongs,
and
so
the
plan
is
pretty
straightforward,
starting
in
q3.
So
you
know
upcoming
we're
gonna,
stop
allowing
new
sub
graphs
on
the
hosted
service
to
be
created.
B
When
the
network
supports
that
change,
so
the
obvious
sort
of
first
pass
there
is
gonna,
be
around
ethereum
mainnet.
So
what
we're
basically
gonna
wind
up
doing
is
on
the
hosted
service.
If
you
try
to
create
a
new
sub
graph,
you'll
now
have
to
select
the
you
know,
which
chain
you
want
and
if
you
pick
ethereum,
because
that's
supported
on
the
network,
we're
going
to
redirect
you
over
to
studio
and
you
have
to
create
the
subgraph
over
there.
B
So
this
is
going
to
help
us
because
it's
going
to
start
encouraging
people
to
start
from
the
very
beginning
on
the
network
instead
of
the
hosted
service,
so
we're
rolling
out
those
pieces
in
in
q3.
In
q4
and
sort
of
the
next
step
is
then
to
stop
upgrades
for
hosted
service
accounts
or
sorry
should
be
subgraphs.
So
if
you
have
a
sub
graph
that
you
want
to,
you
know
deploy
a
new
version
of
that
is
currently
on
hosted
service.
B
We're
gonna
force
you
to
move
it
over
to
studio
and
deploy
it
onto
the
network.
Now
we're
also
gonna
have
migration
tools
and
grants
and
other
tools
and
and
and
sort
of
levers,
if
you
will
to
encourage
people
to
to
make
that
transition,
but
between
these
two
phases
we
hope
that
most
of
the
most
of
the
traffic
winds
up
shifting
over
the
net
over
to
the
network,
you
know
by
the
end
of
q4
and
then
and
q1
of
next
year,
is
when
we
sort
of
do
the
cleanup
and
all
of
that
other
stuff.
B
Now.
The
challenge
here
is
that
there
are
some
dependencies
right.
So
in
q3,
we've
got
to
roll
out
multi-chain
support
on
the
network
and
start
the
process
of
adding
more
chains
on
the
network
which
we're
on
track
for
right.
Now,
there's
a
couple
of
new
oracles.
We
have
to
roll
out
there's
some
arbitration
stuff.
The
council
needs
to
sort
out,
but
all
those
pieces,
and
that
plan
is
moving
along.
So
by
the
end
of
q3,
we
should
be
able
to
support.
B
You
know:
non-ethereum
mainnet
chains
on
the
network,
have
it
available
for
rewards
and
all
that
jazz.
It's
gonna
take
time
to
roll
all
the
chains
out
because
there's
a
lot
of
them,
but
it
will
all
of
the
supporting
mechanisms
will
be
in
place
and
we
will
start
methodically
working
with
the
foundation
and
every
other.
You
know
core
dev
to
roll
these
things.
B
B
So
if
you
go
to
the
hosted
service
to
a
sub
graph,
you've
already
got
deployed,
you
can
click
a
button
and
it
will
transfer
it
over
to
the
studio
for
you
in
a
very
sort
of
automated
way
and
make
it
really
easy
for
you
to
get
on
the
network
during
q3,
we're
also
hoping
to
roll
out
the
l2
support,
which
will
reduce
costs
and
encourage
curation
and
migration.
What
else
was
the
question
here
sorting
things
out,
so
you
can
ignore
that,
but
that's
sort
of
the
gist
of
it.
B
That
and
again
just
to
talk
brief.
You
know,
just
to
recap:
we
have
a
multi-phase
project
phase,
one
happens
starting
in
q3,
where
we're
stopping
new
subgraph
deployments
phase
two
starts
in
q4,
we're
stopping
upgrades
and
then
phase
three
will
be
the
final
sort
of
migration
and
cleanup
and
whatnot.
So
that's
that's
the
plan.
I
will
say
I've
done
a
couple
of
these
scales
of
migrations.
B
B
Of
ethereum
mainnet,
we
know
it's
supported
on
the
network
right
now.
Stopping
new
subgraphs
from
being
created
on
the
host
of
service
will
stop
the
growth
of
the
hosting
service
and
start.
You
know
really
kicking
into
the
growth
of
the
of
the
network
as
well,
which
benefits
everybody
so
anyway,
good
stuff.
All
around
any
questions
thoughts,
I
don't
really
need
any
fancy,
screen,
drawings
or
trolling
messages,
though.
A
Yeah
very
exciting
I'll
just
leave.
Also
in
the
chat
like
you
guys,
should
be
prepared
to
start
my
migrating
subgraphs
over
the
decentralized
network.
You
can
always
reach
out
to
a
few
folks
on
this
photo,
but
I'm
also
going
to
link
here
in
the
youtube
show
notes
a
link
to
a
blog
post,
where
you
can
follow
a
very
nice
tutorial.
I
think
that
simone
has
drafted
yeah
so.
F
F
B
You
know
it's
just
how
the
network's
constructed,
if
you're
the
first
one
on
the
chain
you
will
and
the
only
or
one
of
the
few
indexers
and
there's
a
number
of
subgraphs
on
there,
you
will
get
a
significant
sort
of
set
of
rewards
just
as
part
of
the
natural
indexing
rewards
and
those
proportions,
so
that
should
help,
but
I
do
know
that
the
graph
foundation
has
some
other
plans
too,
to
help
bootstrap
that
overall
effort.
So
I
don't
know
pedro.
B
A
D
D
Yeah
yeah,
so
that
kind
of
segues,
I
guess
on
to
a
onto
the
supporting
like
other
chains
on
the
network-
and
I
think
I've
talked
in
this
group
about
this.
I
don't
know
if
I
can
share
my
screen
briefly,
but
support
for
multiple
chains.
At
the
moment,
obviously
only
ethereum
indexing
is
is
supported,
essentially
because
there
isn't,
in
order
to
provide
security
for
the
indexing
awards,
the
provider
we
need.
D
Data
is
not,
and
so
does
this
whole
piece
of
work
to
technically
unblock
adding
chains,
and
so
the
first
part
that
was
the
data
edge,
which
essentially
is
just
a
means
of
bringing
data
on
chain
which
zach
worked
on.
I
think
he's
talked
about
here
before
and
that's
essentially
been
accepted
and
we're
going
to
be
adopting
this
sort
of
data
edge
based
oracle
pattern.
D
The
epoch
block
oracle
itself
is
essentially
the
implementation
of
that
and
as
folks
chiago
philippo
have
been
working
on
this,
and
this
is
non-trivial
because
it
needs
to
be
a
system.
That's
pretty
resilient
to
all
sorts
of
things
like
gas
spiking
on
ethereum
to
chains
behaving
in
slightly
unexpected
ways.
D
So
this
this
work
is
in
progress,
but
this
essentially
the
the
real
meat
of
of
this
project
and
hopefully
deploying
to
test
net
more
just
for
our
internal
testing,
rather
than
on
the
sort
of
protocol
test
net
this
week.
There's
then
updating
a
bunch
of
affected
components.
The
idea
is
that
is
that
actually
indexing.
D
Other
subgraphs
should
should
work
in
a
like,
almost
exactly
exactly
the
same
way
as
main
net
sub
graphs,
with
some
small
changes
under
the
hood
to
the
index
region
so
essentially
how
it
chooses,
which
blocked
to
close
an
allocation
for,
and
also
some
like.
Some
other
changes
in
the
studio
and
explorer
which
are
sort
of
can
maybe
serve
as
more
information
and
be
more
useful
for
them
for
their
users.
D
And
then
there
are
some
changes
to
the
gateway,
a
lot
of
which
are
already
underway,
and
then
we
get
into
the
difficulty
of
like
adding
new
networks
over
time
and
car.
Your
question
kind
of
did
touch
on
some
of
the
nuance
here,
the
there's
a
obviously
on
any
given
network.
There's
a
sort
of
supply
demand
dynamic
where
there
are
a
bunch
of
subgroups
who
want
to
be
deployed
on
the
network.
In
some
cases
we
do
have
indexers,
who
we
know
support,
say
bsc.
D
I've
had
vscr,
I
knows,
for
other
reasons
who
are
sort
of
eager
to
support,
support
given
network,
but
we're
conscious
that
we
need.
We
need
enough
indexes
and
the
divers
have
indexes
for
all
the
chains
that
are
being
added.
So
this
again
is
a
work
in
progress
in
terms
of
which
networks
get
added
and
and
and
how
they
get
rolled
out
over
time.
D
Obviously,
with
a
view
to
disney's
point
of
full
support
of
everything
so
like
any,
any
subgraph
could
be
deployed
to
the
network,
and
so
this
is
one
where
we'll
be
reaching
out
to
indexes
engaging
with
existing
indexes,
but
also,
potentially,
people
who
aren't
running
indexes,
who
are
quite
chain
aligned
would
be
a
good
fit
to
run
into
indexes
if
they're
already
running
archive
nodes.
So
yes,
so
that's
essentially,
where
we're
currently
out
we're
pretty
close
on
the
technical
side
to
to
readiness.
G
A
Yeah
exactly
so
brandon
kramer
is
saying
for
all
those
indexers
who
are
already
working
on
bsc
and
other
more
challenging
chains.
We
would
love
to
hear
your
feedback
thoughts,
so
we
can
continue
to
integrate
this
into
our
docs,
etc,
feel
free
to
reach
out
on
discord,
yeah,
absolutely
brandon,
and
that's
what
I
was
going
to
mention
right
now
and
as
a
comment
to
disease
as
a
follow-up
comment
to
disease
comment
was
that
the
foundation
will
indeed
work
closely
with
indexers
on
making
sure
that
they
are
ready
to
support
this
change.
A
That's
something
we've
done
before
with
the
mission
control.
What
I
was
saying
that,
like
we
just
don't
know
exactly
how
things
will
work,
but
obviously
the
foundation
will
be
involved
in
making
sure
that
we
have.
We
can
teach
indexers
how
to
run
things
and
also
the
fire
fire
halls.
So
probably
there'd
be
some
workshops.
There
were
still
disgusting
things,
but
yeah
the
foundation
will
try
to
obviously
make
sure
that
indexes
skating
did
support
this
change
properly,
once
ready,
very
cool,
we're
very
close
thanks
adam.
Thank
you
so
much.
A
There
was
another
thing
we've
mentioned.
Maybe
you
can
speak
to
our
weave,
that's
been
announced
on
during
graph
day,
and
we've
also
been
talking
about
having
better
support
for
file
data
sources.
Could
we
talk
about
how?
What
is
it
that
we
have
currently
with
our
weave
how
this
whole
file,
indexing
or
bed
of
support
will
look
like
how
far
along
are
we
and
how
the
two
may
be
related.
D
Sure,
yes,
so
I
can
actually
talk.
I
guess
to
a
little
bit
how
about
how
ways
in
which
they're
not
not
related
or
not
the
same
thing
as
well.
So
we've
support
just
as
a
reminder.
This
is
indexing
our
weave
as
a
blockchain,
a
chain
box
with
transactions,
rather
than
our
weave
as
a
file
storage
network.
D
So
there's
an
initial
implementation,
which
essentially
means
there's
a
a
firehose
compatible
or
or
if
ios,
integration
or
like
of
the
rwev
client,
which
existing
is
up
and
running
and
is
essentially
configured
on
the
hosted
service.
So
essentially,
this
means
that
you
can
create
subgraphs
based
on
our
weave
blocks
and
transactions.
So
it's
been
out
there.
D
There
are
some
things
which
we
know
that
this
sort
of
doesn't
support,
for
example
like
bundler
transactions,
so
bundler
is
essentially
like
essentially
a
way
of
batching
up
many
many
transactions
which
then
gets
submitted
onto
our
weave.
So
it's
almost
kind
of
like
an
ar-weave
firewave
roll-up,
which
actually,
I
think,
pedro
from
our
discussions
and
discovery,
actually
makes
up
a
like
a
large
amount
of
what's
going
on
to
our
weave
at
the
moment.
D
So
there's
the
kind
of
things
that
aren't
supported,
but
we're
at
the
point
where
it
is
available
and
we
essentially
need
to
start
getting
a
bit
of
user
feedback
and
understand,
use
cases
for
this
and
also
areas
where
it
falls
short.
So,
for
example,
we've
already
added
sort
of
better
support
for
some
decoding,
or
at
least
in
documentation
and
sort
of
like
address
filtering,
where
I
think
we
were
using
public
keys
initially
so
essentially
we'll
need
to
build.
D
This
out
like
like,
like,
I
think,
an
obvious
use
case
for
the
data
at
the
moment
would
be
something
that
looks
like
a
an
away
block
explorer
could
could
be
built
because
you're
drinking
off
transactions
and
blocks,
but
yeah
need
to
essentially
do
the
work
and
and
outreach
to
get
this
feedback
and
work
out.
What
would
be
useful
to
the
community
if
it
is
lots
of
wonderful
support,
then,
and
bundler's
like
interrogation,
is
an
important
part
of
what
people
would
want
from
a
block
explorer.
D
Obviously,
the
integration
is
not
gonna,
be
quite
what
people
need
need
quite
yet
because
that's
where
our
weave
is
at
and
I
think
we
need
to
just
do
a
bit
more
sort
of
proactive
outreach
and
also
building
ourselves.
So
that's
then
destroying
separate
from
file
data
sources.
So
this
one-
and
I
actually
have
at
the
top
here
like
file
data
sources,
which
has
been
a
gip
in
the
forum
for
a
while,
and
that
work
is
in
progress
in
terms
of
the
initial
implementation.
D
This
will
enhance
essentially
the
existing
ipfs
support,
which
it
currently
exists
in
graph
node,
but
it's
quite
brittle
and
it's
also
implemented
in
a
way
that
can
never
be
made
deterministic,
so
just
just
to
elaborate
a
little
bit
more
there.
Obviously,
one
of
the
key
value
propositions
of
subgraphs
is
determinism
which
say
that
when,
if
you
query
one
index
surface
of
graphics
of
a
given
block
and
get
hvac,
you
then
query
another
one.
D
D
We've
taken
the
sort
of
pragmatic
approach
of
creating
this
more
robust
implementation,
where
we
can
then
get
more
feedback,
add
more
add
more
other
type.
Like
more
other,
like
you
notice,
it's
called
file
data
sources,
not
ipfs
data
sources,
because
it
is
essentially
done
in
solution
done
in
a
way.
That's
agnostic
to
the
precise
type
of
file,
so
we'd
be
able
to
add
fetching
for
other
oe
files
or
files
from
other,
like
storage
networks,
so
again
yeah
getting
user
feedback
understanding.
D
What
features
need
to
be
added,
but
then
also
once
we
have
that
information
that
knowledge
moving
towards
deterministic
support,
which
there
is
quite
a
broad
sort
of
solution,
space
for
and
there
are
trade-offs
between
all
of
them.
But
we
want
to
do
that
and
once
we
have
a
slightly
more
informed
viewpoint.
A
Yeah
thanks
for
clearing
that
out
adam
any
questions
here.
I
guess
that
will
unlock
fairly
fairly.
I
mean
we
hope
we
all
have
this
nft
we've
already
we've
had
this
need
to
better
serve
the
nft
community,
let's
say
and
hear
their
problems,
so
maybe
that's
something
that
obviously
will
hopefully
will
be
able
to
help
out
with
in
the
future,
and
that's
apparently
very
very
soon
it's
coming
any
questions
on
this,
or
should
we
move
on
to
l2
arbitramen
here
from
the
protocol
team,
we
have
pablo
and
ariel
in
here.
G
G
G
And
then
this
allows
us
to
have
an
escape
hatch
in
the
future.
If
something
goes
terribly
wrong
and
arbitrary
disappears
from
the
face
of
the
earth,
then
we
can
still
recover
the
tokens
from
there,
because
we
just
approve
contract
or
some
other
account
to
manage
the
funds
there
and
to
recover
them
in
some
way,
maybe
with
a
merkle
tree
root
or
something
like
that
and
then.
G
Finally,
the
the
other
big
thing
that
we
added
here
is
being
able
to
do
call
hooks
when
you're
sending
tokens
to
2l2
in
particular,
and
this
is
something
that
the
default
arbitrary
bridge
had
for
a
while
and
then
they
removed
it
and
now
they're,
adding
it
back.
So,
in
the
end,
we
might
actually
end
up
using
their
approach
to
to
do
this
interface.
But
for
now
it's
a
custom
implementation
and
the
the
idea
is
when
you
send
tokens
from
a
122.
G
This
set
of
contracts
is
up
and
it's
being
audited
right
now,
so
hopefully
it'll
be
ready
to
try
on
mainnet
relatively
soon,
and
then
I
think
oh
yeah.
I
can
show
a
little
bit
of
how
this
works.
I
don't
want
to
get
into
too
much
detail,
but
the
basic
idea
is:
when
you
want
to
send
tokens
from
l1202,
then
you
call
the
l1
graph
token
gateway
and
say
I
want
to
do
an
outbound
transfer.
G
You
first
need
to
approve
the
gateway
to
take
the
tokens
from
you
and
that
gateway
is
going
to
put
those
tokens
into
the
bridge
escrow
contract
and
it's
going
to
send
what
arbitrarily
calls
a
retriable
ticket
that
is
a
ticket
for
a
transaction
in
l2
and
that's
going
to
be
redeemed
in
l2,
so
that
the
layer
2
blockchain
is
going
to
run.
That
transaction.
G
That's
going
to
call
the
l2
graph,
token
gateway
and
that's
going
to
mint
new
tokens
in
l2.
So
on
the
l1
side,
any
tokens
that
we
sent
to
are
going
to
stay
in
that
bridge
escrow
contract
locked
until
you
bring
them
back
to
a1
and
on
the
l2
side
we
will
mint
tokens
that
are
backed
by
the
tokens
on
o1.
So
any
token
on
l2-
and
this
is
very
important-
it's
going
to
be
very,
very
important
in
jp34
as
well.
G
You
call
outbound
transfer,
but
this
time
on
the
l2
side
and
the
tokens
that
you
had
there
are
going
to
be
burned
and
then
they're
going
to
be
released
from
escrow
on
the
other
side
so
far,
so
good,
so
that
that's
the
bridge,
if
anyone
has
any
questions
so
far,
I'm
going
to
move
on
to
that
the
big
bigger
gip
that
is
jp34
for
the
devnet,
so
carrying
on
this
one
is
quite
a
big
jp
if
you've
seen
it
in
the
forums.
It's
quite
long.
G
We're
proposing
an
arbitrary
devnet-
and
definitely
it's
kind
of
a
tricky
word
here,
because
we're
not
saying
we're
going
to
do
this
just
in
testnet.
The
devnet
is
an
experimental
deployment
tool
too,
where
we
can
try
all
of
the
mechanisms.
All
of
the
the
whole
protocol
having
subgraphs
there
with
even
query
fees
and
so
indexers
can
stake
in
l2
delegators
can
delegate
curators
can
curate
on
subgraphs.
So
so
we
have
a
mirrored
deployment
of
the
graph
protocol
on
the
arbitrom
mainnet
deployment.
G
This
will
have
one
thing
that
is
different
from
a
one
one
main
thing
that
is
different
from
one
and
that
thing
is
in
dexa
rewards.
So
we
call
it
the
devnet,
because
it's
not
going
to
have
index
rewards
at
first,
but
we
are
changing
and-
and
the
gip
here
proposes
changing
the
way
rewards
work
so
that
when
we
want
to
enable
them,
we
can
have
rewards
on
a1
and
l2
at
the
same
time,
and
we
can
have
both
networks
running
in
parallel
for
a
while
and
gradually
transition
the
community
towards
the
full
l2
deployment.
G
So
there's
a
future
a
near
future
where
we're
going
to
have
stuff
running
on
a
1
and
stop
running
102,
and
this
will
help
us
gain
that
everything
is
working.
Fine
that
puts
our
needs
and
that
yeah
everything
is
okay
and
then
gradually
there's
going
to
be
more
rewards
on
o2
until
it's
clear
that
l2
is
better
because
the
gas
costs
are
so
much
lower,
and
so
hopefully
that
means
eventually
we
can
disable
the
a1
deployment
or
or
disable
the
rewards
101.
G
G
now
on
l1
sorry-
and
this
is
very
important
because
of
what
we
said
before
that
conceptually
we
want
the
graph
token
to
remain
a
mainnet
token,
and
we
want
every
token
in
l2
to
be
backed
by
a
token
l1.
We
don't
want
a
scenario
where
someone
somehow
compromises
cl2
side
and
they
can
bridge
tokens
back
to
a
one
that
didn't
actually
exist
in
l1
and
then
create
new
graph
tokens.
G
G
This
is
the
way
rewards
are
currently
minted
in
the
protocol,
so
when
an
indexer
closes
on
a
location,
this
is
a
call,
a
transaction
to
the
the
staking
contract
and
that
staking
control
is
going
to
call
what
we
call
the
rewards
manager.
That
is
a
separate
contract
that
has
all
of
the
calculations
of
what
are
the
rewards
that
correspond
for
this
graph
and
therefore,
what
are
the
rewards
that
correspond
for
this
allocation
and
this
indexer
and
its
delegators
and
then
the
rewards
manager
is
going
to
mint
those
tokens.
G
So
we're
changing
this
to
a
new
reward
session.
Issuance
mechanism
where,
like
right
now,
issuance
and
distribution
are
together,
we
meant,
and
then
we
immediately,
we
send
it
to
the
taking
contract
to
send
it
to
indexers,
and
this
happens
when
an
allocation
is
closed.
Now
we
want
to
separate
this
and
we
want
to
mint
the
tokens
at
a
at
a
different
time.
G
So
what
we
have
is
a
new
contract
called
the
reservoir
and
we
have
those
contracts
on
a
1
and
an
l2,
the
l1
reservoir
and
the
l2
reservoir
and
the
l1
reservoir
has
a
drip
function
and
certain
actors
that
we're
going
to
call
keepers
are
able
to
call
this
l1
reservoir
drip
function.
That
means
all
of
the
tokens
that
we're
going
to
need
that
we're
that
we
could
possibly
give
out
for
inductor
rewards
over
the
next
week
or
so,
and
so
the
reservoir
is
going
to
keep
those
tokens
there
until
when
an
allocation
is
closed.
G
G
So
let
me
see
if
I
forgot
anything
from
the
slide:
okay,
so
yeah
going
back
to
this
issuance
here
is
an
example
of
why
we
want
to
have
those
call
hooks
on
the
bridge
when
we're
dripping
rewards
on
a
one,
we're
calling
grip
the
keeper
which,
in
in
the
latest
proposal
keepers,
are
indexers.
Actually,
who
can
do
this
through
the
indexer
agent
and
they
can
get
a
a
small,
but
hopefully
enough
to
cover
gas
costs,
reward
a
keeper
reward
for
calling
this.
G
And
then
we
we
mint
those
tokens
and
we
mince
everything
that
we
need
for
a
one
and
four
two,
and
then
we
send
those
tokens
to
the
l2
reservoir
on
l2
and
that
needs
to
use
the
bridge
because
we're
sending
grt
from
122
and
that
needs
to
happen
through
the
bridge.
But
we
also
want
to
tell
the
el
tourism
our
how
much?
G
What
is
the
amount
of
rewards
that
you
you
need
to
distribute
over
the
next
week?
What
is
the
the
supply
base
that
we
used?
What
is
the
issuance
rate
that
we
use
so
that
the
l2
reservoir,
when
it
when
the
rewards
manager
asks
it?
What
are
the
rewards
for
this
period?
It
can
give
the
right
answer
based
on
the
amount
that
it
has
received,
and
we
want
to
do
that
in
one
go.
It's
kind
of
messy
if
we
need
to
send
two
separate
messages,
so
we're
just
sending
that
to.
G
G
That
is
how
much
of
those
global
rewards
are
we
sending
to
o2
and
then
the
rewards
manager
will
still
compute
the
rewards
per
signal,
but
it
will
use
that
global
rewards
for
tell
me
what
the
rewards
for
this
layer
are,
that
is
kept
by
the
l1
reservoir
and
hopefully
that's
clear,
there's
a
lot
more
detail
into
these
formulas
in
the
gp.
If
you
want
to
take
a
closer
look,
so
I
already
explained
this
now
going
to
what
is
our
our
plan
in
general?
Where
do
we
stand
with
all
of
this?
G
So
for
jp
34,
there's
two
pull
requests
and
for
jp31
there's
one
pull
request
for
the
bridge
which
is
being
audited
for
jp34.
There
are
two
pull
requests.
The
first
one
is
being
audited
right
now.
The
second
one
will
probably
go
in
an
audit
very
soon,
but
even
if
we
only
have
that
first
pr
audited,
we
should
be
able
to
to
start
the
deployment
at
least
of
the
l2
side
of
things
of
this
new
rewards
mechanism.
G
So
with
a
merge
coming,
we
know
that
ring
could
be
is
not
going
to
be
around
for
much
longer.
So
we
need
to
test
all
of
this
in
tesla
first,
and
for
that
we
need
a
new
test
net,
because
we
need
to
deploy
the
test
network
early.
So
that's
going
to
happen
first
and
then,
once
we
have
the
gurley
test
net
working,
we
can
deploy
that
arbitrary
grt
bridge.
G
Obviously,
we've
already
done,
like
mock
deployments
of
this,
to
try
it
out,
but
that
bridge
we
need
to
play
two
to
a
full
test
net
that
is
running
and
that
has
sub
graphs
and
everything
so
we're
going
to
deploy
the
bridge
there.
And
then
we
can
deploy
the
l2
side
of
the
devnet
with
all
of
the
contract
contraction
l2
with
this
new
rewards
mechanism.
G
It
just
won't
have
any
rewards
because
it
will
never
receive
a
drip
from
a
one,
and
so
once
we
have
that
we
can
start
testing
the
l2
side
of
things
as
much
as
we
want
and
then
eventually
we
can
deploy
all
of
the
l1
changes.
That
start
dripping
rewards
to
l2,
and
that
should
include
the
second
pr
that
second
pr
adds
that
keeper
reward
for
drip,
so
that
someone
is
incentivized
to
call
it
and
then
eventually
we
can
initialize
the
inductor
rewards
102..
So
so
what
I've
just
explained
is
the
plan
for
testnet.
G
We
want
to
do
the
same
in
mainnet,
not
necessarily
going
through
all
of
the
steps
in
testnet
before
we
go
to
mainnet
once
we've
tested
the
l2
set
of
things.
So
once
we've
done
step
four
on
the
testnet
side
of
the
plan,
we
should
be
able
to
start
deploying
stuff
into
mainit
as
well
and
and
running
steps,
one
two
and
three
so
deploying
all
of
the
l2
side
of
things
having
a
devnet
having
indexers
taking
l2
subgraph
developers
deploying
subgraphs
tool
to
in
an
experimental
manner,
but
still
and
then
eventually,
step.
G
G
That
is
how
do
we
actually
do
that
plan
of
going
from
zero
rewards
to
100
rewards
on
l2,
or
maybe
that
maybe
the
end
game
is
not
100,
but
we'll
see
about
that,
so
that
that's
kind
of
the
general
plan
of
having
the
graph
protocol
running
on
l2
now
there's
going
to
be
a
lot
of
things
to
do
after
that.
So
one
of
the
things
that
we're
working
on-
and
I'm
actually
experimenting
with
this
right
now
is
how
do
we
facilitate
people
moving
stake
or
curation
signal
from
l1202?
G
So
this
is
going
to
take
a
bit
more
time
because
it's
kind
of
complex.
How
do
you
do
that
safely
and
properly,
but
we
are
working
on
that
as
well
and
then,
of
course,
as
I
mentioned
at
the
beginning,
this
is
only
the
smart
contract
side.
There
is
a
lot
of
work
for
the
products
adapting
the
explorer
the
subgroup
studio,
the
indexer
agent,
the
oracles
and
so
on.
G
So
like
we're
doing
a
whole
new
deployment
with
some
particularities
and
there's
going
to
be
a
lot
of
teams
working
on
this,
so
yeah
there's
a
lot
more
to
come.
So
hopefully
there's
going
to
be
more
updates
coming
soon
and
I
think
that's
all
I
had
so.
If
there's
any
questions
I'm
here,
I
know
that's
a
lot
to
take
in
so.
A
H
Hey
how
you
doing
pablo.
Thank
you
very
much
for
the
presentation.
I
just
wanted
to
emphasize
the
importance
that
we
get
as
many
eyes
as
possible
on
this
excellently
written
gip.
That
pablo
has
put
on
the
forums
it's
been
there
for
13
days
now
we
sometimes
have
a
little
bit
of
issue
with,
I
guess,
agility
pro
making
things
progress
in
a
timely
fashion,
and
this
is
a
really
important
and
really
complex
gip.
So
you
know
we
have
the
brain
trust
on
the
call
here.
H
So
I'm
just
you
know,
I'm
just
asking
all
of
you,
if
you
have
time,
is
to
take
a
little
bit
of
time
to
look
at
this
on
the
forums
and
add
your
commentary
because,
as
pablo
says,
there's
a
lot
more
than
just
this
initial
gip
required.
There's
a
lot
of
teams
that
need
to
work
on
specific
pieces
to
make
this
work,
so
just
to
plea
really
that
everybody,
if
you
have
some
time
to
to
read
it,
it's
very
well
written,
very
readable,
a
bit
of
maths
in
there.
H
A
Yeah,
I
think
that's
it
yep.
Thank
you
so
much
paul
yeah,
as
jim
mentioned.
This
is
a
it's
going
to
be
a
big
lift.
Do
take
the
time
to
read
the
gip.
Definitely,
and
it's
pretty
exciting,
I
mean
we've
been
we've
we've
seen
people
asking
for
this
and
it's
going
to
bring
a
lot
of
great
benefits,
not
just
economic
efficiency,
but
also
the
experience
as
mentioned
before.
It's
going
to
be
a
lot
better.
Very
nice
thanks!
Thank
you.
Thank
you
ariel
for
working
on
this
and
everyone
in
the
index.