►
From YouTube: The Graph | Core Devs Call #20
Description
In Core Devs Call #20, The Graph team discusses updates, features, and protocol changes within the ecosystem, focusing on Arbitrum One migration, exponential query fee rebates, and Substreams. Join the conversation and stay informed about The Graph's progress and improvements.
Timestamps:
00:00 Intro
04:50 L2 Scaling Process
43:30 Substreams GUI Updates
51:18 Substream Based Subgraphs
View the Forum Post and Notes for this call here: https://forum.thegraph.com/t/the-graph-core-dev-call-20/4199
Key GIPs discussed in the call:
GIP-0051: Exponential Query Fee Rebates for Indexers: https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162
GIP-0052: Timeline and requirements to increase rewards in L2: https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193
GIP-0046: L2 Migration Helpers: https://forum.thegraph.com/t/gip-0046-l2-migration-helpers/4023
Follow The Graph on social media:
Twitter: https://twitter.com/graphprotocol
Instagram: https://instagram.com/graphprotocol
LinkedIn: https://www.linkedin.com/company/thegraph
GitHub: https://github.com/graphprotocol
Website: https://thegraph.com
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.
A
A
We
do
want
to
hear
from
you
today
we're
going
to
be
talking
about
a
good
amount
of
important
gips
and
protocol
changes
and
also
I'm
going
to
be
sharing
all
of
the
links
to
The
Forum,
where
these
discussions
are
where
we're
having
all
of
these
discussions.
So
if
you
want
to
follow
up,
async
do
use
the
Forum
to
continue
asking
questions
and
we're
always
on
yeah
Discord
tool.
You
can
you
can
reach
out
and
and
talk
to
us
I
just
noticed
this
is
not
full
screen
yeah.
A
A
Pablo
will
also
talk
about
the
the
dependencies
here
like
the
migration
helpers,
and
then
Ford
will
go
through
the
current
plan
to
ensure
there
no
down
that
there's
no
downtime
when
migrating
sub
graphs
over
the
L2
and
this
move
to
L2
is
a
big
lift
and
it
will
require
some
actions
from
all
stakeholders,
including
not
just
indexers,
but
delegators
curators
and
subgraph
owners
too.
So
do
take
no
task.
Questions
like
I
said
and
get
in
touch
through
the
Forum.
A
If
you
need
some
clarity
or
want
to
provide
any
sort
of
feedback
on
this,
it's
fairly
important
that
you
do
participate
next
and
also
extremely
important.
Is
the
Gip
51
that
one
is
a
proposed
new
exponential
rebate
mechanism
that
is
to
replace
the
current
cop
Douglas
inspired
one
used
in
the
protocol
to
distribute
query
feed
rebates
to
indexers
as
before.
These
two
requires
some
close
coordination
with
different
stakeholders,
particularly
indexers.
So
do
take
notes
and
we'll
be
hearing
from
Howard
one
of
the
Gip
authors,
which
we
will
go
through
the
details
of
these
new
proposal.
A
A
First
one
is
Pablo
yeah.
Thank
you.
Nick
for
sharing.
All
of
these
and
I'll
also
be
sharing
the
the
actual
Forum
posts.
Pablo
I,
believe
you
are
already
a
co-host,
so
you
should
be
able
to
screen
yeah
yeah.
Can
you
hear
me?
Yes,
perfectly.
Okay,
cool
I'm
gonna
share
my
screen.
Can
you
see
this?
Yes,
we
can
thank
you,
okay,
brilliance,
all
right,
so
yeah
as
perro
said
I'm
going
to
be
presenting
some
updates
on
the
L2
scaling
process
how
to
scaling
into
migration.
A
We've
been
doing
this
in
several
stages,
so
we
had
a
long
preparation
phase
where
we
looked
at
how
to
build
this
and
how
to
make
this
happen.
And
then
there
was
a
first
stage
that
was
deploying
the
bridge
on
deploying
BL2
contracts,
and
that
happened.
I
mean
the
bridge
was
deployed
December
last
year
and
then,
throughout
q1
of
this
year,
there's
been
work
on
getting
Explorer
and
studio
and
other,
let's
say,
off-chain
components
to
support
the
SL2
Network.
A
A
Currently,
that's
only
five
percent
of
the
token
issuance.
That
is
happening
on
arbitrum
and
then
95
of
it
is
still
happening
in
ethereum
maintenance.
So,
for
this
to
happen,
we
had
to
change
the
way
Insurance
worked
so
now.
Indexing
rewards
follow
a
linear
formula
instead
of
the
exponential
that
they
use
to
follow,
but
now
we're
we're
moving
on
towards
stage
three.
A
So,
as
I
mentioned,
we've
deployed
the
five
percent
issuance
on
O2
to
maintenance
and
orbital.
One
I
mean
also
to
mainly
because
it's
changed.
The
way
rewards
happen
on
window
two
and
it's
also
reduced
Insurance
on
maintenance
to
95
of
what
it
used
to
be,
and
after
this
happened,
we've
had
a
good
amount
of
people
already
migrating
well,
not
migrating,
but
deploying
new
subgraph
channel
two.
So
we
currently
have
120
subgroups
that
have
been
deployed
to
the
L2
Network,
which
is
pretty
good.
A
Considering
we've
just
started
unders
only
this,
like
smaller
incentive
and
because
of
the
smaller
incentive.
We
also
had
a
fair
amount
of
stake
from
indexers
that
has
moved
202
and
some
delegators
that
have
started
delegating
102
as
well.
So
in
total
that's
about
20
million
GRT,
which
is
still
small,
considering
that
this
is
less
than
five
percent
of
the
stake
that
we
have
I
want.
A
So
it's
still
going
slowly,
but
it's
still
nice
to
see
that
some
participants
are
starting
to
set
up
their
operations
indexes
are
starting
to
set
up
their
operations
and
serving
subgrass
there,
which
is
pretty
cool
to
see.
At
the
same
time,
we've
been
working
on
the
migration
helpers
and
we're
almost
done
with
the
audience
all
of
the
gns,
so
the
subgraph
and
curation
migration
helpers
have
been
audited
already,
and
the
migration
helpers
for
stake
delegation
and
for
vesting
contracts
are
almost
almost
done.
We
had
the
initial
report
from
the
Auditors.
A
We
prepared
the
fixes
for
that
and
we're
just
waiting
for
the
final
report
now,
so
we
still
need
to
do
some
testing
of
all
of
these
contracts,
we're
developing
a
formal
test
plan
and
we're
going
to
be
running
that,
like
we
did
for
the
previous
stages,
but
we're
getting
very
close.
So
hopefully,
in
the
next
few
weeks,
we'll
have
a
contract
site
ready
for
that
and
at
the
same
time,
all
of
the
UI
development
for
the
migration
helpers.
A
A
Okay,
thanks.
Okay,
so,
as
I
said,
UI
development,
for
that
is
ongoing,
it's
quite
a
challenge,
because
it's
it's
not
a
very
easy
flow
to
expose
in
a
way
that
is
easy
to
use
and
then
finally,
we
recently
published
JP
52,
and
this
proposes
increasingly
L2
rewards
in
four
steps.
Until
we
get
to
100
on
all
two
at
the
end
of
this
process,
we
will
have
all
of
the
token
issuance.
All
of
the
indexing
rewards
happening
in.
A
So
a
brief
recap
on
migration
helpers
again
go
to
previous
core
Dev
calls
if
you
want
more
detail
or
check
out
gip46
we're
providing
contracts
and
related
user
interface
to
migrate,
subgraph's
creation
index
or
stake
delegation
and
investing
contracts,
and
this
is
very
important
because
a
lot
of
indexers
and
delegators
are
using
investing
contracts
to
to
stake
or
delegate
and
the
basic
idea
is.
There
is
going
to
be
a
function
on
the
L1
gns
or
the
l1's
taking
contract
that
you
can
call
them.
A
That
will
send
the
state
that
is
related
to
that
participant
to
the
counter
Colonial
two
yeah.
So,
generally,
it's
going
to
be
one
or
two
transactions
that
each
participant
needs
to
do
in
order
to
move
to
O2
and
in
the
case
of
soccer
sanctuation,
the
subgraph
owners
will
migrate
some
graphs
and
then
curators
can
choose
whether
they
want
to
migrate
their
curation
or
and
when
they
want
to
do
it
and
the
same
for
indexing.
A
Indexer,
State
and
delegation
and
index
just
choose
when
to
migrate
their
state
and
they
can
do
it
partially
and
then
deleggers
choose
when
to
migrate
their
delegation
pill
too,
or
if
they
prefer
to
withdraw
level
one
and
then
for
vesting
contracts.
It's
a
bit
trickier,
but
the
vesting
beneficiaries
will
be
able
to
set
up
an
L2
counterpart
of
their
vesting
contract
and
then
use
that
as
their
L2
identity
to
send
their
stake
and
delegation
to
be
owned
by
these
L2
testing
contracts.
A
So
that's
a
general
idea
and
then
for
the
in
a
few
minutes,
we'll
describe
some
improvements
to
the
indexer
stack
to
handle
what
happens
when
a
subgraph
migrates
towards
improvements
for
that
are
happening
on
both
the
Gateway
and
the
indexer
stacks
of
inductory
agent.
So
yeah
we'll
focus
a
bit
more
on
that
so
increasing
reward.
Channel
2,
as
I
said
it's
it's
going
from
five
percent
to
100
in
several
Milestones.
Over
a
few
months.
We
are
setting
migration.
A
The
whole
processor
prerequisite
for
any
increases,
so
it's
currently
at
five
percent,
and
the
first
bump
will
not
happen
before
migration
helpers
for
for
all
of
the
participants
are
released.
We're
going
to
be
monitoring
that
things
go
well
in
each
step
and
we
set
the
timeline
if
anything
goes
wrong
with
the
contracts
in
particular.
But
if
other
things
go
wrong,
of
course,
we'll
be
fixing
and
adjusting
the
timeline
as
needed,
and
there's
going
to
be
an
ongoing
conversation
about
the
requirements
for
each
of
the
steps.
A
We've
already
had
lots
of
great
feedback
on
the
Forum
and
at
the
investor
office
hours
call
and
we're
going
to
be
incorporating
that
into
the
proposal
and
we're
going
to
keep
chatting
about
that
and
try
to
keep
discussing
before
doing
any
of
these
steps
at
least
go
to
an
index
or
office
hours
to
make
sure
that
there's
nothing
weird.
That's,
for
instance,
stopping
indexers
from
from
migrating
or
causing
any
other
issues.
A
So
the
four
steps
first,
one
will
go
from
five
to
twenty
five
percent,
we're
trying
to
aim
for,
let's
say
one
or
two
weeks
after
migration,
whole
percent
released
have
been
released
and
we
will
have
to
validate
that
all
the
participants
can
use
the
helpers
before
actually
doing
the
bump
and
then
not
too
too
much
later
after
that.
So,
let's
say
about
two
weeks
later,
we
would
bump
to
50
after
validating
that
already
some
stock
graphs
have
actually
migrated
and
some
indexers
have
actually
migrated.
A
So
we
have
a
more
Lively
Network
model
too,
and
at
that
point,
there's
going
to
be
a
sort
of
parity
between
a
one
and
O2
and
we're
thinking.
We
should
keep
that
going
for
about
two
months
just
to
to
have
a
more
solid
validation
that
everything's
working
well
and
because
we
before
the
next
jump
that
would
be
for
95.
We
would
hope
that
I
mean
we
will
require
that
a
lot
of
indexers
have
migrated,
and
then
the
qos
102
is
similar
to
1101
and
based
on
feedback
from
indexers.
A
We
would
probably
add
some
requirements
for
delegators
from
you
know
some
amount
of
delegates
to
also
have
migrated
202
so
that
yeah
we
don't
leave
this
participant
behind
and
if
there
are
deleggers
a
little
bit
are
a
bit
slower
to
to
migrate.
We
still
have
a
healthy
amount
of
Delegation
moving
towards
to
before
we
do
this
big
final
bump.
A
Would
kind
of
invert
the
current
state
that
we
have
and
then
we
would
still
keep
that
five
percent
on
a
one
mostly
because
some
subgraph
developers
might
take
a
bit
longer
to
migrate
and
we
don't
want
to
put
them
in
a
position
where
all
of
the
rewards
go
through
O2
very
quickly
and
then
there's
no
more
indexers
there
and
then
there's.
No.
You
can't
query
those
subgraphs
anymore,
so
we
want
to
avoid
that.
A
C
In
order
to
support
this,
the
indexer
agent
will
need
to
be
aware
of
both
Networks
and
we'll
support.
A
combined
strategy
of
allocating
stake
across
both
the
L1
and
L2
on
the
next
slide.
I
have
some
details
around
those
changes:
let's
go
there
next
cool,
so
yeah
in
L1
and
L2
mode,
which
will
be
coming
up
in
the
next
agent.
C
C
C
C
C
C
A
A
To
answer
some
of
these
questions
or
yeah
yeah,
we
can
have
one
two
minutes
and
then
we
can.
We
have
to
move
on
yeah,
but
we
can
answer
simones
and
Mark's
questions
cool
so
to
subgroup.
Tabs
need
to
become
active
to
migrate
tool
too,
not
sure
what
you
mean
by
becoming
active,
but
but
yes
that
so
the
migration
will
not
be
automatic.
Subgraph
tabs
that
want
to
migrate
to
L2
would
have
to
execute
the
transaction
themselves
through
the
Explorer
or
I.
A
Think
Studio
UI
to
do
this
and
then
will
it
support
different
index
addresses
for
L2,
yes
for
all
of
the
migration
helpers,
because
the
participant
one
might
be
using
a
multi-sig
or
a
smart
contract
that
doesn't
exist
on
L2
all
of
the
time.
So
every
single
time
that
you
want
to
do
a
migrate
immigration,
you
have
to
specify
no
two
beneficiary
there's
going
to
be
your
L2
address.
Obviously
you
can't,
which
is
one
for
a
part
of
your
state
and
a
different
one.
For
another
part
of
your
sake.
A
It's
always
the
same
identity,
but
it's
always
you.
You
have
a
choice
to
specify
who
you're
what
your
L2
address
is
in
the
vesting
contracts.
Cases
is
going
to
be
like
Auto
assigned
to
the
L2
Westing
contract
for
an
uninvested
I'm,
not
fully
casted
contract,
but
for
everything
else.
That
L2
address
is
something
that
you
can
set.
A
What
happens
if
they
don't
migrate?
Well,
if,
if
enough
people
don't
have
don't
migrate,
when
we
get
to
that
95
stage,
we
won't
move
forward.
If
there's
a
significant
amount
of
people
that
don't
want
to
migrate
and
then,
if
that
happens,
we'll
have
to
raise
it
and
as
a
community
decide
what
what
are
we
going
to
do?
Are
we
going
to
keep
supporting
our
one
indefinitely
Or?
A
Are
we
going
to
do
something
else,
so
I
think
right
now,
there's
consensus
that
we
want
to
move
to
the
whole
network,
but
if
we
get
to
that
95
station
and
there's
like
a
significant
percentage
of
people
who
don't
want
to
move
202,
then
the
community
will
have
to
visit
and
the
council
will
have
to
decide
how
to
move
forward.
Maybe,
with
a
community
vote
I,
don't
know
we'll
have
to
cross
that
bridge.
When
we
get
there,
the
subgraphs
need
to
be
re-indexed
from
scratch
when
they
migrate
to
two
I.
C
Yeah,
the
idea
with
this
is
that
it's
gonna
be
a
choice
for
indexers,
but
hopefully
we
have
many
indexers
that
will
operate
on
L1
and
L2
in
this
combined
mode.
And
if
you
have
the
subgraph
synced
already
from
L1,
your
index
or
agent
will
simply
need
to
allocate
it
to
it.
On
the
L2
and
you'll
already
have
it
synced
and
you
won't
need
to
to
do
any
work
to
re-sync
or
re-index
the
data
and
that's
important
for
the
the
quick
migration
over
with
no
downtime.
A
A
You
put
in
the
chat
that
yeah
Mark
Andre
was
asking
specifically
about
index
reagent
with
el2
address
and
you
responded.
We
can't
support
that
yeah
great
yeah,
thanks
folks
for
the
questions.
Thank
you
Pablo
and
Ford
yeah.
We
can
continue
in
the
chat
answering
some
questions,
but
we
do
have
to
move
on
with
the
agenda.
So
thanks
again,
Pablo
for
Howard.
Are
you
ready?
You
should
be
yeah
sure?
Okay,
there
you
go.
E
A
E
A
E
Yep
I'll
go
ahead
and
hop
in
so
this
is
a
brief
update
on
some
progress
we've
made
regarding
regarding
query
fee
rebates.
So
to
ask
you
a
jump
slide,
so
here's
a
reference
on
a
couple
of
documents
that
we
think
would
be
helpful
to
read,
namely
there's
Gip
51.
That's
Linked,
In,
The
Forum
there's
been
some
discussion
there,
so
that's
will
be
the
primary
place
to
follow
up
after
regarding
this
update,
and
there
is
some
of
the
code
posted
not
yet
audited
and
slide.
E
E
Okay,
so
this
is
really
oversimplified,
but
essentially
for
anyone.
You
know
in
the
community
is
not
quite
familiar
with
this
concept.
Essentially,
what
happens?
Is
users
pay
for
queries
in
some
fashion,
those
payments
go
into
a
smart
contract.
Indexers
interact
with
that
and
get
some
portion
of
that
as
their
payment
for
serving
a
query.
The
part
that
the
indexers
get
is
called
their
rebate.
So
that
is
what,
whenever
we
say,
index
or
rebase,
you
can
think
the
amount
of
money
the
indexer
is
getting
from
the
query
fees
and
so
in
all
these
slides.
E
So
just
you
know
glossing
over
this
a
bit,
but
essentially
the
importance
here
is
we're
interested
in
this,
because
we
want
there
to
be
a
lot
of
query
fees
in
the
network
and
when
that
happens,
we
expect
that
the
rebates
will
be
a
substantial
part
of
index
or
revenue,
and
so
we
want
to
make
sure
this
is
sufficient
and
you
know
useful
for
everyone
as
possible,
and
so
that's
just
that
second
point
there.
So
there's
indexing
course
today,
but
then
yeah,
the
rebates
were
the
big
emphasis
for
this.
E
E
Unfortunately,
you
can't
know
what
everyone
else's
decisions
are
going
to
be,
and
so
you
have
uncertainty
in
the
amount
of
GRT
you're
going
to
actually
get
for
serving
any
particular
query,
and
so
you
have
this
uncertainty.
It's
kind
of
complicated
as
far
as
how
you
have
to
reason
about
it.
With
all
these
different.
You
know,
interactions
between
people
and
an
additional
consequence
of
how
it
operates
today.
Is
that
there's
a
lot
of
the
rebate
that
is
burnt
and
when
I
say
burnt
I
mean
as
an
example?
E
If
a
consumer
pays
one
GRT
for
a
query
fee,
maybe
only
0.6
GRT
end
up
to
the
actual
indexer
that
serve
for
the
query.
Maybe
it's
0.65,
but
the
point
is:
there's
actually
a
substantial
percentage
of
query
fees
today
that
are
just
burnt
and
they,
you
know,
essentially
cease
to
exist.
So
the
indexers
are
not
getting
that
and
that
creates
a
point
of
friction
where
either
the
consumers
could
be
paying
slightly
less
or
the
index
is
making
more
or
some
combination
of
the
two
either
way.
E
This
is
causing
a
hindrance
to
the
ability
of
indexers
to
make
you
know
a
profit
from
serving
queries,
and
so
we
can
think
of
the
Cobb
Douglas
inspired
form
of
rebates
right
now,
it's
it's
kind
of
complicated,
it's
kind
of
opaque
to
a
lot
of
indexers.
You
know,
as
far
as
like
trying
to
explain
how
the
different
pieces
work
and
trying
to
predict
things
and
also
importantly,
it's
inefficient,
and
what
we'd
like
to
do
is
switch
to
something.
That's
simple,
so
that
you
know
we
can
explain
it.
Clearly,
people
can
get
the
concept
it's
intuitive.
E
They
maybe,
for
example,
don't
have
a
lot
of
uncertainty
and
then
it's
efficient,
meaning
that
there's
not
a
lot
of
query
fees
being
thrown
away.
It's
really
just
going
directly
from
the
consumers
to
the
indexers
as
much
as
possible.
There
are
additional
concerns,
or
you
know
things
that
we
need
to
do
to
ensure
the
security
of
the
protocol,
but
we
want
to
make
it
as
streamlined
as
possible
for
everyone,
and
so
that's
the
the
real
emphasis
of
what
we're
trying
to
do
with
this
change
and
slide.
E
So
this
is
the
the
one
mathie
type
slide
and
essentially
there's
two,
let's
say
magic
numbers
or
protocol
parameters,
and
if
I
am
looking
at
a
particular
subgraph
as
an
indexer
and
I
need
to
figure
out
how
much
am
I
going
to
get
rebated
for
serving
queries
on
that
subgraph.
The
formulas
like
what
we
see
here
on
the
top
right
so
R
sub.
I
j
that
stands
for
the
rebate
the
I
indexer
gets
for
serving
on
the
jth
subgraph
and
the
Q
sub.
E
E
Essentially,
what
it's
saying
is
that
if
you
stake
a
lot
relative
to
your
queries
that
are
being
served,
you'll
get
essentially
all
of
the
queries.
This
number,
in
parentheses,
will
essentially
be
one
when
you
have
a
lot
of
stake
relative
to
the
amount
of
queries
are
being
served,
and
so
you
know,
if
query
fee
is
sufficient
sufficiently
large.
This
is
essentially
going
to
encourage
indexers
to
stake
in
proportion
to
the
query
fees.
E
Now,
that's
ignoring
indexing
rewards
for
the
moment,
but
just
think
about
this
as
we're
you
know,
moving
forward
with
the
evolution
of
you,
know
the
graph
and
so
right
now
this
formula
that
you
you
see
only
has
the
particular
indexers
query
fees
and
stake
involved,
so
this
indexer
now
can
say
well
how
much
am
I
sticking,
how
many
query
fees
am
I
serving
okay,
this
is
exactly
I
can
compute.
With
this.
E
Now.
What
we'll
talk
about
is
the
stake
ratio
in
this
fourth
bullet
point,
you
see
S
Sub,
I
j
over
Q
sub.
I
j.
That's
the
amount
that
you
are
staking
relative
to
the
amount
of
query
fees
you're
serving
essentially
everyone
in
the
graph
today,
as
far
as
indexers
go,
have
a
very
large
stake
ratio.
As
far
as
this
formula
is
concerned,
okay,
let's
go
to
the
next
slide
and
try
to
make
this
a
little
more
concrete
yeah.
So
here's
what
that
curve
looks
like
that
formula.
E
If
you,
as
you
increase
the
stake
ratio
what's
going
on,
is
that
you're
getting
a
larger
and
larger
proportion
of
your
query
fees?
So
if
you
have
a
stake
ratio
of,
let's
say,
10
you're,
essentially
going
to
get
almost
100.
It's
like
99
point
something
it'll
be
more
clear
in
the
next
slide,
but
the
goal
here
is
to
encourage
people
you
know
to
stake
for,
for
you
know
we
need
it
for
collateral
and
such
for
security,
and
so
this
is
what
it's
going
to
look
like
intuitively,
for
you
guys
and
slide.
E
Okay,
so
let
me
now
walk
through
one
little
numerical
example:
let's
suppose
that
as
an
indexer
I
serve
100
grts
worth
of
query
fees
as
in
you
know,
someone
paid
that
much
and
it
was
on.
Let's
say
some
random
sub
graph
and
I
had
allocated
a
thousand
GRT
in
that
case,
if
you
go
through
and
plug
in
the
numbers
with
these
tentative
parameters
that
we're
suggesting
in
the
Gip
where
Alphas
one
and
Lambda
is
0.6,
if
you
just
go
down
on
the
left
side,
you
see
this
R
sub.
E
So
this
means
that
if
someone
had
served,
100
grt's
worth
of
queries,
they're
going
to
get
back
all
of
that,
but
0.25,
which
is
a
substantial
improvement
from
today,
where
they
could
be.
You
know
30
or
more
that's
being
burnt,
and
so
that's
hopefully
going
to
make
it
much
more
efficient
for
everybody,
okay
and
slide
foreign.
E
As
far
as
economic
concerns,
Tomas
is
going
to
take
us
over
more
implementation
things,
but
today
you
have
to
get
rebated
based
on
the
network
State,
and
so
this
requires
you
know
using
these
pools
and
interacting
and
thinking
about
how
everyone
else
is
behaving
which
makes
it
just
really
hard
to
think
about
and
how
hard
to
optimize.
You
know
your
decisions
on
how
much
you
know
to
be
staking
on
these
things.
Yeah.
In
addition,
you
don't
know
necessarily
how
much
you're
going
to
be
rebated
and
it's
inefficient.
D
Okay,
thanks
Howard
yeah,
so
I'm
going
to
talk
a
little
bit
more
about
what
this
means
like
in
terms
of
actions
required
for
indexers
and
how
this
impacts
operations
so
far,
Howard
has
covered
like
the
economic
side
and
how
like
we
are
changing
the
formula
so
initially
or
intuitively.
You
could
think
that
the
implementation
for
this
is
like
a
drop-in
replacement.
You
take
the
old
formula.
D
D
Here
on
the
on
this
slide,
you
can
see
on
the
left
side.
It's
the
current
cop
Douglas
rebates
mechanism.
As
you
can
see,
it's
a
a
two-step
process
initially,
once
on
a
location,
is
closed.
The
indexer
software
will
like
redeem
a
voucher
through
the
allocation
exchange.
The
allocation
exchange
will
like
send
the
tokens
that
are
related
to
the
voucher
into
the
stacking
contracts.
D
Those
will
be
accumulated
in
what
we
call
our
rebate,
pools
and
rebate
pools.
Is
this
concept
that
we
have
in
the
implementation,
which
is
a
really
like
a
bucket,
where
we
accumulate
query
fees
for
a
certain
period
of
time,
for
it
like
a
window
of
time,
and
then
we
apply
the
cup
Douglas
formula
to
to
that
bucket.
D
D
So
now,
let's
look
at
the
proposed
implementation
for
the
exponential
rebates.
The
first
thing:
you'll
notice,
it's
a
single
step
operation,
so
the
indexer
will
just
redeem
their
voucher
and
instantly
automatically.
You
will
get
the
the
rebates
calculated
and
the
rebates
will
be
get
transferred
back
to
the
indexer.
That's
single
transaction,
no
window
of
time,
no
rebate
pools
all
that
complexity
gets
thrown
away,
which
is
great,
I,
think
there
we
go
so
yeah.
Just
to
summarize,
the
first
thing
is
rebate
pools
are
removed.
D
It's
this
allows
us
to
do
instant
rebates.
You
just
redeem
your
voucher
and
you
get
the
rebates
back.
That's
single
transaction,
which
is
good.
It's
versus
the
previous
case,
and
the
second
change
or
simplification
is
that
we
no
longer
need
this
window
of
time
defined
by
this
parameter.
We
no
longer
need
several
allocation
states
that
were
part
of
the
life
cycle
of
an
allocation
claimed
and
finalized.
Those
don't
really
mean
anything
with
an
implementation.
D
There
is
an
another
consequence
derive
of
these
that
query
fees
will
no
longer
get
burned
after
like
if
you
are
late
to
collect
your
fees.
So
today,
if
you
redeem
a
voucher
and
like
more
than
one
week
or
has
passed
after
the
allocation
has
been
closed,
like
those
fees
are
burnt,
because
you,
like
you,
missed
your
window
of
opportunity
to
getting
the
rates.
That's
not
going
to
happen
anymore,
which
is
also
all
good.
D
D
D
D
This
is
because
we
kept
the
same
interface
for
the
version
section,
so
there
are
no
immediate
change
updates
required
in
order
to
to
get
ready
for
for
this
implementation,
but
the
second
transaction
like
after
the
upgrade
will
of
course
be
reverting.
If
you
send
that
transaction
to
the
contracts,
so
in
a
later
upgrade
for
the
indexer
stack,
we
will
need
to
remove
that,
but
it's
not
a
hard
prerequisite
to
get
ready
for
for
this
implementation.
D
Okay,
the
second
thing
I
wanted
to
talk
about
in
terms
of
big
important
changes,
is
the
removal
of
the
risk
taking
flag
the
the
current.
The
way
this
currently
works
is
that
when
you
blame
your
rebates
on
the
second
transaction,
there's
a
flag
you
can
pass,
you
can
configure
if
that
flag
set
to
true
the
rebates
are
automatically
restaked.
If
that
flag
is
set
to
false,
the
rebates
are
transferred
back
to
the
indexer
address
or
the
indexer
address
defined
by
their
rewards
distribution
address
this.
D
So
the
way
indexings
will
work
and
the
way
we
proposed
the
the
new
query
fees
rebates
work
is
that
there
is
no
more
flag
and
then
the
behavior
it
depends
on
whether
or
not
you
have
a
rewards
destination
address
set.
If
the
indexer
has
an
an
address
set
for
that,
the
rebates
get
transferred
automatically.
If
they
don't,
it
rebates
gate
restaked
automatically.
D
This
making.
This
change
is
good
first,
so
both
indexing
rewards
and
query
fee
rebates
are
operated
similarly,
but
also
it
allows
us
to
not
make
changes
to
the
allocation
exchange,
which
is
the
other
contract.
That's
involved
in
this
like
we
could
remove
this,
this
change
from
the
Gip,
but
we
would
need
to
upgrade
that
other
contract
to
account
for
that.
D
A
It
okay!
Thank
you.
Thank
you.
So
much
we'll
include
these
in
the
show
notes,
so
for
those
that
will
be
watching
this
on
on
on
YouTube
anyway
cool
again,
thank
you,
Howard
and
tomash
for
your
presentation,
yep
yeah.
Thank
you.
So
much
I
believe
we
have
Alex
as
well.
Also
his
co-host
Alex.
You
should
be
ready
to.
B
Okay,
hello,
everybody
I
want
to
do
a
quick,
then
we're
going
to
come
back
to
from
the
if
the
real
reality
is
of
math
to
something
a
little
bit
more
concrete
there
with
a
GUI
application
that
we're
rolling
out
for
sub
streams.
You
might
have
seen
it
already.
We
had
a
first
version
and
I
want
to
show
you
just
a
bunch
of
new
features
for
those
who
are
developing
subtreams.
B
You
were
using
substream
to
run
you'll,
be
able
to
use
some
streams
GUI
now
we're
about
to
do
a
release
and
I'm
going
to
show
off
a
few
of
the
features
in
there.
Okay,
so
this
is
the
GUI
has
a
few
tabs
and
it's
a
terminal
based
like
in
the
old
days,
and
you
can
navigate
a
little
bit
of
the
the
documentation
of
the
sub
streams.
Module
you're
looking
for
in
here,
you'll
have
all
the
progress.
B
If
there's
massive
parallel
operations
happening,
you'll
see
all
these
bars
coming
through
and
then
you
can
navigate
the
results
and
I'm
going
to
show
you
a
few
shortcuts
like
you,
can
use
to
navigate
and
understand
what
sort
of
data
is
coming
through
and
also
realize
that
the
debugging
experience
in
substreams
it's
much
closer
to
the
metal
than
with
subgraphs,
and
that's
a
new
opportunity
that
we're
gonna
discover.
So
here
we're
in
the
graph
out
module
in
multiple
modules
and
substreams.
B
We
can
switch
from
module
to
module
with
two
keys
here
and
there's
a
new
feature
for
those
who
know
that
you
can
search
the
modules
with
little
M
and
then
you
can
like
punch
in
the
few
first
few
letters
and
hitting
like
up
and
down
and
whatnot
and
then
you're
going
to
switch
to
that
module.
Okay,
so
the
module
switcher
now
gets
improved
was
horrible
up
there.
B
It's
better
and
you
see
all
these
little
dots
that
those
mean
that
at
this
particular
block
that
module
outputted
some
data
and
you
can
jump
from
one
another
with
O
and
P
like
that
jump
back
and
forth.
And
now
there's
a
new
search
feature,
something
we've
added.
Let's
say
we're
interested
in
that
thing.
Here
we
can
search
with
Slash,
which
is
very
similar
to
less
it's
a
local
implementation,
that
searches
on
the
current
page.
Yes,
see,
there's
four
instances
here.
B
So
with
little
n
you
can
jump
down
and
up
capital
and
lower
end
goes
up
and
down,
but
also
it
applies
the
search
to
all
blocks.
So
you
can
find
quickly
what
other
blocks
match
see
in
this
case,
there's
no
other
mesh,
let's
search
for
anything,
at
least
with
a
string
pool,
address,
slash
pool
address
like
happens
that
there's
a
lot
of
matches-
they're
red-
maybe
you
don't
see
that
easily,
but
this
is
red
now
and
you
can
use
you
know
skips
to
go
to
those
with
capital.
O
capital
p
goes
to
the
next
block.
B
Where
there
is
a
match,
see
this
one.
It
has
partial
mesh.
This
doesn't
match
this
does
not
match,
but
this
one
goes
so
we're
going
to
jump
directly
to
the
next
matching
block.
So
that's
already
something:
we've
also
rolled
out
a
I'm
going
to
go
to
the
graph
out
module
which
outputs
things
like
entities
that
go
directly
into
graph
node
for
building
substreams
based
subgraph,
and
in
here
we
also
have
a
search
feature
that
is
slash,
slash
and
now
you
get
in
JQ
mode.
B
For
those
who
don't
know
JQ,
it's
a
Json
query
language
you
have
not
normally
like
on.
You
know
on
the
command
line.
You
can
query
whatever
you
type
in
Json
and
this
will
format
it
for
you
right
and
so
that's
JQ,
but
we
have
that
baked
in.
So
you
can
say
entity,
changes
and
then
hit
enter
and
it's
going
to
shrink
down
what
you
have
there
and
also
we've
added
the
search
history.
So
if
you
go
up
up
see
you
can
go
back
into
history,
switch
even
the
search
mode
and
continue
to
refine
your.
B
You
know
what
you're
looking
for,
where
ID
is
equal
to
that
thing
and
then
you're
going
to
get
only
that
one.
So
you
can
dig,
and
that
also
does
all
the
search
match
and
you
can
skip
to
the
next
block
to
see
only
the
things
that
you're
interested
in
so
and
that
the
search
is
freeform.
So
that's
that's
a
few
of
the
things
you
can
now.
Also,
let's
say,
go
if
there's
logs
here,
there's
log
capital
L
will
remove
the
log,
so
you
don't
search
into
them.
Capital.
L!
B
Are
there
other
options
you
can
see
here?
Oh
there's
a
new
formatter
for
you
guys,
working
with
bytes.
If
you
use
the
F
key,
you
I,
don't
I
don't
see
here
but
like
if
you
have
bites
or
serialized
normally
space
64..
Now
you
just
hit
F,
you
don't
need
to
go
to
the
command
line,
decode
base64
to
hex.
So
you
just
it's
going
to
cycle
through
the
method
of
decoding
for
bytes,
going
through
text
based.
You
know,
base64
strings
and
whatnot.
So
right
up
there
in
your
screen,
there's
a
new
feature.
B
You
modify
your
source
code,
you're
satisfied
with
I,
don't
know
what
here,
you've
changed
a
few
things
in
your
code,
rebuild
it
and
then
hit
R,
and
it's
going
to
rerun
the
whole
thing
and
you'll
get
the
updated
data
right
in
the
same
context,
same
block
same
module,
you
get
the
updated
value
now
and
one
last
thing
I
want
to
show
is:
we
have
now
a
visualizer
for
the
structure,
so
the
graph
structure
of
the
substreams
module
so
we're
going
to
graph
out
you
see.
All
of
these
are
the
inputs
to
the
graph
out
modules.
B
B
So
that's
it
for
the
GUI
last
thing,
there's
another
tool
that
we've
crafted
Junior
crafted
is
a
thing
to
test.
You
know
the
graph
out
here:
module
it
sending
out
entities
and
Fields
changes
and
creation
and
whatever
new
values
that
would
go
into
the
entity
this
little
tool.
We
launch
and
it
queries
graphql
the
subs,
the
sub
graph
in
graphql,
and
it
validates
that
all
the
values
are
the
same.
So
it's
looking
for
that
particular
entity
querying
for
that
ID
for
that
field
name.
B
You
can
already
build
firm
source
and
this
will
Aid
a
mass
actively
in
you
know
the
debugging
experience
even
before
it
reaches
any
postgres
database,
which
usually
with
what
takes
a
lot
of
time,
you
can
go
and
inspect
midways
in
the
in
the
chain
after
a
million
block
with
parallel
operation
happening
before
so
you
can
concentrate
on
debugging.
You
know
one
aspect
without
loading
in
postgres.
Okay,
that's
it
for
me.
Thank
you
all
see.
You
there.
B
F
F
So
yes,
so
so
this
is
very
much
in
the
same
ballpark
a
lot
of
the
same
stuff,
we're
working
on
across
the
teams
at
the
moment.
So
some
time
ago
we
had
a
post
on
the
Forum,
so
sub
streams
into
sub
graphs,
simple
integration,
I
think
things
are
always
maybe
simpler
in
in
Prospect,
but
I
think
I
think
what's
been
amazing
about
this.
This
whole
effort
is
the
number
of
teams
who've
been
contributing
across
the
ecosystem.
F
So
we've
got
folks
building
sub
streams,
building
tooling
for
sub
streams,
building
Instagram
Chrome
syncs
for
sub
streams,
and
so
it's
really
been
cool
to
see
it
all,
like
all
all
come
together
across
teams
with
everyone
bring
their
different
talents
to
bear
so
I
guess
so.
Alex
touching
on
some
things
again
for
some
people
this
this
will
be
understood,
but
the
anatomy
of
a
substream
looks
kind
of
like
this.
F
As
long
as
the
the
data
that's
being
produced,
matches
a
schema.graphql
file
so
now
we're
getting
into
subgraph
land.
So
we've
got
that
local
developer
experience
that
Alex
pointed
to
or
run
through
there
and
I
think
it's
definitely
true
that
I
don't
if
you've
got
Subway
developers
in
the
audience,
but
that
experience
of
building
a
subgraph
Cogen
build
deploy,
seeing
if
it
sinks
seeing
if
it
hits,
hits
and
an
arrow
with
substreams
with
the
local
development
environment.
F
You
can
be
running
the
indexing
process,
doing
that
validation
in
your
local
terminal,
testing
and
and
learning
much
more
quickly
and
then
essentially,
when
you're
ready
to
go,
you
can
just
essentially
make
sure
everything's
going
into
the
graph
out
as
you'd
expect
and
and
then
you
can
deploy
it
to
your
subgraph.
So
that's.
If
we
take
a
summer
sorry
I've
been
building
loads
of
great
sub
streams
using
their
e-supply.
F
As
an
example,
I
think
my
thing
is
covering
this
The
Entity
changes
are
the
end
output,
which
then
means
the
subgraph
can
consume
it.
So
you
put
it
into
subsequent
subgraph.
You've
got
your
substring
package.
Choreographical
schema.
You've
got
a
very
simple
subgraph.yaml
file.
You
essentially
pack
your
substream,
which
you
can
see,
is
referenced
here.
F
You
then
graph
build
again
I'm
moving
this
everywhere,
apart
from
where
it
needs
to
be
yep
and
then
graph
build
and
graph
deploy,
and
essentially
it
will
then
so
here
you're
using
the
substream
CLI
here
using
you're
using
the
graph
graph
CLI.
But
it's
only
a
few
commands
to
really
bring
it
all
together.
F
So
in
terms
of
the
current
status
of
this
and
conscious
of
time,
substring
based
data
sources
are
supporting
graph.
Node
core
developers
are
dog
fooding
integration
for
laptop
use
cases
and
sub
graphs.
Alex
pointed
to
a
couple
of
the
tools
that
we're
using
to
to
think
about
cross-comparing
data
from
a
conventional
subgraph
to
substream
power,
subgraph
to
make
sure
we're
getting
consistent
data.
F
As
a
subgraph
data
source,
so
there's
also
a
lot
of
work
which
we're
learning
as
we're
dog
fooding.
This
ways
we
can
make
things
work
better,
so
one
is
more
efficient
rights
to
the
database.
One
thing
we
see
is
that
we
we
start
to
hit
up
on
the
limits
where
you
write
per
block
as
subgraphs
do
and
so
we're
working
on
more
efficient
rights
to
the
database.
F
Masari
has
mentioned
in
making
lots
of
ready-made
apis
parameterized
Sub
sub
streams
are
maybe
a
really
powerful
tool
to
reduce
the
amount
of
manual
building
and
and
duplication
increase,
the
sort
of
like
modularity
and
benefiting
from
other
people's
work,
that's
possible
in
sub
streams,
and
then
Alex
has
talked
a
lot
about
turning
a
lot
of
their
learnings
into
cookbooks
and
examples.
So
people
are
building
stuff
in
the
right
way
and
and
they
have
the
information
that
they
need
in
terms
of
what
happens
next
through
the
proposal.
F
Initial
implementation,
phase
of
doing
testing
documentation,
making
some
of
those
improvements,
as
mentioned
coming
up,
is
in
I
guess
an
open
Alpha
on
the
subgraph
studio
for
developers
mips
program
for
indexes
to
get
them
start
testing.
This
this
new
functionality
onto
an
open,
Beta,
General
availability
on
on
on
the
network
after
that,
and
so
we
are
running
out
of
time.
So
I
don't
know
if
we
even
have
any
time
for
questions,
but.
F
Yes,
yes
also,
so
the
example
I
was
just
showing
there
was
in
this
was
in
the
Missouri
sub
streams
example
Dylan,
but
I
think
one
thing
we
definitely
want
to
make
available
is
is
more
examples
that
show
all
of
the
different
patterns
that
we
kind
of
that
we're
seeing
yes,
there's
they
they've
got
some
great
examples.
There
and
they've
very
much
been
leading
the
way
on
something,
in
particular,
some
of
the
network-wide
sub
streams.
A
D
A
Mentioned
we'll
be
working
on
better
dogs
and
cookbooks
and
examples
yeah
so
that
time
I
just
wanted
to
do.
One
final
shout
out
to
Darby
she's
a
graph
Advocates
she's,
an
advocate
she's,
been
doing
great
work
on
collecting
all
of
these
notes
and
sharing
it
on
Twitter
super
helpful,
get
like
a
nice
tweet
tweet
tweet
thread
so
do
be
on
the
lookout
for
those
summaries
on
Twitter
moving
forward
as
well
thanks
Darby
and
that's
it.
Thank
you
all
so
much
whatever
that
time.