►
From YouTube: The Graph | Core Devs Call #16 - Sept 29, 2022
Description
*Core Devs Call - September 29th, 2022*
*Timestamps*
00:00 Intro
01:49 MIPs (Migration Infrastructure Providers) Program Brief Update
06:28 File Data Sources
17:01 Subgraph Data Pruning
28:08 Updates on L2 and GIP-0037
41:32 Current State of Curation v1.x and Roadmap to 2.0
*Link to external sources mentioned in the call:*
- MIPs Blog Post: https://thegraph.com/blog/mips-multi-chain-indexing-incentivized-program
- MIPs Homepage: https://thegraphfoundation.notion.site/MIPs-Home-911e1187f1d94d12b247317265f81059
- File Data Sources: https://hackmd.io/opoO7onKRR-2GwI3zHnNFg?view
- GIP-0031: Arbitrum GRT Bridge https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305
- GIP-0034: Arbitrum Devnet with a New Rewards Issuance and Distribution Mechanism https://forum.thegraph.com/t/gip-0034-the-graph-arbitrum-deployment-with-a-new-rewards-issuance-and-distribution-mechanism/3418
- GIP-0037:The Graph Arbitrum Deployment with Linear Rewards Minted in L2 https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551
- GIP-0039: Curation v1.x https://forum.thegraph.com/t/gip-0039-curation-v1-x/3613
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
A
A
And
Snapple
screen,
but
anyway
you
can
see
it
right
thumbs
up
Alex
someone
thumbs
up,
yes,
perfect!
Thank
you,
Matthew,
okay,
all
right!
So,
let's
get
started.
As
you
know,
these
are
the
monthly
calls.
You
know
we
always
upload
all
of
these
to
YouTube,
so
I'm
gonna
be
sharing
in
the
chat
and
in
the
show
notes
a
link
or
to
our
YouTube
channel,
where
you
can
check
previous
recordings.
A
If
you
haven't
attended
those
in
the
past
and
there's
a
a
public
website
there
that
that's
the
core
depths
workspace,
we
have
it
it's
a
it's
an
ocean
page.
You
can
check
all
of
these.
During
going
to
the
graph.f
foundation,
you
can
subscribe
to
our
ecosystem
calendar
and
you
know
be
in
the
loop
about
future
workshops
and
other
core
devs
talks
we'll
be
having
and
also
get
access
to
the
cortex
workspace.
That
is
where
we
have
the
multiple
working
groups.
A
A
Let's
get
started
with
just
a
very
quick
update
on
the
mips
program.
As
you
know,
this
has
been
announced
a
couple
weeks
ago.
I
did
cover
it
in
a
in
a
in
a
pretty
previous
core
devs
call.
I,
don't
want
to
get
into
them
into
much
detail
today,
because
we
we've
already
kind
of
covered
what
what
it
is
in
a
nutshell.
A
It's
the
program
that
the
foundation
come
structured
and
you
know
we've
kick-started
it
one
week
ago,
where
it
will
have
multiple
chains
on
this
test
net,
and
you
know
just
making
sure
that
we
can,
in
due
time
once
you
have
the
proper
quality
of
service
migrate,
those
chains
to
the
network,
and
so
that
means
that
we're
ramping
up
with
new
indexers
that
are
helping
us
getting
getting
started
and
create
some
supply
for
those
for
those
for
those
chains.
And
so,
if
you've
been
around
it's
similar
to
the
mission
control.
A
The
first
incentivized
testnet
we've
launched
two
years
ago,
and
so
this
is
a
great
opportunity
for
indexers
to
get
started
and
join
us
and
serve
new
chains
like
noses
chain.
That
was
the
first
one
announced
and
it's
already
live.
We
started
the
phase
zero.
The
program
has
started
as
I
said.
The
agreement
has
been
sent.
A
Please
do
assign
it
if
you're
participating,
we're
very
happy
to
have
all
of
you
joining
us
and
helping
us
out,
and
it's
a
you
know,
it's
a
it's
a
major
milestone
in
our
in
our
in
for
the
protocol
because,
as
you
know,
we're
all
about
decentralization
and
the
only
way
we
can
get
there
is
to
have
more
indexers
joining
our
Network
can
serve
multiple
chains.
So
it's
all
going
well.
Thank
you
for
joining
us.
I
will
be
sharing
also
the
page
to
the
the
link
to
our
new,
our
brand
new
mips
homepage.
A
A
A
We've
been
also
talking
about
it
and
there's
some
updates
here
then
we
can,
you
know,
understand
a
little
bit
better
what
this
is
and
how
developers
can
get
their
hands
on
it,
and
this
is
one
of
the
ways
we
are
one
of
the
things
we
are
working
on,
just
to
make
sure
that
we
can
better
serve
the
nft
community
and
sort
of
use
cases,
so
that's
fairly
exciting,
and
then
we
have
sub
graphs
data
pruning
as
well
Adam.
Thank
you.
This
is
fairly
important
for
subgraph
developers.
Obviously
we'll
get
to
know
more
then.
A
As
you
know,
one
major
upca
update
we're
bringing
to
the
protocol
and
the
network
is
the
migration
to
L2,
specifically
Arbitron.
This
has
been
covered
in
the
past.
We've
covered
Gip,
34
and
I
believe
31
before,
and
so
today,
it's
all
about
grp37,
that's
in
the
Forum
I'll
post,
a
link
to
it
as
well
and
Pablo
from
aginode
will
be
talking
about
this
as
well.
A
Then
we'll
have
our
going
through
curation
V1
and
what
it
means
to
you
know.
What
are
we
thinking
about
when
you're
thinking
of
overhauling
duration
and
and
and
the
recent
efforts
on
improving
the
overall
developer
experience
the
whole
user
experience
making
it
super
seamless,
that's
a
big
big
topic
right
right
now
and
so
how
it
will
go
through
some
of
these
initial
details
and
in
a
in
in
the
future
in
the
future
core
devs
called
in
a
month
from
from
now
we'll
go
even
deeper
here.
A
So
do
subscribe
or
do
do
do
do
follow
our
updates,
it's
fairly
important
and
then
we're
going
to
wrap
up
with
the
kind
of
a
brainstorm
on
bringing
substreams
to
the
network.
That's
something
that's
fairly
new
we've!
Just
you
know.
We
just
started
having
this
conversation
as
part
of
the
that
an
api's
working
group,
and
so
we
can
take
the
time
today
to
continue
this
discussion
and
and
I.
Think
it's
a
nice
way
to
finish.
A
Today's
call
and
that's
going
to
be
led
mostly
by
Adam,
Alex
and
streaming
from
streaming
fast,
but
obviously
all
other
core
devs
can
be
should
can
and
should
participate,
but
specifically
the
or
the
the
folks
from
the
index
of
experienced
working
groups
and
other
indexes.
We
have
joining
us
so
yeah,
that's
it.
Let's.
Let
me
pause
here.
I'll,
stop
sharing
my
screen
and
Adam.
Are
you
around
and
ready.
B
B
B
That
will
that
the
protocol
is
also
moving
towards.
So
the
current
status
of
holiday
sources
is
or
ipfs,
data
sources
is
that
they
aren't
are
not
deterministic,
because
essentially,
you
may
not
be
able
to
get
a
file
back
from
ipfs.
Anyone
who
has
used
ipfs
in
production
has
probably
encountered
some
headaches
when
it
comes
to
finding
data
on
the
network,
and
so
this
initial
release
isn't
getting
us
all
the
way
there.
But
it's
essentially
doing
a
lot
of
great
groundwork
to
take
us
or
allow
us
to
move
in
that
direction.
B
Theo
from
Legends
who's
also
been
working
on
this
and,
of
course,
Zach
Zach's
also
been
very
involved
in
someone
thinking
on
on
how
we
moved
to
determinism
in
the
future,
and
so
yeah
so
with
without
further
I
suppose
to
do
I
just
want
to
I
guess,
give
folks
a
sense
of
the
change,
the
change
that
we're
currently
working
on,
where
we're
currently
at
in
the
rollout
of
that.
So
if
you
take
oh,
that's
a
good
start.
B
B
So
essentially
that
will
be
reaching
out
to
try
and
find
a
given
file
for
my
BFS
it'll
fetch
it
then,
then
it
might
succeed.
The
file
might
be
returned.
You
can
then
sort
of
process
the
data
in
that
file,
or
it
might
be
that,
for
whatever
reason
your
ipfs
node
isn't
able
to
find
that
file.
It
might
not
be
available.
It
might
not
appear
in
time,
but
essentially
you
can
have
for
success
or
failure.
B
This
then
leads
so
naturally
to
determinism,
because
if
one
indexer
successful
one
fails,
then
the
resulting
right
to
the
store
will
provide
different
data.
You'll
have
different
results
and
also
it
means,
in
the
case
of
failure
that
if
there
was
really
useful
like
important
information
in
that
file,
that
that
was
going
to
be
useful
or
important
to
users
when
they
came
to
query,
query
the
store
and
query
the
sub
graph.
B
If
you've
got
an
art
platform
where
essentially
the
file
is
uploaded
loaded
to
open
the
best
around
the
same
time
that
the
on-chain
transaction
happens,
then
it
can
be
that
essentially,
the
transaction
happens
before
the
file
is
then
found
and
then
essentially,
you've
got
a
subgraph
that
doesn't
have
a
pointer
to
the
actual
important
message
data
about
in
with
information
about
the
Arts.
So
it
has
problems
in
that
you've
got
this
sort
of
Blended
success.
Failure
non-determinism
you've
also
got
this
one
done
like
lack
of
robustness.
So
it's
it's.
B
So
that
gives
you
some
robustness.
It
means
that
if
you
don't
find
it
the
first
time,
maybe
because
of
that
kind
of
race
condition,
you've
got
another
chance.
So
you
can
provide
that
useful
API
to
people,
but
then,
crucially,
because
it's
a
different
data
source
you've
got
these
sort
of
two
separate
rights.
B
So
this
is
currently
in
terms
of
where
it's
at
we're
in
testing
of
this.
So
there
are
a
few
nuanced
things
around
like
finding
files
and
directories
which
Felipe
has
been
working
on,
just
to
make
sure
that
we
match
the
same
sort
of
I,
guess
functionality
that
we
have
here,
but
just
with
more
robustness.
B
So
yes,
I'm
moving
to
supporting
directories,
you
could
have
file
data
sources
which
are
indexing,
our
weave,
which
are
indexing
ceramic
and
then,
maybe
even
in
future.
These
non-deterministic
or
variable
things
like
ipns
or
even
HTTP
endpoints
could
be
file
data
sources
which
could
then
be
in
a
certain
way.
So
that's
obviously
a
huge
like
going
to
be
a
hugely
important
development
as
we
move
towards
supporting
nft
use
cases
which
obviously
can
be
found
in
our
weave
and
often
and
HTTP
endpoints
for
all
sorts
of
various
reasons.
B
B
It
introduces
some
constraints,
there's
a
Limited
store
access
to
the
file
file
handlers
and
they
need
to
be
separate
entities
various
ways.
But
thankfully,
some
of
the
other
features
that
we've
been
working
on.
All
the
Guild
in
particular,
have
been
working
on
nested
filters
and
those
kind
of
things
which
actually
mean
that
having
separate
entities
or
like
child
entities
of
of
primary
entities
isn't
so
much
of
a
problem
because
you
can
filter
and
you
can
sort
by
those
by
the
features
of
those
entities.
B
A
B
A
B
B
If
you
want
real
data
freshness
and
those
kind
of
things,
I
think
there
is
a
really
interesting
space
for
indexes
kind
of
being
on
the
hook
to
like
help
other
index
file
indexes
find
files
potentially
where,
if
you've,
essentially
attested
to
results,
including
a
given
file.
Another
indexer
can't
find
out
on
ipfs
for
whatever
reason
like
having
some
kind
of
means
of
encouraging
indexes
to
share
data
with
one
another,
because
one
big
problem,
obviously
with
nfts
is,
is
the
problem
of
files
just
disappearing
from
ipfs.
B
Then
the
nft
is
not
there
at
all.
There
aren't
that
many
actual
incentive
or
mechanisms
for
keeping
files
around
I
think
there
is
a
really
interesting
design
space
there
and
then
like
I,
guess
the
mechanism
which
hasn't
been
explored
or
like
thoroughly
looked
into
so
much
as
the
like,
because
it
wasn't
sort
of
around
I
guess
the
gossip
Network
as
a
means
of
at
least
coordinating
on
what
files
are
not
available
and
who
has
different
ones
and
I.
B
B
Yeah,
yes,
perfect,
move
seamlessly
I
guess
on
to
so
about
pruning.
So
this
is
another
functionality
which
is
kind
of
in
the
same
spot.
So
I'll
get
the
same
context
again.
It's
been
great
work
by
by
David
from
actually
note
who's
been
working
on
pruning,
subgraphs,
so
essentially
spokesma
again
may
or
may
not
know.
A
subgraph
is
kind
of
archival
by
default,
which
is
to
say
that
it
keeps
a
history
of
all
of
its
state.
B
So
from
the
first
block
when
it
started
indexing
to
the
most
recent
block,
you
can
essentially
query
that
subgraph
for
information
at
any
of
those
blocks,
which
is
gives
you
a
really
rich
access
to
historical
data.
It's
it's
crucial
for
for
arbitration
on
the
network,
because
you'll
need
to
be
able
to
go
back
and
query
and
check
for
essentially
this,
like
the
subgraph
stay
at
the
same
block
between
different
indexes.
B
It's
also
the
case
that
a
lot
of
subgraphs
are
keeping
a
lot
of
history
that
actually
is
never
queried
and
they've
run
some
analysis
to
see
when
most
queries
are
relative
to
the
chain
head
and
actually,
obviously,
a
huge
majority
of
people
are
just
querying
for
the
data
at
the
chain
head
rather
than
historical
data
and
so
like
otherwise,
it's
relevant.
Why
is
this
important?
Essentially,
it
means
that
it
can
slow
down
indexing.
B
Some
of
their
queries
can
be
very
slow
essentially
because
they've
got
so
much
historical
data
and
so
pruning
is
a
feature.
That's
designed
that's
been
aiming
to
in
a
specific
case
like
like.
Essentially,
let
people
remove
some
segment
of
History,
not
all
for
the
reasons
I
said
around
arbitration
or
around
around
handling
reops,
but
some
so
I
actually
point
to
the
to
the
pr
here,
which
I
think
is
quite
kind
of
quite
descriptive,
but
essentially
graphman
prunes.
B
This
is
an
index
of
control
at
the
moment,
but
essentially
indexer
an
indexer
can
choose
to
prune
a
given,
subgraph
or
other
deployment
and
essentially
remove
state
from
a
certain
number
of
blocks
default.
10
000,
before
the
current
subgraph
head
and
after
pruning,
the
deployment
can
only
be
queried
at
block
numbers,
at
least
as
high
as
that
blog
that
block.
So
when
you
query,
you
get
a
bunch
of
information
back
so
again.
B
This
is
kind
of
interesting
to
see
in
like
for
a
given
subgraph
the
number
of
sort
of
historical
versions,
so
like
uni,
swap
as
an
example
has
datas,
maybe
1300
days
plus
you've
nearly
got
1.4
million
versions,
so
you've
got
a
lot
of
you've
got
like
the
ratio
here
gives
you
a
sense
of
how
many
actual
like
how
much
actual
recent
current
state
you've
got
versus
historical
State,
but
essentially
this
this
prints
out.
This
pruning
took
553
seconds
I.
C
B
Database
of
sort
of
60
cell
grass
shrank
by
about
a
third
with
some
sort
of
grass
being
reduced
by
90.
So
this
is
functionality
that
isn't
necessarily
applicable
to
all
cell
graphs,
but
can
like
make
material
differences
in
terms
of
storage
size
but
then,
more
importantly,
Cruise
speed
for
drivers.
In
terms
of
where
this
is
at,
like,
as
I
said,
it
gives
you
faster
queries,
it
gives
you
smaller
data
sets.
There
are
some
drawbacks
in
that
you
get
limited
time,
travel
queries.
B
You
also
lose
the
ability
to
graft
before
the
point
where
you
pruned,
but
I
guess
we're
like
it's
going
to
be
pretty
important
in
terms
of
speeding
up
queries
and
yeah.
Essentially
it's
to
the
point
now
where
David's
been
testing
with
Vincent
from
asari
on
yeah,
seeing
what
the
impact
is
in
terms
of
like
then,
depending
on
that
impact.
There's
some
sort
of
developments
here.
One
is
a
split
history
approach
which
would
kind
of
give
you
the
benefits
of
pruning
without
actually
throwing
away
all
that
historical
State.
B
So
there's
a
question
as
to
whether
that's
going
to
be
a
good
approach,
then
there's
also
this
question
of
what
should
be
configured
by
the
developer
versus
the
indexer,
and
so
sometimes
developers
might
want
to
say,
look
action,
but
I
don't
care
about
historical,
so
you
can
throw
it
away.
I'll
always
query
for
most
recent
recent
State
and
developers
will
want
that
level
of
control.
At
the
moment,
as
I
said,
it's
just
an
index
of
control.
B
Yes,
so
we've
talked
to
Theo
about
this
I
can't
remember,
if
that's
so
so
there
have
been
some
updates
to
the
indexing
status
API,
which
I
think
do
essentially
reflect
the
changes
when
you
prune
to
like
the
start
block
that
that
the
subgraph
can
be
queried
for
I'll
need
to
check,
and
just
so
this
isn't
yet
live
on.
The
network.
I'll
need
to
check
with
Gateway
team,
because
they're
like
I,
think
there
was
maybe
a
change.
B
They'd
need
to
essentially
I
like
account
for
that,
so
it
would
then
know
there's
an
indexes
in
the
same
way
that
it
checks
for
where
they
are
at
the
chain
head.
I.
Think
the
other
side
of
the
question
around
proof
of
indexing
proof
of
indexing
is
unchanged
by
this.
It's
generated
at
sort
of
indexing
time
as
you
process
blocks,
so
it's
not
dependent
on
because
essentially
it's
like
a
digest
block
by
block.
It
doesn't
matter.
B
What's
in
the
database
at
a
given
moment,
like
the
proof
indexing
themselves,
they
won't
be
purged
from
the
blocks
from
history.
It
will
just
be
be
the
state,
so
you
would
be
if
you
wanted
to
rewind.
Actually,
that
was
another
thing
out
that
you
can't
do
you
can
rewind
Beyond,
where
you
started
pruning
and
re-index
and
see
so
some
changes
or
whatever,
but
but
yeah
prefer
indexing
should
be
unaffected.
A
Jim,
the
Gateway
does
not
yet
support
these
queries
or
I've
looked
queries
for
print
state.
So
if
you
prune-
and
someone
makes
a
a
query,
you
might
end
up
being
penalized
because
we'll
think
that
your
indexer
is
down
so
but
I
think
we
can
prioritize
that
change.
I
didn't
know
that
this
was
going
to
be
announced
yet.
B
A
No
problem,
Jim,
I,
think
I.
Think
that's.
Basically.
The
conversation
has
answered
my
question,
but
you
know
my
question
was
going
to
be
sort
of
there's.
You
know
you
would
need
to
have
synced
the
entire.
Let's
say
it's
a
big,
complex,
subgraph,
not
UNICEF
whatever
you
would
need
need
to
think
the
whole
thing
anyway
to
to
get
your
pois
prior
to
deciding
to
prune
right.
So
you
know
the
whole
POI
Doctrine
stays
in
place.
The
other
thing
I
just
wanted
to
comment.
I
think
this
is
awesome.
A
The
idea
that
you
know
the
idea
that
immediately
comes
to
mind
for
me
is
just
thinking
from
an
index's
point
of
view.
Is
it
opens
up
possibly
a
different
class
of
indexer
like
a
super
lean
type
of
operation
where
you're
offering
you
know
you're
getting
yourself
very
close
to
like
New
York
data,
centers
or
whatever,
wherever
you
need
to
be
to
be
ultra
low
latency,
but
you're
also
super
low
footprint
right,
because
a
lot
of
indexers
cost
it's
all
about.
It's
not
not
so
much
about
compute.
A
It's
about
Storage
storage
costs,
I
mean
it's
just
it's
off
the
charts.
How
much
we
have
to
pay
for
storage,
so
the
idea
that
you
could
potentially
run
you
know
an
indexer,
that's
very
lean,
but
very
low
latency,
you
know
is
very
appealing.
I
think
it's
very
interesting
thing
to
to
sort
of
think
more
about.
B
A
B
Think
it'll
be
interesting
to
see
different
indexes,
sort
of
and
I
think
there'll
be
more
and
more
of
this,
as
than
the
range
of
potential
infrastructure
like
we
haven't
gotten
or
talked
yet
about
like
when
index
could
be
running
five
houses
or
some
streams,
or
maybe
touch
on
that
at
the
end.
But
it'll
get
get
from
being
like
you,
everyone's
running
the
same
thing
to
maybe
index
is
making
slightly
more
strategic
choices
about
what
kind
of
index
that
they
would
like
to
be,
which
I
think
would
be
really
interesting.
A
D
A
B
D
D
So,
first,
what
what's
the
plan
for
the
L2
scaling
they're
moving
to
moving
the
protocol
to
arbitrum?
There
is
three
stages,
so
right
now
we're
before
starting
stage
one.
The
first
thing
that
we
want
to
do
is
we
want
to
deploy
a
bridge
so
that
users
can
move
graph,
the
graph
token
from
Main
ethereum
to
arbitrum
and
and
that's
the
thing
we're
working
on
right
now.
The
code
for
the
bridge
is
pretty
much
ready.
It's
been
audited.
D
D
We
need
to
figure
out
how
we
distribute
inductor
rewards
on
O2,
because
right
now
the
token
is
minted
on
a
one
and
then
we
have
to
figure
out
like
two
women
tokens,
you
know
two:
do
we
send
tokens
from
a
one
two
or
two?
How
do
we
sort
that
token
issuance
problem
once
we
move
to
to
our
bedroom
and
then
finally
stage
three
is
we
have
a
protocol
working?
We
can
actually
distribute
rewards
in
a
1.02.
D
So
that's
going
to
be
kind
of
a
later
stage
right
now.
Our
main
focus
is
stage
one
and
stage
two.
That
is,
we
want
to
get
that
bridge
deployed
to
mainnet
as
soon
as
possible,
and
then
we
want
to
get
the
rewards
problem
solved
so
that
we
can
enable
index
reward
Channel
2
as
soon
as
possible
as
well.
So
just
a
recap
of
what
stage
one
looks
like
is:
we
have
a
bridge
that
bridge
is
a
couple
of
contracts
on
L1
and
O2
and
it
uses
the
arbitrum
ethereum
bridge.
D
That
is
something
provided
by
arbit
room.
So
when
people
want
to
move
tokens
from
a
one
two
or
two,
they
put
them
in
Bridge
escrow
by
calling
the
L1
graph
token
Gateway,
and
that
triggers
minting
those
tokens.
You
know
too
and
then,
when
people
want
to
move
sorry
tokens
from
l2201,
they
send
those
tokens
to
the
Token
Gateway,
which
will
burn
them,
and
this
will
trigger
a
transactional.
D
One
I
mean
someone
needs
to
trigger
it
after
the
dispute
period
is
over
seven
days
later,
so
that
those
tokens
Can
then
be
sent
from
the
escrow
pack
to
the
the
user.
At
the
user's
address
in
all
one,
which
could
also
be
a
contract
so
updates
on
this
particular
part
of
this
particular
stage.
Jp31
we
have
the
bridge
implementation,
it
was
shot
at
it.
D
There
were
no
surprises
during
the
audit,
a
couple
issues
that
were
solved
after
the
audit,
so
we
we
have
like
a
pretty
robust
implementation
and
we've
tested
it
on
test
and
we've
tested
it
on
on
girly
and
everything
girly.
So
so
we
know
that
this
average
works,
that
you
can
send
tokens
back
and
forth.
D
There's
some
recent
updates
that
is
this
week
we
figured
out.
We
can
make
the
call
hooks
interface
safer
and
for
those
that
haven't
seen
this
or
don't
remember
part
of
the
benefits
of
this
bridge
is
we
can
send
tokens
with
data
atomically.
So
for
some
of
the
migration
helpers
and
some
other
things
that
require
communication
between
a
one
and
two.
We
sometimes
want
to
send
some
tokens
and
then
send
some
cool
data
together
with
the
tokens
so
that
some
behavior
is
triggered.
D
You
know
two
when
those
tokens
arrived
and
that
used
to
be
just
where
we
have
a
wide
list
of
who
can
send
core
hooks
like
this
and
that
used
to
Simply
Be
for
the
destination
address,
with
whatever
call
data
was
passed
by
the
sender,
so
we're
just
making
that
safer
by
making
that
a
fixed
function
interface.
So
whenever
someone
sends
a
cohook,
it
will
always
pull
a
function
called
on
token
transfer
with
some
specific
parameters.
D
So
that's
going
to
make
it
say
for
from
re-entrancy
risks
or
just
the
idea
that,
like
if
you're
in
you
end
up
calling
an
untrusted
contract,
there's
at
least
some
structure
behind
it,
and
you
just
you
can't
just
do
whatever
you
want.
So
I'm
gonna
push
an
update
for
jp31
very,
very
soon,
I'm,
actually
working
on
writing
that
today
and
then
other
than
that.
D
Other
teams
are
already
working
on
quality
of
chain
components
like
the
graph,
Studio
UI
index
rate
and
there's
a
bunch
of
other
things
that
go
around.
Deploying
the
bridge
and
deploying
the
L2,
Network
and
yeah
I
can
go
into
detail
on
those
things,
but
just
know
that
it's
been.
It's
been
working
worked
on
and
then
that's
what
the
actual
code
for
for
the
bridge
contracts,
as
I
mentioned,
the
audit
was
completed,
but
we
we
have.
D
We
want
to
get
even
more
confidence
on
this
code,
so
we're
working
on
setting
up
setting
up
a
code,
Arena
contest
and
for
those
who
aren't
familiar.
This
is
the
a
sort
of
decentralized
audit
where
a
certified
wardens
anyone
can
be
done,
become
a
certified
Warden
and
you
can
participate
in
auditing
the
code
for
a
bounty
so
keep
an
eye
out
for
that.
That's
still
not
not
set
up
completely,
but
we're
working
on
that.
D
So,
if
you're
awarded
or
if
you
want
to
be
a
warden
yeah,
this
might
be
a
good
opportunity
to
get
involved
with
looking
at
this
code
and
helping
to
make
it
secure
so
moving
on
to
stage
two.
So
once
we
once
we
have,
this
quote
Arena
contest
finished
and
we're
we
can
get
the
council
to
approve
the
transactions
we'll
be
able
to
actually
deploy
this
bridge
and
the
ultra
Network
without
index
rewards
and
for
stage
two.
We
want
to
enable
these
rewards.
D
Previously
we
had
presented
jp34-
and
this
is
just
a
brief
recap
of
the
main
idea
behind
that
is,
that
is,
we
want
to
be
able
to
send
all
of
the
tokens
for
index
rewards
from
a
one
to
L2,
so
that
there
is
no
minting
nl2
and-
and
this
requires
adding
a
reservoir
and
a
one
and
a
reservoir
L2,
and
then
the
rewards
would
be
distributed
from
this
Reservoir
instead
of
minted.
Whenever
another
location
is
closed
and
we
have
the
intimidation
for
that,
it's
been
audited
as
well.
D
There
is
a
system
for
a
keeper
reward
that
incentivizes
people
calling
this
drip
function
that
generates
all
of
the
rewards
for
the
upcoming
week,
and
we
think
this
would
work
the
problem.
Is.
It
ended
up
being
quite
complex.
It's
a
lot
of
lines
of
code,
this
system
for
sending
messages
between
L1
and
L2.
D
It
works,
it's
I
mean
supported
by
arbitrum
and
everything,
but
doing
that
in
a
permissionless
way
or
in
a
in
a
decentralized
way
where
anyone
can
call
that
function,
which
is
kind
of
difficult,
it's
difficult
to
ensure
that
this
works
correctly
and
that
there's
no
briefing
going
on
and
things
like
that.
So
yeah,
it's
a
it's
a
tricky
setup
and
while
we
still
think
this
could
work
it
made
us
think,
can
we
have
other
Alternatives
and
then
we
had
Ariel's
idea.
D
What
happens
if
we
make
index
rewards
linear
instead
of
the
current
compound
interest
formula,
and
then
we
just
mint
Terminal
Two.
So
we
ended
up
actually
implementing
this,
and
this
is
jp37
that
is
now
competing
with
tap-34.
So
for
this
stage
2
we
can
have
option
A.
That
is
mint
everything
in
L1
and
send
part
of
it
to
a
2
for
jp37.
That
is
mint.
D
Dl2
rewards
directly
now
to
Min
dl1
rewards
directly
in
L1
and
then
just
make
it
so
that
it's
easier
to
to
know
how
much
of
the
tokens
have
been
minted
in
L2,
so
that
if
someone
wants
to
bridge
those
new
minted
tokens
from
l2201,
the
bridge
is
still
able
to
Mint
them.
But
it
has
a
clear
boundary
of
how
much
how
many
tokens
it
can
make,
because
you
can't
ever
have
more
than
x
amount
of
tokens
that
have
been
minted
onto
so.
D
If
you
want
to
look
into
this
in
detail,
there's
the
Forum
link
here
so
there's
a
forum
thread
with
cap37
I
I
really
encourage
people
to
take
a
look
at
it
provide
feedback.
If
you
can
find
any
potential
issues
with
that
or
if
you
can
provide
a
an
opinion
on
whether
JP,
34
or
37
is
a
better
path
forward
photograph
because
yeah
both
of
these
could
work.
Lately,
we've
been
leaning
towards
kp37
because
it's
really
a
lot
less
code.
It's
a
lot
cleaner.
D
It
looks
a
lot
simpler
and
we
really
think
it.
It
makes
the
system
more
robust,
because
we've
removed
that
L1
to
L2
communication
completely.
At
least
for
indexer
rewards,
so
the
way
rewards
would
be
issued
and
distributed
is
simply
replicating
whatever
we
have
now
in
L1.
That
is
you
close
on
a
location
and
the
rewards
manager
means
some
new
tokens.
We
have
the
same
thing
in
L2
right
now.
D
This
is
part
like
something
that
we
have
implemented
in
that
rewards
manager
contract.
It
simplifies
from
this
exponential
formula
to
the
linear
formula
and
it
makes
everything
a
lot
easier
to
handle
in
the
code,
so
yeah
I
think
yeah,
that's
what
I
have
and
maybe
we're
gonna
have
questions
at
the
end.
If
anyone
has
questions
but
yeah,
the
the
main
thing
is,
if
you
folks
want
to
look
at
these
JPS
and
comments
and
get
involved,
that
would
be
great,
so
yeah.
Thank
you.
A
Thanks
Pablo
yeah.
Indeed,
we
should
try
to
book
the
Q
a
to
the
end,
we're
we're
behind
schedule.
Thank
you.
So
much
I
know
Jim
would
probably
want
to
say.
Please
go
go
to
The
Forum
and
do
comments
on
this
and
give
your
feedback.
That's
that's
important
yeah.
It
is
comment.
Given
the
number
of
green
Jacks,
a
simple
approach
with
smaller
attack.
Surface
areas
seems
to
prevent
and
I
would
have
to
agree,
yeah.
A
A
C
Yep,
okay,
you
can
hear
me
fine,
yep,
okay,
cool,
then
I
will
Jump
On
In
so
this
morning,
I'm
giving
a
little
bit
of
an
update
on
the
curation
side
of
the
protocol
and
really
what
we're
trying
to
do
here
is
give
an
update
to
what's
currently
being
used,
and
so
we're
going
to
call
this
duration
1.x.
It's
not
a
full-scale.
C
C
Curves
I'll
give
a
specific
example
with
an
illustration
on
the
next
slide,
but
I
want
to
highlight
some
of
the
concepts
here
that
have,
you
know,
come
up
with
various
interviews
with
curators
and
others,
and
one
of
the
biggest
things
we
see
now
is
the
complaints
about
things
like
rug
pulling,
because
you
might
provide
some
level
of
signal
on
a
sub
graph
and
come
the
next
day.
You
might
show
up
and
look
and
say,
wait,
there's
only
let's
say
3000grtf
signal
and
I
put
in
5
000..
Why
am
I?
C
Now,
when
I
say
valuable,
I
mean
this
in
a
sort
of
General
sense,
I'm,
not
saying
just
the
ones
that
get
the
most
query
fees,
the
most
frequent
queries,
because
some
apps
actually
might
be
really
dependent
on
a
particular
subgraph,
but
it
might
not
have
often
or
frequent
queries,
but
it
could
be
critical
infrastructure
and
one
way
or
another.
We
want
curation
to
help
us
be
able
to
find
the
valuable
subgraphs
and
today
that
can
be
difficult.
C
You
know
200
of
the
mind
or
something
like
that,
we're
going
to
try
to
make
it
so
that
it's
more
of
a
Level
Playing
Field
in
that
regard.
Now
there
are
trade-offs
that
we're
making
here,
but
again
we're
emphasizing
that
these
are
just
a
step
in
that
direction
of
trying
to
improve
the
user
experience,
and
we
also
want
to
help
make
sure
that
there
is
some
sort
of
nice
relationship
between
signal
and
the
quality
of
service.
We
want
that
to
be
as
predictable
as
possible
as
we're
moving
to
L2
so
really
The.
C
Proposal
here
is
a
simple
modification
we're
going
to,
in
essence,
just
flatten
the
bonding
curves
and
change.
What
we
presently
have
from
being
something
with
a
slope
to
something
that
looks
more
like
what
we
see
as
a
pool
similar
to
something
like
delegation
and
to
recap,
what
bonding
curves
look
like
is,
as
someone
mints
more
and
more
shares
they're.
Providing
more
signal
on
a
subgraph
in
the
little
area
in
any
particular
region
of
this
is
telling
us.
You
know
one,
how
many
shares
someone
has
and
what
price
they're
entitled
to
so.
C
This
is
a
very
simple
update
in
the
here.
This
is
saying:
hey.
We
have
a
particular
slope
that
might
be
changing
by
subgraph,
whereas
if
we
just
make
it
a
flat
bonding
curve,
it's
actually
the
equivalent
of
a
pool.
So
now
we
can
sort
of
eliminate
the
Notions
of
bonding
curves
from
our
ideas
from
our
you
know,
ideas
of
curation
and
so
tentatively,
what
we're
going
to
do
is
we're
going
to
provide
a
proposal
on
the
Forum.
This
is
essentially
drafted.
A
I
don't
see
anyone
raising
their
hands
right
now
and
we
are
very
very
short
on
time.
So
we
may
not
be
able
to
have
at
least
a
meaningful
discussion
around
this
last
topic
of
having
substreams
powered
sub
graphs
on
the
network,
but
I
think
yeah
I'm
not
seeing
any
resend.
So
maybe
we
can
kick
start
that
conversation
I
see
Alex
I
looked
okay,
yeah.
C
B
C
B
So
there's
then
like
how
we
go
from
that
and
a
hosted
solution
to
bringing
this
onto
the
network
and
I.
Think.
As
long
as
we
feel
confident
in
the
determinism
of
the
solution,
then
then,
then
that
should
hopefully
be
pretty
streamlined,
but
it'll
be
quite
a
big
change
for
indexes,
because
then
that'll
suddenly
be
mean.
They'll
index
will
need
to
be
running
fire
hoses
and
substream
endpoints.
So
there's
quite
a
big
I
guess:
infrastructure
change
as
we
get
to
that
point.
I
don't
know
if
Anton
I
don't
know.
A
Yeah,
sorry,
a
chat
is
disabled.
That's
why
I
could
not?
Yes,
I
could
now
try
the
question
there.
I
have
a
question
about
the
correction
proposal
and
basically
now
at
the
moment
the
queer
Visa
distributed
at
the
moment
when
the
index
error
closes
the
its
allocations,
and
at
this
moment
you
know,
rapid
movement
between
different
subgraphs
is
punchable,
because
you
will
lose
your
shares.
C
Yeah
so
I
mean
maybe
I
had
a
comment
on
here
as
Pablo
kind
of
laid
out.
There's
like
these,
like
three
stages
that
are
being
built
for
L2
and
in
the
initial
stage,
there's
actually
not
intended
to
be
rewards.
You
know
like
it's
first
getting
the
bridge
and
then
we
add
rewards
and
so
on,
and
so
in
the
initial
stages
before
query
fees,
we
plan
to
hopefully
provide
more,
you
know,
updates
and
so
on,
so
that
you
know
more
long-term
solution
can
be.
C
You
know,
brought
to
light
in
and
sort
of
you
know
discussed
with
everyone
more
openly
in
the
forums
and
everything.
But
you
are
completely
right
that
this
is
a
downside
of
you
know.
Having
a
flat
bonding
curve
is
that
people
can
pretty
much
jump
in
right,
just
collect
some
query
fees
and
then
hop
back
out.
But
we're
presently
saying
is
that
this
is
worth
the
trade-off,
given
the
move
to
L2
and
the
lack
of
query
rewards,
but
also
because
it
helps
prevent
these
sort
of
run
on
the
banks
in
these
sort
of
zero.
A
Thanks
Anton
getting
back
to
the
sub
streams
last
minute
we
can.
We
hardly
introduce
the
topic.
I,
don't
think
we'll
have
time,
there's
always
next
time.
Alex
there's
always
the
next
time,
there's
no
shortage
of
things
to
be
working
on
and
there's
so
many
different
things
that
active
at
the
moment.
Yeah.
Let's
move
that
conversation
to
a
later
time,
we're
at
the
top
of
the
hour
and
folks
may
have
other
meetings
right.
So,
let's
Okay
Cohen
has
one
last
question.
A
We
have
one
last
minute:
let's
try
to
answer
Corona's
questions
and
then
we
can
and
then
we
can
all
Hop
Off
thanks
though
Alex
and
Adam
for
joining
the
call
we
can.
We
can
continue
in
other
venues
for
sure
and
next
month
we
can
do
an
update
here
and
continue
the
discussion,
possibly
with
others,
foreign
you're
heading
on
when
you're
you're
up
you
can't
yeah
yeah.
My
question
was
about
the
subgraph
pruning.
A
B
Yes,
I
think
the
scenario
where
documentation
and
guidance
I
guess
is
is
required.
I
think
we
Zach.
We
talked
about
this
on
the
length
of
pruning
a
couple
of
months
ago.
I
think
we
haven't
fully
thought
through
that
the
implication
of
that
on
on
the
network.
It
would
obviously
be
a
bit
of
a
constraint
if
we
need
to
keep
always
have
over
and
keep
things
around
for
the
life
potential
lifetime
of
a
of
which
an
arbitration
could
be
brought.
So
I
think
we'll
need
to
think
on
that.
B
B
Yes,
this
is
a
graph
man.
It's
yeah,
it's
currently
a
graph
main
command,
so
it's
obviously
sort
of
outside
of
the
context
of
the
network.
But
it's
a
reasonable.
It's
a
reasonable
point.
I,
don't
know
if
we
need,
if
we'd
want
to
think
about
changing
the
default
settings
so
see.
The
length
of
any
fault
will
also
then
start
to
vary
by
like
if
it's
a
polygon,
subgraph,
then
epochs
are
different
links
in
terms
of
number
of
number
of
blocks.
B
A
Okay,
as
always
thanks
for
going,
we
are
over
time,
so
we
should
wrap
up
here
amazing
next
time,
we'll
make
make
sure
that
we
have
time
to
cover
everything
or
at
least
balance
the
Q,
a
and
topics
we
want
to
cover.
But
it's
always
great
to
see
people
asking
questions
and
there's
only
so
much
we
can
share
in
a
one-hour
call.
In
the
meantime,
no,
regardless
there's
always
updates
in
the
Forum
feel
free
to
participate
and
join
us
on
Discord
as
well.