►
From YouTube: The Graph | Core Devs #17 - Nov 10, 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://thegraphfoundation.notion.site/The-Graph-Core-R-D-5dca927e67eb4e459539f5bd6d0a7fb8
------
**Core Devs Call - November 10th, 2022**
**Timestamps**
00:00 Intro
04:33 Scalar/Fee System Update
18:31 The Graph's Billing UX
34:20 Code4rena Contest
38:22 GRT Arbitrum Bridge Updates
45:16 Adding Support for Multi-Chain Indexing Rewards
Link to external sources mentioned in the call:
- GIP-0040: L2 Bridge & Protocol Deployment: https://forum.thegraph.com/t/gip-0040-l2-bridge-and-protocol-deployment/3695
- GIP-0008: Subgraph API versioning and feature support: https://forum.thegraph.com/t/a-process-for-specifying-the-subgraph-api-version-and-feature-support-matrix/2004
- GIP-0009: Arbitration Charter: https://forum.thegraph.com/t/an-arbitration-charter-to-clarify-arbitrator-behavior/1936
- GIP-0038: Epoch Block Oracle: https://forum.thegraph.com/t/gip-0038-epoch-block-oracle/3323
------
Need help migrating subgraphs to the network? Here's a complete tutorial: https://thegraph.com/blog/how-to-migr...
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/theg...
GitHub: https://github.com/graphprotocol
Website: https://thegraph.com/
Calendar: https://calendar.google.com/calendar/u/0/embed?src=info@thegraph.foundation
A
Okay,
it's
recording
now
I'm
still
letting
some
people
in
let's
get
started
with
four
minutes
in
okay.
Welcome
all
welcome
back,
it's
another
core,
devs
call.
As
always.
This
is
a
monthly
call
with
the
the
graph
core
contributors
or
in
other
words
core
devs,
and
all
of
these
calls
are
recorded
and
uploaded
to
our
YouTube
channel.
So
I'll
just
leave
the
the
link
in
the
chat.
A
If
you
want
to
check
the
previous
ones
and
as
always,
your
all
more
than
than
welcome
to
join
all
of
these
calls
and
get
the
the
chance
to
ask
some
questions
and
participate
in
this
discussions,
you
can
always
also
go
to
to
our
website.
That's
listening!
This
slide,
I'll
just
share
a
link
as
well,
and
there
you
can
see
the
core
devs
workspace,
our
ecosystem
calendar,
so
you
can
subscribe
and
and
join
future
future
calls.
A
A
It's
ongoing:
that's
what
we're
calling
the
phase
phase,
one
we've
had
around
400
people
participating
and
they
are
still
participating,
which
is
pretty
good
right
now,
we're
focusing
on
adding
robustness
to
the
network,
meaning
that,
because
we're
now
supporting
multiple
chains,
there's
new
components
like
the
epoch,
bulk
Oracle,
that
we've
been
covering
here-
and
you
know
we
need
to
make
sure
that
everything
is
working
properly
before
we
go
on
to
mainnet.
That's
why
the
all
of
this
testing
is
happening
on
the
graphs
early
testnet.
A
So
that's
the
main
goal
of
this
phase.
One
really
is
to
monitor
to
OS
and
ensure
that
we
are
ready
to
serve
noses
properly
on
the
network
and
that
will
be
phase
two
which
is
imminent,
so
do
keep
an
eye
on
the
program
and
check
your
emails.
If
you
are
participating
yeah-
and
this
hasn't
been,
this
will
never
be
possible
without
the
mips
participating
and
sharing
their
feedback
on
the
program.
So
appreciate
you
all.
This
is
how
we
can
get
ready
per
minute,
quick
overview
of
the
agenda.
A
So
today
we
will
go
over
scalar.
As
you
know,
scalable
is
a
micro
micro
transaction
solution
previously
built
on
the
connect
Vector
protocol
for
query
fees
on
the
network.
It's
been
recently
read
the
design
to
support
some
solutions
like
homomorphic
encryption
and
thus
removing
implicit
thrusts
in
the
process.
A
Zach
will
share
more
updates
here
for
sure
and
shall
more
the
recent
achievements
coming
from
the
from
the
research
team,
then
we'll
have
Brandon
Kramer
from
agent
node
who's
been
working
on
Improvement
upcoming
improvements
to
the
graphs
building
user
experience
yeah.
That's
like
this.
We've
all
been
dedicating
quite
a
bit
of
time
to
this,
so
I
think
it's
worth
going
over
this
and
I
think
we'll
get
some
20
or
25
minutes
for
this
particular
session.
A
Lastly,
still
on
Gip
is
actually
a
quick
overview
of
changes
coming
to
the
protocol
and
state
of
dependencies
related
to
unlocking
multi-chain
indexing
rewards
on
the
network
and
that's
going
to
be
from
Adam
and
leaving
some
time
for
Q
a
and
open
discussions
and
also
during
all
of
these
topics.
At
the
end,
you
know
if
you
want
to
participate
and
ask
questions,
just
raise
your
hand.
I
will
unmute
you
and
you'll
be
able
to
ask
your
questions
the
right
away.
So
yeah,
it's
a
big
agenda.
A
B
B
Just
as
a
quick
refresher
of
of
what
scalar
is,
is
that
scalar
enables
fees
to
flow
from
gateways
to
indexer.
We
had
to
roll
a
custom
fee
system,
rather
than
use
any
of
the
off-the-shelf
state
Channel
Solutions,
because
we
couldn't
find
any
state
Channel
solution
that
would
scale
to
the
needs
of
the
graph.
So
in
the
graph,
every
query
is
enabled
by
a
fee
and
the
hosted
service
is
serving
more
than
one
billion
queries
per
day
by
comparison.
B
Ethereum
is
doing
about
1
million
transactions
per
day,
so
we
would
need
about
1
000
times
that
capacity
today
to
just
account
for
query
fees,
not
accounting
for
future
growth
of
the
graph.
So
that's
a
lot
of
fees
that
we
we
need
to
support
with
this
system.
Not
only
did
we
need,
you
know
to
support
all
this.
This
throughput
for
the
1
billion
queries
per
day,
but
we
also
needed
something.
B
So
that's
how
scalar
works
and
then
the
the
last
thing
that
we
would
really
need
for
scalar
to
to
be
able
to
support.
The
graph
is
a
highly
efficient
dispute
system
which
no
other
state
Channel
system
has
so
efficient
disputes
are
essential,
because
an
indexer
needs
assurances
that
if
they
serve
queries,
they're
going
to
receive
those
fees,
you
know,
even
if
a
Gateway
goes
offline
or
refuses
to
cooperate,
they
don't
want
to
to
trust
that
Gateway
is
going
to
to
pay
them
the
fees
right
because
they're
incentivized
to
hold
on
to
their
fees.
B
So
they
they
want
to
be
sure
that,
even
if
the
Gateway
is
not
cooperating
that
they
can,
they
can
collect
those
fees
anyway.
And
what
I
want
you
to
notice
about
these
design
goals?
Is
that
highly
concurrent
State
channels
and
efficient
disputes
seem
to
be
at
odds
with
one
another,
and
these
are
the
things
that
we
need
scalar
to
be.
B
You
know
including
publishing
papers
for
academic
peer
review,
they're,
developing
a
compiler
and
just
lots
of
places
to
cross
our
T's
and
Dot
our
eyes
to
get
this
over
the
finish
line.
But
in
the
meantime,
the
exciting
thing
that
I
I
want
to
share
with
you
today
is
that
the
cryptography
team
at
semiotic
has
come
up
with
an
even
better
approach
than
snarks
to
deal
with
this
problem
of
efficient
disputes
in
scalar.
Now
snarks
are
great,
but
one
of
their
key
advantages
is
also
their
weakness,
in
that
they
are
general
purpose
tools.
B
They're
designed
to
solve
any
compute
problem
that
you
throw
at
them.
You
know
as
Engineers.
We
we
know
that
there
are
advantages
to
bespoke
Oak
Solutions.
You
know
solutions
that
are
designed
to
exactly
fit
the
specifications
of
the
problem
that
you
have
right.
That's
why
there's
not
just
one
power
tool
in
someone's
garage,
not
just
a
hammer
or
just
a
screw
driver
or
just
a
a
shot,
a
saw
for
all
problems.
We
have
many
different
kinds
of
tools
for
many
different
jobs.
B
It's
resizable,
you
know.
One
of
the
problems
that
we
had
with
snarks
is
that
you
have
to
choose
ahead
of
time
how
many
state
Channel
that
you're
going
to
support.
So
we
we
wanted
to
get
up
to
say
a
million
concurrent
State
channels,
but
then
we
would
have
to
bake
in
that
number,
potentially
forever
that
one
million
State
channels
was
just
going
to
be
the
number
that
we
supported,
and
you
know
never
never
more
than
that.
But
with
this
new
solution,
it's
it's
resizable.
B
So
if,
if
we
happen
to
use
a
million
State
channels,
then
need
more
well,
we
can
just
grow
the
solution
to
support
that
number
of
State
channels
and
if
we
need
less
than
a
million
State
channels
well
we
can.
We
don't
have
to
be
paying
the
cost
for
a
million
at
all
times.
We
can.
We
can
start
off
with
a
much
lower
number
and
grow
as
As
We
Knew,
also
a
cheaper
verifier,
which
is
the
the
cost
that
the
indexer
pays
on
chain.
B
Whenever
they're
going
to
be
collecting
fees-
and
this
is,
you
know-
cost
savings
that
can
be
passed
on
to
Consumers
a
cheaper
approver.
You
know,
one
thing
that
was
was
very
difficult
to
overcome,
with
the
with
the
snark
solution
was
that
when
we
wanted
to
generate
a
proof,
it
meant
having
a
large
amount
of
infrastructure.
B
You
know
maybe,
depending
on
the
system,
up
to
maybe
two
terabytes
of
ram
that
you
just
had
to
have
available
to
you
for
a
few
hours
to
generate
one
of
these
proofs
and
the
the
cost
for
that
kind
of
system.
Add
up
in
a
non-negligible
way
that
will
that
people
would
notice
when,
when
using
the
graph-
and
then
you
know
finally
something
that's
faster
to
Market,
you
know
we,
we,
we
love
our
snarks,
but
we
have
real
problems
that
we're
trying
to
solve
today.
B
So
if
we
can,
if
we
can
get
something
out
the
door
sooner
with
all
these
properties,
that
would
just
be
you
know
a
win
for
everyone,
and
what
they
came
up
with
is
a
a
holographic
homomorphic
signature
scheme,
which
is,
you
know,
quite
a
mouthful,
so
they,
you
know,
helpfully
abbreviated
that
to
just
h2s2,
which
is
a
working
title.
This
is
not
a
marketing
update.
B
This
is
just
an
update
to
the
community
about
where
things
are
at,
so
h2s2
is
kind
of
what
we're
calling
this
thing
internally
and
what
it
does
is
to
take
advantage
of
the
structure
of
homomorphic
signatures
and
map.
That
structure
to
our
problem,
you
know,
cryptography
is,
is
always
complex,
but
the
key
Insight
of
this
scheme
is
very
straightforward,
so
I'm
comfortable,
you
know
just
going
over
it
on
on
this.
B
B
And
so
you
know
if
we,
if
we
have
that
data
all
we
need
to
do
to
verify.
The
proof
is
just
verify
a
single
signature
and
we
have
our
succinct
proof
like
that's
it.
No
complicated,
polynomial
math
with
snarks
and
whatever
it's
just
like
very
easy
to
understand.
What's
going
on
here,
I
am
glossing
over
a
lot
of
detail,
but
you
know
the
core
idea
is
just
that
simple
and
because
it's
so
simple,
you
know,
we
think
that
we
can
deliver
this
solution
much
faster
than
any
any
snark
based
snark
powered
solution.
B
You
know
why,
then,
why
do
you
care
right
as
a
member
of
the
community
graph?
Why
is
this
update
exciting
to
you?
First,
you
know
the
efficient
dispute
resolution
is
going
to
be
cost
savings
and
those
savings
are
going
to
be
passed
from
indexers
onto
consumers
and,
ultimately,
lower
cost
means
that
we
can
enable
more
economic
use
cases.
You
know
powered
by
the
graph
more
efficiently,
big
bad
long
tail
of
of
use
cases
you
know
can
be
enabled
if,
if
the
graph
is
is
cheaper
to
use
which
this
this
solution
provides.
B
But
another
benefit
that
that
might
be
a
little
less
obvious
is
to
scale
out
the
role
of
the
Gateway,
and
you
know
who
can
operate
a
Gateway.
The
reason
that
we
can
do
that
is
that
today,
the
graph
console
approves
Gateway
operators,
and
they
have
to
do
this
because
of
this.
This
trust,
this
implicit
trust
between
the
indexer
and
a
Gateway
that,
when
an
indexer
is
going
to
serve
queries,
they
want
to
have
assurances
that
they
can
collect
their
fees.
B
But
if
the
dispute
resolution
mechanism
is
not
efficient,
then
that
trust
is
is
just
based
on
delegated
trust
from
the
the
graph
console
that
the
graph
console
is
responsible
for
vetting
these
gateways
and
and
choosing
Gateway
operators
that
are
long-term
incentive
aligned
with
the
graph
you
know
and
that
delegated
trust
system
works.
But
it's
not
ideal.
B
What
we
really
like
is
to
be
able
to
allow
for
for
more
Gateway
operators
to
participate
in
the
network,
and
so
what
we're
really
doing
here
is
replacing
the
trust
that
is
delegated
by
governance
in
the
graph
council,
with
trust
that's
built
on
mathematics,
so
we
can
scale
participation
in
the
graph
and,
in
particular,
scale
participation
in
the
role
of
the
Gateway
using
incentive
systems.
You
know
that's
what
what
the
graph
is
all
about.
A
C
B
I
correct
it's
actually
much
more
than
that,
because
we
have
concurrent
requests
between
any
Gateway
and
and
indexer,
so
that
can
mean
thousands
of
State
channels
between
a
single
Gateway
and
indexer.
So
we
really
need
a
system
that
scales.
You
know
well
well
beyond
what
what
any
existing
system
does
today.
B
In
fact,
we've
seen
the
season
in
the
high
hundreds
of
thousands
of
State
channels
between
even
single
gateways
and
indexers,
because
of
the
graph
being
geographically
distributed
all
over
the
globe,
and
we
don't
want
to
have
separate
collateralization
for
each
of
these
relationships
and
the
system
needs
to
be.
You
know
robust
and
fault,
tolerant
for
failure,
which
means
spinning
up
even
more
State
channels,
so
there's
a
there's
a
lot
of
State
channels
going
on
at
any
given
time.
B
A
D
Right,
so
you
should
be
able
to
see
my
screen
yep.
We
are
perfect,
okay,
so
yeah
I'm,
gonna
chat,
hopefully
I
won't
reach
that
25
minutes
and
there'll
be
time
for
questions
for
both
this
and
and
for
Zacks.
If
anybody
else
has
any
questions,
but
I'm
generally
going
to
cover
what
the
upcoming
improvements
are
to
the
graphs
billion
ux,
this
is
part
of
a
general
kind
of
initiative
that
we
have,
where
we're
looking
at,
how
to
strategically
improve
a
number
of
things
about
the
graphs.
D
The
main
three
things
that
we've
been
focusing
on
over
the
past,
maybe
two
to
three
months
or
so
have
been:
first
improving
the
billing
and
payment
ux.
Basically,
users
are
experiencing
a
lot
of
cognitive
complexity
when,
when
making
payments-
and
this
is
specific
to
like
the
actual
billing
flow,
when
they're
going
through
and
clicking
to
make
payments
each
month,
it's
complex,
there's
too
many
steps
and
we
there's
a
number
of
ways
that
we
we
have
identified
to
improve
that.
The
second
thing
here
is
price
predictability.
D
D
So
that's
kind
of
our
second
initiative
and
then
the
third
thing
here
is
around
Network
quality
of
service,
and
it
should
be
no
surprise
that,
obviously
we
want
to
make
the
graph
network
not
only
reach
parity
but
eventually
surpass
the
quality
of
service.
That's
Often
by
or
offered
by
the
hosted
service,
so
I
think
all
three
of
these
things
kind
of
are
are
really
intertwined,
but
today
I'm
going
to
be
focusing
mostly
on
billing
and
payment
ux
here
and
talking
about
the
things
that
we're
doing
to
improve
that.
D
So,
if
you're
not
familiar
with
the
billing
flow,
just
say
that
you
deploy
a
subgraph
you're
making
queries
and
you
accumulate
a
bill
over
the
course
of
a
month
and
you'll.
Have
this
notification
in
subgraph
studio
that
says:
I
are
you,
you
have
a
certain
amount
owed
and
then
you
have
to
go
in
and
pay
your
bill.
So
the
way
that
you
do
that
you'll
go
into
subgraph
studio
and
you'll
click
and
a
modal
will
come
out,
and
these
three
General
sections
appear
in
this
modal.
D
In
the
first
section,
it
tells
you
that
you
need
to
buy
GRT
and
ethereum.
The
GRT
will
cover
the
queries
and
the
eth
will
cover
the
transaction
costs
and
the
second
box
here
you
see
that
you'll
have
to
move
that
GRT
from
ethereum,
where
GRT
typically
is
to
over
to
polygon,
to
pay
that
Bill-
and
here
we
keep
our
billing
contract
on
polygon,
mainly
to
try
to
kind
of
streamline
some
of
the
costs
for
collecting
payments
on
our
side.
D
So
the
three
main
things
that
we
that
we're
looking
to
implement
are
mainly
related
to
kind
of
each
of
these
steps
and
I'll
show
you
what
that
looks
like
in
the
next
slide.
But
let
me
explain
each
one
of
these
first.
So
the
first
step
is
this
notion
of
abstracting
the
the
Billing
Bridge
for
consumers,
as
you
saw
in
the
last
slide,
the
kind
of
the
middle
middle
area
there
in
the
in
the
slide
shows
that
users
need
to
after
they've
purchased
GRT.
D
They
will
have
to
go
and
bridge
that
over
to
polygon.
So
what
we're?
What
we're
working
on
implementing
and
this
will
be
possible
to
do
after
we've
shifted
to
arbitrum
or
at
least
made
the
Billing
Bridge
available
on
arbitrum
is
really
on
the
back
end,
we'll
kind
of
make
the
shift
from
moving
the
billing
contract
from
polygon,
where
it
currently
sits
over
to
arbitrum,
and
this
is
because
we're
moving
the
entire
protocol
over
to
arbitrom.
D
This
will
just
be
one
one
step
that
they'll
click
and
that
all
will
happen
kind
of
in
the
same
transaction
or
same
set
of
transactions.
The
main
point
is
that
users
won't
really
have
to
experience
that
time
consuming
and
many
many
step
process.
Instead,
that
will
be
streamlined.
So
that's
really
the
first
step
again
we'll
be
able
to
do
this
once
we've
moved
the
billing
contract
over
to
arbitrum,
which
happens
after
the
billing
or
the
after,
the
general
Bridge
from
ethereum
to
arbitrum,
is
and
enabled
so
we're
hoping
that's
coming
soon.
D
D
The
idea
here,
though,
is
that
users
will
be
able
to
access
a
Fiat
on-ramp
that
replaces
that
first
step
right
now
we
ask
users
to
take
over
to
coinbase
or
Finance
or
another
centralized
exchange
buy
GRT
and
then
in
some
cases
you
may
have
to
wait.
You
know
maybe
a
week
or
something
like
that
to
even
get
GRT
back
over
to
your
wallet.
In
some
cases
there
are
limitations
there
and
what
you
can
actually
transfer.
D
Instead,
we
want
to
make
a
Fiat
on-ramp
available
kind
of
in
that
payment
flow,
so
this
option
will
essentially
allow
users
to
go
in
they'll,
be
able
to
click,
they'll,
go
to
a
Fiat
on-ramp
and
then
be
able
to
purchase
GRT
directly
there.
Two
cool
things
that
we've
or
we're
working
on
implementing
is
typically
with
a
Fiat
on-ramp.
D
When
you
buy
an
asset,
it
will
be
sent
to
your
wallet
instead
we're
working
to
try
to
implement
or
we're
working
to
implement
the
option
to
be
able
to
buy
GRT
and
then
directly
deposit
that
to
the
billion
balance
or
a
billion
balance.
This
will
prevent
a
number
of
other
steps
after
you've
purchased
ERT.
D
To
then
have
to
go
back
to
your
wallet
and
make
additional
steps.
This
will
go
directly
to
your
billing
balance
and
after
you've
kyc'd.
It
should
just
be
a
one
to
two
click
process
to
really
go
in
there
by
GRT
and
then
add
to
your
billing
balance.
So
this,
the
the
main
group
of
users
that
we're
targeting
here
are
trying
to
are
mainly
around
users
that
you
don't
want
to
hold
Fiat.
They
want
to
make
payments
with
credit
cards,
and
this
will
help
streamline
that
process.
D
D
The
last
section
here
kind
of
fits
into
a
different
group,
and
in
the
first
group
we
have
users
that
already
have
GRT
and
ethereum.
The
second
group
is
really
that
they
don't
have
GRT
yet
but
want
to
pay
with
credit
cards.
This
third
group
is
really
about
trying
to
streamline
those
users
that
have
stable
coins
and
would
prefer
to
hold
stateable
stable
coins,
but
still
be
able
to
use
the
graph
without
having
to
hold
GRT
for
for
too
long.
So
this
third
option
here
is
kind
of
optimized
for
them.
D
This
would
essentially
allow
users
to
have
automated
and
recurring
crypto
native
payments
from
either
wallets
or
multi-cigs.
So
what
happens
here
is
essentially,
you
could
have
a
wallet
or
a
multi-stig
that
drips
into
a
wallet.
You
keep
your
stable
coins
or
any
kind
of
GRT
or
non-grt
related
crypto
asset
in
that
wallet
over
here
you
have
your
billing
balance
and
you'll
sit
you'll,
be
you
know,
making
queries
that
depend
on
this
billing
balance
and
let's
just
say
that
it
gets
to
a
certain
point
and
you
want
to
refill
it.
D
This
will
be
50
GRT
that
it
gets
below
and
then
essentially
will
send
a
trigger
back
to
your
wallet
to
drip
GRT
into
this
into
this
billing
balance.
So
in
this
case
we'll
say:
50
GRT
is
the
threshold
or
the
trigger
it
will
kind
of
notify
the
wallet
and
then,
if
you
have
GRT
it'll,
just
directly
go
into
your
billing
balance.
D
If
you
have
a
stable
coin,
on
the
other
hand,
it
will
be
sent
to
a
decentralized
exchange,
you'll
get
GRT
and
then
it'll
come
back
and
go
into
your
billing
balance
and
all
those
transactions
and
kind
of
cross-chain
transactions
will
be
taken
care
of
by
implementing
kind
of
a
smart
contract
that
will
automate
that
entire
process.
So,
in
the
end
you
consumers
will
have
kind
of
two
different
options:
they'll
be
able
to
either
Trigger
or
have
a
trigger
that
sets
up.
D
When
your
billing
balance
gets
low,
it
will
refill
up
to
a
certain
amount
in
the
case
that
I
mentioned
before
50grt
might
be
the
trigger
and
it
will
increase
to
500
GRT
to
pay
the
next
month
of
of
query
of
query
payments
or
something
like
that.
The
other
option
is,
if
you
just
want
to
drip
this
slowly
in
over
the
course
of
every
week
or
every
month,
I
believe
that
option
will
probably
be
available
too,
but
that's
something
we're
still
kind
of
debating
internally.
D
So
in
the
end
you
should
see
you
know
the
same
kind
of
of
flow
overall,
but
each
one
of
each
aspect
of
this
flow
will
be
improved.
So
in
the
first
step
we'll
be
adding
a
Fiat
on-ramp
so
that
you
don't
have
to
go
as
a
consumer.
You
won't
have
to
go
to
coinbase
or
Finance,
but
instead
you'll
have
an
on-ramp
to
make
those
purchases
directly
in
the
flow.
D
The
second
option
will
abstract
that
bridge
from
consumers,
so
you
won't
have
to
bridge
from
ethereum
to
polygon
each
time
you
will
still
be
bridging
to
Arbitron,
but
that
will
be
abstracted
from
you.
It
will
generally
be
the
same,
the
same
fee
in
roughly
the
same
time
period
that
you'll
have
to
wait,
but
again
there
won't
be
so
many
clicks,
and
hopefully
this
will
streamline
the
process
and
and
annoyance
a
little
bit
and
the
last
step
kind
of
applies
to
all
three
of
these.
D
It
really
generally
automates
recurring
payments
so
that
you
can
hold
stable
coins
or
other
crypto
assets
and
kind
of
automate
this
process
on
a
weekly
or
monthly
basis,
so
that
you
don't
have
to
worry
about
going
in
to
make
payments
manually
each
month.
So
this
is
essentially
like
kind
of
setting
your
or
putting
in
a
credit
card
on
other
kind
of
platform
and
just
automating
that
monthly
payment
and
covering
that
those
query
costs
so
hopefully
that
all
made
sense.
D
Those
are
the
three
main
improvements
that
we've
been
thinking
about.
It's
worth
noting,
though,
that
we
all
already
have
a
couple
of
a
number
of
other
things
that
we've
already
either
implemented
or
are
close
to
being
implemented
as
well.
So
I
mentioned
previously
that
when
you're
making
payments
you'll
have
to
bridge
GRT
from
ethereum
to
to
polygon
and
that
we're
moving
over
the
billion
balance
to
arbitrum.
D
The
second
thing
here
is
the
email
notification
system.
This
is
something
that
we
updated
I
want
to
say.
Over
a
month
ago
now,
in
previous
ux
research,
we
identified
the
the
the
need
for
users
to
have
multiple
emails
in
their
account.
Previously
users
only
had
one
email
and
they
would
get
those
notifications
about
a
low
billing
balance
to
that
one
email.
But
obviously,
if
individuals
are
within
an
organization,
they
may
need
up
to
10
emails
to
notify
other
stakeholders
within
the
organization.
D
D
That
looks
something
like
this,
so
those
would
be
two
different
views
if
you're
looking
over
the
past
month,
these
will
show
the
amount
that
you
paid
each
week
over
the
course
of
the
past
month
or
if
you
click
on
the
yearly
view.
You'll
be
able
to
see
the
amounts
that
you
paid
over
that
correspond
to
each
month,
there's
also
a
number
of
important
kpis,
but
generally.
D
The
point
here
is
that
you'll
be
able
to
kind
of
visualize
your
past
payments
more
succinctly
and
then
hopefully
be
able
to
translate
that
into
what
your
price
will
be
in
the
coming
weeks
and
months.
The
last
thing
to
talk
about
here
is
this
query
price
estimation,
Tool
I'll
be
forthcoming
and
say
this.
D
Ideally,
we
would
love
the
option
for
users
to
go
in
and
say
put
a
query
into
the
playground,
for
instance,
and
be
able
to
estimate
exactly
what
that
query
is
going
to
cost.
Unfortunately,
it's
a
little
bit
more
complicated
than
that,
because
we're
relying
on
a
decentralized
network
of
indexers
to
you
know
kind
of
Vie
for
what
the
price
is
going
to
be
to
serve
that
query.
E
A
A
A
F
F
F
We
had
to
prepare
a
separate
repo
with
a
lot
of
the
code
that
we
wanted
to
audit
and
then
code
Arena
has
a
lot
of
wardens.
This
is
actually
a
permissionless
role.
Anyone
can
sign
up
to
be
a
warden
and
behave
as
a
as
an
auditor,
and
the
wardens
will
compete
to
find
and
Report
bugs
in
the
code
that
we
present
and
then
they
would
send
those
bug
reports
together
with
gas
reports
and
quality
assurance
reports,
also
telling
us
more
about
code
quality
and
things
that
we
can
do
to
improve
it.
F
F
So
we
already
had
an
audit
for
this
that
was
done
by
open,
separin
and
and
as
we
often
do,
but
because
this
is
such
a
critical
part
of
the
smart
contracts
we
wanted
to
have
as
many
eyes
as
we
could
on
this.
So
this
was
great
because
it
meant
like
there
were
a
lot
of
people
who
had
a
chance
to
look
at
the
code
and
find
vulnerabilities
in
the
Box,
and
this
is
our
first
experiment
with
code
Arena.
F
So
some
results
from
from
this
particular
contest.
We
we
had
I
think
pretty
good
participation.
We
had
315
submissions,
so
each
submission
is
either
a
high
or
medium
severity
issue
or
a
QA
report
or
a
gas
report
and
then,
after
the
duplication
from
the
judge
and
the
severity,
and
the
judge
also
looks
for
invalid
reports.
We
ended
up
having
79
valid
reports,
which
is
pretty
good.
F
The
good
news
is
there
were
no
high
severity
issues,
but
they
were
a
couple.
There
were
a
couple
of
interesting
medium
ones.
So
what
comes
next?
We
already
took
all
of
those
medium
severity
issues
and
the
relevant
stuff
from
the
QA
and
cash
reports,
and
we
implemented
a
lot
of
pictures
for
that
and
in
the
meantime,
the
judge
is
finalizing
the
the
price
distribution
and
there's
going
to
be
a
contest
report
that
will
be
public
eventually.
F
So
now,
we'll
we're
gonna
have
another,
or
one
of
these
wardens
in
particular
will
now
review
all
of
the
medications
that
we
did
to
make
sure
that
we
didn't
add
any
new
bugs
by
fixing
the
the
ones
from
the
contest,
and
once
we
have
approval
from
the
council
and
Adele
is
gonna
discuss
in
a
bit
more
detail.
All
of
the
steps
that
that
we
need
to
do.
We
should
be
able
to
deploy
the
bridge
and
finally
have
the
graph
102.
G
G
Yeah
this
is,
this
is
sort
of
a
continuation
of
what
Paulo
was
was
mentioning.
Clearly,
we
are
deploying
this
bridge
to
arbit
room
and
the
protocol
contracts
in
the
L2,
for
all
the
good
reasons
that
random
Kramer
explained
not
only
about
like
making
things
cheaper
and
faster
for
everyone
in
using
the
network,
but
also
because
of
like
so
many
you
ux
improvements
that
we
can
do
with
this.
Okay,
particularly
with
the
building
and
other
things.
G
So
to
give
you
more
of
a
global
overview.
Already
Pablo
talk
about
like
the
core
Arena
Community
audits.
We
did
a
an
open
sampling
audit
with
about
the
bridge,
but
apart
from
that,
what
we
already
did
is
to
deploy
the
the
protocol
on
a
sort
of
L2
in
the
public
testnet
that
is
connected
to
the
Godly
test
net
that
everyone
is
using
today.
G
So
those
contracts
are
already
really
connected
to
the
to
the
L1
and
what
what
is
happening
now
is
that
the
team
is
running
some
tests
on
the
on
that
public
test
net.
Basically,
moving
some
GRT
over
trying,
like
I,
don't
know
doing
some
allocations
on
the
L2
moving
things
back
from
the
L2
to
L1
Prime,
with
different
gas
parameters
to
see
like
everything
is
working
properly.
G
G
So
what's
the
council
voting
right,
there's
a
few
gips
that
are
related
to
to
this
deployment
and
this
I'm
providing
this
ID.
So
you
can
search
in
the
Forum
later,
if
you,
if
you
want
to
dig
into
the
details,
but
first
of
all
we
have
these
big
I
would
say
this
is
involved
because
we
have
a
JP
40
that
is
sort
of
a
meta
gab
that
describes
the
deployment
and
it's
it's,
including
Gip
number
31
and
39.
Okay,
JP,
13
31
is
basically
deployed.
G
But
there
won't
be
any
kind
of
indexing
rewards
being
minted
there
and
there's
a
different
JP.
That
is
going
to
propose
how
to
activate
indexing
Rewards.
And
the
final
thing
is:
there's
a
proposal.
The
JP
number
39
that
is
proposing
flooding
in
the
bonding
curves
on
the
L2.
For
all
the
reasons
that
you
can
look
in
the
detail,
but
basically
making
things
easier
for
curators,
removing
all
kind
of
from
running
and
allowing
like
setting
the
base
for
other
improvements
in
the
that's.
G
It's
being
worked
by
the
team
for
creation
to
version
two.
So
if
you
are
interested
in
digging
into
like
the
details,
you
can
go
to
snapshot.
This
is
this
is
currently
what
the
council
is
powering
you
can
see.
There
are
five
seems
like
to
be
five
boats
for
doing
the
deployment,
and
it's
this
both
requires
six
council
members,
so
this
is
currently
active.
I
took
this
Snapshot
from
today,
so
this
is
happening
now,
after
the
approval
from
the
council.
G
The
that
the
steps
are
to
ensure
that
the
checklist
I
showed
is
complete,
then
setting
a
date
where
the
deployment
can
happen,
and
it
doesn't
means
that
the
once
the
contracts
are
deployed.
Everything
is
connected
right.
The
console
needs
to
do
some
unchain
transactions
to
finish
the
configuration
of
the
of
the
bridge,
basically
connecting
that
one
and
L2
and
then
I'm
passing
the
bridge.
So
there
will
be
a
final
on-chain
transaction
that
validates
that
everything
is
fine.
Okay.
G
G
A
H
Hey
how's
it
going.
Let
me
share
my
screen
yeah,
so
as
I
was
praying
for
this,
so
we're
talking
about
essentially
enabling
multi-channel
on
the
network.
I
was
reminded
of
the
first
time
we
talked
about
this
initiative
or
which
I
think
was
yeah
so
in
in
March
of
this
year.
So
it's
super
cool
to
see
all
the
progress
and
I
I
think
we
necessarily
didn't
necessarily
anticipate
all
of
the
work
at
the
time.
The
devil
is
always
in
the
detail,
but
really
cool
to
me.
H
I
guess
at
the
end
of
at
the
end
of
this
process.
So
to
give
a
bit
of
context,
do
my
adding
support
for
multi-chain
indexing
rewards.
This
is
very
tightly
coupled
with
the
update
that
Pedro
had
at
the
start.
Just
around
just
around
the
mips
program.
Obviously
notices
this
first.
This
first
network
was
being
added,
but
that
doesn't
sort
of
happen
on
its
own.
H
There
are
certain
things
that
we're
changing,
I
guess
about
the
protocol,
and
so
we've
got
a
couple
of
gips
which
we're
sort
of
moving
similarly
to
Ariel's,
update
towards
of
ratification
by
the
council
associated
with
that
with
those
changes.
So,
essentially,
will
be
required
before
we
can
go
to
mainnet.
So
really
here,
I'm
not
going
to
go
into
any
of
them
in
too
much
detail.
H
H
Time
but
the
essentially
introduction
of
new
networks
introduces
site
change
to
the
Charter,
essentially
in
terms
of
which,
where
the
blocks
come
from
when
you're
closing
an
allocation,
which
essentially
is
a
really
important
thing
when
it
comes
to
comparing
pois
and
so
there's
some
changes
to
the
arbitration
chart
that
are
necessary
there.
But
this
is
also
the
first
I
guess.
H
Formal
ratification
of
the
chartered
by
the
council
and
so
yeah
it'll
be
great
to
have
that
initial
version
ratified
I'm
sure
it
will
change
again
in
the
future,
as
we've
obviously
learned
so
much
over
the
last
year
and
we'll
continue
to
learn,
as
we
see
more
and
more
essentially
disputes
coming
up
and
edge
cases
and
presenting
themselves.
But
this
is
the
first
thing
which
sort
of
the
foundation
a
foundational
piece.
H
Similarly,
this
also,
as
you
can
see
by
the
GOP
number,
quite
an
old
Gip,
but
one
that's
been
situated
and
iterated
over
some
time.
What
we're
doing
by
introducing
new
networks
is
essentially
adding
more
features
to
this
to
sub
graphs
and
so
I.
Think,
as
lots
of
people
know,
there
are
different
features
that
are
not
supported
at
the
moment.
H
On
the
network,
so
ipfs
files
as
part
of
sub
Graphics
is
one
obvious
example
where
that
comp,
they
can't
currently
be
fetched
deterministically
and
so
indexes
can't
prove
their
work
through
proof
of
indexing,
and
so
we
can't
so
the
projector
doesn't
support.
Indexing
rewards,
that's
something
which
is
going
to
sort
of
increase
as
we're
adding
more
networks
as
we're
adding
more
features,
and
in
particular,
we
want
to
free
up
or
create
a
clear
pathway
for
core
developers
to
add
experimental
features
to
to
sub
graphs.
H
H
So
there's
a
lot
of
detail
again
in
this
Gip
and
comment
and
discussion
on
it
is,
is
welcome,
but
I
think
one
of
the
key
artifacts
that
comes
out
of
this
will
be
a
clearer
ratification
of
a
sort
of
feature
Matrix,
which
is
essentially
specify
different
features
that,
as
they're
defined
on
subcraft,
manifests
and
essentially
giving
in
indications
to
their
status.
So
are
they
experimental
or
not?
H
And
then
the
level
of
support
across
sort
of
query,
arbitration,
indexing
arbitration
indexing
rewards
and
so
making
this
a
formal
thing
which
also
tracks
the
sort
of
latest
approved
version
of
graph
node
I.
Think
it's
going
to
be
a
really
important
thing
going
forward,
so
to
give
everyone
Clarity
on
what
and
isn't
isn't
supported,
and
then
this
is
something
that
can
also
Cascade
throughout
the
ecosystem
to
serve
to
be
more
easily
serviced
in
the
Explorer,
so
so
sub
graph
information
can
be
like
highlighted
more
clearly.
H
As
you
can
see,
one
key
type
here
are
the
different
types
of
networks.
So,
as
new
networks
we'll
be
adding,
there's
additional
additional
lines,
work
on
the
only
mainnet
is
fully
supported,
so
those
are
two
quite
foundational
ones
getting
into
the
meat
is
essentially
the
epoch
block
Oracle.
So
this
is
essentially.
H
There's
again,
a
lot
of
detailing
here
around
the
mechanism
used
it's
using
a
data,
Edge
and
sort
of
sub
graph
as
an
oracle,
so
some
cool
implementation,
stuff
and
and
we're
also
there's
something
that's
being
actively
tested
on
as
part
of
the
mips
program.
Actually,
we
had
an
issue
this
week
where
we're
always
some
issues
with
provider,
reliability
and
so
again,
one
of
the
benefits
of
testing
things
on
testnet
and
we're
going
to
be
yeah,
essentially
getting
get
getting
ready
for
mainnet.
H
So
this
introduces
that
sort
of
new
technological
thing,
but
also
introduce
a
new
governance
thing,
which
is
the
addition
of
new
networks
to
the
evok
blog
article
is
going
to
be
done
by
the
council
multi-six.
So
again,
it's
just
giving
a
bit
more
clarity
and
essentially
governance
approval
to
additional
new
networks,
because
it
is
really
unlocking.
H
Quite
an
important
thing,
which
is
indexing,
rewards
for
new
chains,
so
those
that
there
are
two
things:
it's
a
new
technical
thing,
but
it's
also
a
new
governance
process
which
is
kind
of
tied
to
this
here.
But
it's
an
additional
actually
on-chain
action,
rather
than
just
a
governance
vote
and
then
the
last
thing,
which
is
really
just
a
specification
thing.
So
it's
the
edge
but
a
data
Edge
is
a
is
essentially
a
mechanism
for
getting
data
on
chain
into
a
subgraph
in
a
very
gas
efficient
way.
H
And
this
is
what
paths,
the
block
Oracle
and
essentially
it's
just
really
identifying
the
one,
which
is
that
we're
going
to
be
using
for
the
protocol
initially
for
this.
This
one
purpose,
but
we'll
be
using,
for
other
things,
I'm
sure
in
the
future,
and
so
quite
a
few
things.
Some
of
them
essentially
just
ratifying
long-standing
things,
others
introducing
new
functionality
to
the
network.
But
it's
pretty
exciting
and
and
yeah
questions
very
welcome.
E
H
Yes,
that's
a
good,
that's
a
good
call
out
so
I
think.
One
thing
we've
definitely
worked
through
here
is
to
try
and
minimize
the
amount
of
disruption,
obviously
for
indexes
so
I
think
one
thing
that
indexes
will
have
to
be
doing
if
they
want
to
support
nurses.
Sub
graphs
will
be
to
obviously
have
a
notice
client
that
they
can
access,
which
will
be
configured
via
by
graph
node.
H
The
other
like
I,
mean
I,
think
most
Salient
changes
they
need
to
make
is
to
update
their
indexer
agent
configuration
essentially
with
the
subgraph
endpoint
that
the
that's
essentially
the
block,
Oracle
subgraph,
and
then
that
will
essentially
be
used
to
look
up
blocks
when
appropriate.
That
should
be
used
to
close
allocations,
there's
a
bit
of
and
and
so
when
it
comes
to
actually
looking
at
block
numbers
block,
hashes.