►
Description
Co-founder of The Graph and Head of Research and Product at Edge & Node, Brandon Ramirez breaks down the debut of Graph Day back in 2019 and updates the vision that were explored then, and materialized before the second-ever Graph Day this year. As Ramirez’s talk progresses, he examines blockchain architecture evolution, subgraphs, the decentralized infrastructure market, and much more. Ramirez also revealed a proposal out for vote in the community to implement Arbitrum as a Layer 2 solution for The Graph Network, which if passed, would reduce cost of participation in the network.
Watch more Graph Day 2022 talks, panels, and announcements here: https://www.youtube.com/playlist?list=PLTqyKgxaGF3SWt8ipQw-Ul9HQvmxulbUu
Index:
0:00 Evolution of Blockchain Architecture
5:30 Read-Oriented Rollups (subgraphs)
16:46 Decentralized Infrastructure Market
26:55 The Graph’s L2 Scaling Strategy
31:41 Phases of L2 migration
35:42 Improved Economics for Developers
40:20 The Future of The Graph
Keep up with 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
If
you
had
told
me,
it
would
be
three
and
a
half
years
in
a
pandemic
before
the
second
graph
day.
I
wouldn't
have
believed
you,
but
here
we
are
and
actually
at
that
last
graph
day.
I
gave
a
talk
similar
to
this,
where
I
posed
a
question
to
the
audience.
What
is
the
graph
you
know
at
the
time
we
were
just
launching
edge
in
node's
hosted
service.
A
We
had
just
announced
the
earliest
iterations
of
our
protocol
design
and
by
looking
at
the
answer
to
this
question.
Through
these
three
properties,
you
really
could
have
predicted
the
next
few
years
of
what
the
graphs,
r
d
and
research
would
look
like
now
today,
I
want
to
revisit
this
question
through
two
new
lenses.
A
One
is
looking
at
the
graph
as
a
blockchain
protocol
and
the
other
is
looking
at
it
as
a
decentralized
infrastructure
market,
and
my
goal
is
to
contextualize
the
work.
That's
been
happening
in
the
ecosystem
for
the
last
few
years,
as
well
as
the
evolution
of
the
graph
that
you
can
expect
to
come
now,
you
might
be
asking
the
graph
as
a
blockchain
protocol.
You
don't
really
hear
it
mentioned
in
that
light
too
often,
right,
you
hear
queries,
you
hear
indexing.
A
So
here's
the
mandatory
bitcoin
slide
in
the
beginning.
There
was
bitcoin,
it
was
good,
but
the
problem
was
it
only
really
did
one
thing
right:
it
was
the
money
app
and
it
was
all
kind
of
rolled
into
the
other
innovations
of
blockchain
around
consensus
and
having
this
distributed.
You
know
data,
availability
and
state
machine.
A
A
few
years
later,
projects
like
ethereum
came
along
and
said,
hey
what,
if
we
decouple,
you
know
the
general
compute
layer
and
allow
people
to
build
their
own.
You
know
purpose-built
application,
specific
smart
contracts,
but
it
was
all
still
bundled
in
the
same
package
right
so
consensus
data
availability,
smart
contract
execution-
was
all
happening
within
the
same
chain
now
in
the
last
few
years,
with
the
advent
of
technologies
such
as
roll-ups,
as
well
as
purpose-built
chains
such
as
celestia
or
r-we've.
A
We
can
do
roll-ups,
we
can
do
volidiums
and
so
on,
and
what
I
would
like
to
pose
to
you
is
that
there's
actually
a
missing
layer
in
the
modular
blockchain
stack.
That's
been
underappreciated
and
underconsidered
in
the
blockchain
space
up
until
this
point
and
to
understand
why,
I
believe
that's
the
case.
I
want
to
walk
you
through
a
few
missing
pieces
that
exist
in
blockchains
today.
A
The
first
is
on
the
incentive
layer,
so
we
tend
to
think
a
lot
about
the
incentives
that
exist
in
blockchain,
such
as
the
gas
price
auction,
the
block
rewards,
but
there's
also
things
that
blockchains
need
to
do
to
succeed
that
aren't
directly
incentivized,
such
as
storing
historical
state,
running
archive
nodes,
doing
data
retrieval
right,
a
big
part
of
the
ethereum
and
blockchain
vision
was
being
able
to
do
light,
clients
and
warp.
Sync:
have
you
know
decentralized
block
explorers?
All
of
that
stuff
is
not
incentivized
directly
in
the
blockchain
protocols
that
we
have
today.
A
On
top
of
the
full
nodes
in
this
blockchain
data
supply
chain-
and
indeed
that's
what's
happened-
we
see
things
like
inferior
alchemy,
the
opencnft
api
be
very
successful,
but
we
believe
in
a
similar
spirit,
to
the
mev
researchers
that
are
looking
at
the
transaction
supply
chain
and
observing
that
centralization
at
one
layer
in
that
chain
can
infect
the
other
layers.
We
believe
that
it's
necessary
for
the
end-to-end
blockchain
data
supply
chain
to
be
decentralized,
otherwise,
the
only
ones
with
the
incentive
to
run
these
full
nodes.
A
So
I'd
like
to
introduce
a
new
concept
to
you
guys
today,
since
this
is
graph
day,
you
can
probably
see
where
I'm
going
with
this
we're
going
to
talk
about
sub
graphs.
But
in
this
context
I
want
to
talk
about
them
as
read
oriented
rollups
and
to
understand
why
I'm
using
that
label.
In
this
context,
let's
do
a
quick
recap
of
what
rollups
do
today:
they're
a
classic
example
of
this
unbundling,
where
data
availability
and
consensus
stays
on
layer
one,
but
state
machine
execution
moves
to
layer.
A
Two
and
specifically
it's
the
transactions
that
are
stored
as
like
call
data
on
ethereum,
and
then
you
can
either
submit
fraud
proofs
that
a
block
on
the
layer
2
is
incorrect,
as
in
the
optimistic
use
case
or
in
the
zk
roll
up
use
case.
You
can
get
validity
proofs
that
every
block
is
correct
and
can
be
verified
on
layer
1
in
real
time
now,
read-oriented
roll-ups
support
either
of
these
patterns,
the
optimistic
or
the
zk
pattern.
A
Sourcing
or
map
produce
logic
over
any
sets
of
triggers
that
exist
on
the
layer
one,
but
nonetheless
they
still
rely
on
layer,
one
for
consensus
and
data
availability,
and
so
the
new
layer
of
the
modular
blockchain
stack
that
I
want
to
propose
is
this
transformation
layer
and
that's
really
where
read-oriented
roll-ups
shine?
It's
not
so
much
about
the
user,
a
priority
having
an
expectation
of
how
they're
going
to
change
state
in
these
reoriented
roll-ups.
A
It's
more
that
the
users
can
have
taken
arbitrary
actions
in
the
past,
and
these
read-oriented
roll-ups
can
be
designed
around
the
data
that
already
exists
on
the
chain.
Importantly,
they
can
support
almost
all
of
the
design
patterns
that
we
see
today.
So
I've
talked
more
about
rollups
here,
but
the
validium
pattern
where
data
availability
is
handled
on
a
separate
layer
is
likely
where
subgraphs
will
need
to
go
to
support
nft
use
cases
in
the
decentralized
network
where
all
the
metadata
is
stored
on
ipfs
and
doesn't
have
layer,
1
data
availability
guarantees.
A
Importantly,
like
all
rollups,
these
are
composable
and
scalable.
So
you
in
the
same
way
that
you
can
have
validium
roll-ups
verified
in
an
optimistic
roll-up
or
in
a
zk
roll-up.
You
can
also
have
read-oriented
roll-ups
built
on
top
of
layer
ones,
other
layer,
twos
or
indeed
other
read-oriented
roll-ups
case
with
sub-graph
composition
and
some
of
the
data
pipelined
execution
models
that
you'll
hear
about
later
today,
and
this
composability
through
sharding
is
what
gets
us
the
scalability
benefits
of
rollups
right.
A
It's
that
each
person
can
focus
on
the
small
shard
of
computation
that
they're
interested
in
and
the
path
you
know
back
to
the
layer,
one
base
layer
and
when
we
think
about
scalability,
you
know
it's
not
just
scalability
in
a
vacuum
that
we
care
about.
It's
really
about
unlocking
more
use
cases
for
web3.
You
know.
A
The
other
benefit
to
read
oriented
rollups
is
that
they're
natively
provisioned
and
upgradable,
at
least
as
they
exist
in
the
graph,
because
it's
not
important
for
the
user
to
have
an
a
priori
mental
model
of
how
the
state
execution
is
going
to
happen,
and
it's
really
x,
post
definitions
of
the
derived
data.
You
can
upgrade
sub
graphs.
You
can
natively
provision
them
all
in
the
context
of
the
graph
using
the
curation
mechanism
that
you
need
walked
us
through
earlier,
but
we'd
be
remiss
if
we
didn't
talk
about
verifiability
right.
A
A
A
On
the
verifiable
query
side,
this
is
actually
something
that
we've
been
thinking
about
for
a
number
of
years.
This
is
a
screenshot
from
a
talk
that
I
gave
near
devcon.
We
weren't
quite
invited
to
speak
at
devcon
back
then
in
2018,
where
we
presented
this
idea
that
you
know,
maybe
we
could
look
at
the
database
indexes
that
are
in
use
today.
The
data
structures
that
are
used
to
power
those
indexes
and
can
we
just
come
up
with
mercalized
versions
of
those
indices?
A
A
A
Now,
verifiability
isn't
something
that
we're
just
doing
as
a
virtue
signal.
It's
not
just
something
we're
doing
to
check
the
box
of
being
a
protocol
in
in
web3.
We
think
this
is
going
to
have
a
meaningful
impact
on
the
use
cases
that
we
see
the
subgraphs
and
the
graph
applied
towards
you
know.
So
today,
most
use
cases
are
front-end
use
cases
right,
whether
it's
a
read-only
app
an
interactive
app,
some
kind
of
d5
front
end,
but
there's
a
host
of
on-chain
use
cases
that
the
graph
has
not
really
yet
been
applied
to
in
earnest.
A
You
could
imagine
a
subgraph
acting
as
a
reputation
oracle,
as
we
heard
from
yaniv
earlier
today.
You
could
imagine
it
being
used
as
a
price
oracle
or
some
kind
of
defy
aggregations.
You
could
even
imagine
it
implementing
urine
style.
You
know
automated
trading
strategies
where
the
output
of
the
strategy
is
bridged
back
on
to
the
layer,
one
or
the
lower
level
chain,
and
if
you
really
trust
the
verifiability
properties
of
the
graph,
you
could
even
imagine
using
this
in
a
cross-chain
state,
bridging
you
know
use
case
you
know.
A
So
today
we
tend
to
bridge
really
simple
state
across
chains
like
a
token
balance,
but
imagine
being
able
to
bridge
any
arbitrary
map
reduce
over
some
other
chain
onto
another
chain.
These
are
the
types
of
use
cases
that
become
available
to
us
once
we
take
earnest,
you
know,
effort
and
focus
on
verifiability.
A
Now
some
people
in
our
community
have
been
a
little
ahead
of
the
curve
on
on
testing
the
boundaries
of
what
possible
what's
possible.
This
is
a
experiment
that
denison
one
of
the
subgraph
developers
in
our
ecosystem
ran
last
year,
where
he
reimplemented
an
erc20
token
inside
of
a
sub
graph
using
the
subgraph
as
a
read
oriented
roll
up
where
basically
just
the
call
data
was
stored
on
chain
and
then
the
state
of
the
token
contract
was
basically
all
written
in
assembly
script.
A
Now
this
isn't
something
I'd
recommend
doing
today
with
the
security
model
of
the
graph.
But
this
is
the
kind
of
thing
that
would
become
trivial
to
do
once.
Verifiable
indexing
and
verifiable
queries
has
been
delivered
so
to
just
recap
really
quickly.
You
know:
right-oriented
read-ups
read
oriented
read-ups
many
of
the
same
considerations.
A
You
know
they
have
a
one
of
n
trust
model.
They
have
to
design
bridges.
They
take
advantage
of.
You
know
the
the
great
unbundling,
but
the
key
difference
is
that
right,
oriented
read-ups
are
transaction-oriented
state
machines,
whereas
read-oriented
roll-ups
are
arbitrary,
mapreduce
operations
and
they're
natively,
provisioned
and
upgradable.
A
Now,
admittedly,
over
the
last
few
years,
viewing
the
graph
as
a
blockchain
has
not
been
our
core
focus.
Although
I
do
want
to
give
a
shout
out
to
jackson.
Blizzenski
who's
really
kept
the
torch
burning
on
the
verifiable
queries
research
at
times
by
himself
and
was
integral
to
founding
the
cryptography
working
group
within
the
graph
ecosystem.
A
A
The
graph
in
particular,
I
think,
is
a
great
example
of
open
source
infrastructure.
So
a
lot
of
us
are
used
to
open
source
software,
where
one
developer
solves
a
problem
for
themselves
publishes
as
a
library.
Other
developers
can
build
on
that
remix
it
open
source
infrastructure
gives
you
all
the
same
benefits
but
for
actual
running
software.
So
when
someone
solves
a
problem
for
themselves
by
building
the
subgraph,
they've
now
solved
that
problem
for
everyone
else.
A
That
needs
to
use
that
type
of
data
and,
with
the
advent
of
subgraph
composition,
people
will
be
able
to
keep
building
on
and
remixing
with
the
logic
that's
already
been
published
to
the
graph
today.
So
over
time,
the
network
will
just
become
this
rich
tapestry
of
open
decentralized
apis
that
you
can
interact.
With
importantly,
the
service
providers
that
are
serving
these
apis
are
completely
open
and
adaptable.
A
That
means
you
know,
there's
no
centralized
entity
controlling
them,
they're,
responding
in
real
time
to
incentives
and
those
incentives
lead
them
to
do
things
like
auto
scale,
provision,
more
resources,
service,
different
geographies,
add
more
data
into
database
indices,
caching,
layers
to
optimize
their
setup.
All
of
that
sort
of
happens.
A
You
know
in
an
uncoordinated
decentralized
way
to
deliver.
You
know
a
superior
quality
of
service
to
the
end
user
and
the
last
benefit
I
want
to
focus
on
today,
because
it's
one
that
I
think
is
we've
had
some
interesting
progress
on
over
the
last
year
or
two
is
just
the
fact
that
the
graph
is
web.
Three
native,
and
I
want
to
highlight
a
couple
examples
of
what
that
means.
We
heard
from
a
couple
speakers
earlier
today
about
constitution
dao
running
on
juicebox,
which
deployed
to
the
decentralized
network.
A
I
think
it's
super
cool
that
you
can
actually
go
to
the
snapshot,
vote
for
the
juicebox
dow,
and
you
can
see
this
dow
provisioning
resources
to
power,
the
subgraph
that
they
used
to
drive
the
fundraising
platform
that
then
went
on
to
power,
the
constitution
dow
and
a
lot
of
us
that
have
participated
in
dao's.
You
know
we
may
lament
that
most
of
the
services
that
we
want
to
use
are
outside
of
the
trust
boundary
of
the
doubt
so
like
you
might
create
the
advocate
staff,
for
example.
A
But
then
that
advocate
style
needs
a
twitter
account
and
that
twitter
account
needs
to
be
owned
by
an
individual.
It
can't
be
owned
by
the
entire
doubt.
The
integration
points
are
there:
it's
not
web3
native,
but
when
you're
using
the
graph,
the
dow
can
natively
manage
and
control
their
subgraphs
using
the
permission
model
and
structure,
that's
been
built
embedded
into
the
dao.
A
Another
great
example
of
web3
native
capabilities
in
the
graph
is
the
fact
that
subgraphs
are
just
nfts
so
owning
the
subgraph
confers
a
number
of
really
important
rights
to
the
subgraph
owner.
You
can
do
things
like
upgrade
the
subgraph.
You
can,
you
know,
migrate.
The
curated
stake
on
that
subgraph
and
we've
heard
from
a
lot
of
users
that
hey
like.
Sometimes
you
want
to
have
you
know
an
individual
start
building
the
subgraph
then
transfer
it
to
a
dow.
A
Sometimes
you
might
be
working
with
the
dev
shop,
and
so
we
solved
that
problem
by
just
making
subgraphs
nfts
and
so
now
they're
digitally
native
transferable
ownable
items
they
can
integrate
with
d5.
You
could,
you
know,
use
it
in
all
sorts
of
you
know:
d5
composability
use
cases,
so
I
think
it's
a
fantastic
use
case
for
nfts
that
are
more
than
just
a
jpeg.
A
So,
let's
get
into
it
one
of
the
challenges
with
quality
of
service,
as
I
noted
before,
is
the
incredible
volumes
that
we've
been
processing
from
day
one,
but
you
know
most
recently
we're
it's
not
uncommon
to
be
over
a
billion
queries
per
day.
You
know,
so
that's
really
why
we
had
to
start
from
the
scalability
perspective
and
move
towards
verifiability
and
the
other
big
challenge
with
quality
of
service.
Is
that
it's
emergent?
A
A
We
can't
directly
observe
from
the
blockchain
what
the
you
know,
uptime
of
a
given
indexer
is,
and
despite
all
those
challenges,
quality
of
service
is
pretty
good,
like
you
can
see
here
that
on
many
days
the
the
decentralized
network
keeps
up
just
fine,
with
edge
and
node's
hosted
service
there's
even
times
when
the
edge
of
node
hosted
service
has
had
significant
outages
and
the
decentralized
network
has
been
more
robust,
but
pretty
good.
It's
not
good
enough
right,
we're
operating
in
the
space
where
people
are
comparing
the
graph
to
web
2
analogs.
A
A
And
importantly,
when
I
talk
about
negotiation,
I'm
not
talking
about
two
humans,
you
know
sitting
at
a
table
negotiating
with
each
other.
Hey.
How
much
is
this
query
going
to
cost?
That's
worth?
Fractions
of
you
know
a
fraction
of
a
penny
that
would
introduce
so
much
mental
transaction
overhead
that
it
would
completely
obviate
all
the
benefits
that
we
get
from
a
decentralized
infrastructure
layer.
A
On
the
indexer
side,
we
have
the
indexer
service
that
sets
prices,
and
we
also
have
the
indexer
agent
that
decides
which
sub
graphs
to
even
index
in
the
first
place,
and
I'm
excited
to
announce
that
this
week
we're
launching
two
brand
new
tools
for
indexers,
one
called
automated
agora
and
the
other.
That's
an
allocation,
optimization
tool
and
those
will
be
available
in
beta
to
try
out
at
graph
hack
this
weekend.
A
A
Now,
when
it
comes
to
using
agents
as
a
consumer,
you
know,
maybe
the
indexers
can
handle
it,
but
most
consumers.
This
is
kind
of
a
new
pattern
right,
we're
not
used
to
having
robots,
make
decisions
on
our
behalf.
In
fact,
quite
the
opposite.
We're
used
to
technology,
giving
us
information
that
we
can
then
use
to
make
decisions,
but
here
we're
flipping
the
script
here.
We
need
a
way
of
representing
what
users
want,
so
that
agents
can
make
automated
decisions
on
their
behalf.
A
It
feels
equally
terrible,
and
so
we
shaped
utility
curves
based
on
these
sort
of
notions
of
the
value
of
performance,
and
then
the
trick
is
how
do
we
give
the
power
to
users
to
actually
express
how
much
things
like
performance
cost
of
service
data
freshness
how
much
these
things
mean
to
them?
So
this
is
a
screenshot
from
the
subgraph
studio,
where
the
subgraph
developer
can
modify
an
api
key
to
decide
which
of
these
things
they
want
to
value
and
then
into
that
experience,
we're
building,
reporting
tools
and
predictive
analytics
to
help
them
understand.
A
A
Another
big
driver
of
performance
is
just
the
number
of
indexers
on
a
subgraph,
as
you
might
imagine,
more
indexers
on
a
subgraph
means,
there's
more
likely
to
be
a
high
quality
indexer
with
good
uptime,
the
data
freshness.
You
need
in
the
geography
that
you
want,
and
so
another
big
portion
of
our
focus
has
been
on.
How
do
we
drive
the
number
of
indexers
on
a
sub
graph
up?
A
Interestingly,
a
grant
from
the
graph
foundation
to
the
economic
auditing,
firm
prism
group
included
equilibrium
analysis
that
related
the
number
of
indexers
on
a
subgraph
to
indexing
rewards.
Basically,
the
square
root
of
indexing
rewards
over
the
fixed
costs
of
servicing
that
sub
graph,
and
so
there's
this
inverse
relationship
between
the
fixed
costs
that
indexers
have
to
pay
to
service
a
subgraph
and
the
number
of
indexers
we'd
expect
to
service
a
given
subgraph,
and
that
brings
me
to
the
next
section,
the
next
pillar
of
success,
which
is
cost
of
service.
A
Cost
of
service
in
the
graph
today
has
two
main
components.
One
is
indexing
performance
which
I'm
not
going
to
spend
a
ton
of
time
on
in
this
talk,
because
there's
going
to
be
a
great
talk
by
sebastian
later
today,
as
we
mentioned
that
I
highly
encourage
you
stick
around
for
the
other.
Big
driver
of
cost
is
on
chain
gas
costs.
A
To
give
you
a
recap
of
where
we're
at
today
in
the
network
to
upgrade
a
subgraph,
these
are
april,
averages
costs
about
100.
So
if
you're
a
subgraph
developer,
let's
say
upgrading
your
subgraph
a
couple
times
a
month.
That's
you
know
close
to
200
and
then
the
costs,
the
gas
cost,
that
an
indexer
has
to
pay
to
service.
That
subgraph
for
about
a
month
is
upwards
of
a
hundred
dollars
and,
as
we
just
talked
about
more
subgraphs
excuse
me,
more
indexers
on
a
subgraph
is
better
than
less
indexers.
A
So
if
we
say
four
is
the
magic
number
well
now
we're
up
to
four
hundred
and
twenty
dollars
a
month,
and
so,
if
you're
keeping
count
we're
at
600
total
for
a
subgraph
upgraded
twice
a
month
and
that's
all
just
gas
right,
that's
not
value!
That's
going
to
the
bottom
line
of
indexers.
That's
not
value!
A
We
feel
that
at
this
stage
in
the
game,
garbage
from
one
has
proven
itself:
it's
been
battle
tested.
It
has
several
billion
dollars
in
total
value
locked.
It
has
prominent
projects
that
have
migrated.
It
migrated
to
it,
including
projects
like
live,
pier
that
have
very
similar
requirements
and
economic
considerations
as
the
graph
to
give
you
a
sense
of
the
impact
that
this
is
going
to
have
on
the
network.
A
A
A
A
A
Four,
we
hope
is
that
over
time,
l1
just
becomes
a
ghost
town.
It'll
continue
to
be
there
if
we
need
it,
but
we
fully
expect
that
as
the
assumptions
around
layer,
two
and
people
will
get
comfortable
with
it
from
a
user
perspective
that
all
graph
usage
will
just
move
to
garbage
from
layer.
Two,
to
give
you
a
quick
idea
of
the
estimated
timeline,
noting
that
it's
always
hard
to
make
estimates
in
a
decentralized
open
source
environment.
A
And
for
us
developer,
experience
really
starts
with
the
subgraph
studio,
where
we
do
things
like
give.
You
subgraph
developers
tools
for
api
key
management.
The
preferences
that
I
showed
you
earlier.
We
have
the
subgraph
studio
sandbox,
where
you
can
deploy
and
interact
with
the
subgraph
locally,
all
without
you
know,
first
having
to
acquire
grt
or
interact
with
the
blockchain,
but
there's
limits
to
what
we
can
do
just
on
the
front
end
with
developer
experience
at
a
certain
point,
we're
constrained
by
the
economics-
and
let
me
give
you
a
few
examples
of
that.
A
A
So
on
this
front,
we
actually
have
an
exciting
announcement
well
exciting
if
you're,
a
wonkish
protocol
economics
type
that
we
call
principal
protected,
bonding
curves
and
without
getting
too
much
into
the
weeds.
These
are
mev
proof
bonding
curves,
that
preserve
some
of
the
earlier
is
better
dynamics
of
traditional
bonding
curves,
but
where
the
user
doesn't
incur
any
principal
risk
by
interacting
with
the
bonding
curves,
I
highly
recommend
you
check
out
the
gip
in
the
forums
if
you're
interested
in
learning
more.
A
A
One
of
the
other
pieces
of
feedback
we
hear
from
subgraph
developers
is
that
it's
you
know.
Sometimes
they
have
a
preference
for
modularity
for
performance
and
upgradeability
purposes,
and
when
you
do
that
in
the
decentralized
network,
that
means
now
you've
gone
from
interacting
with
two
bonding
curves
to
10,
bonding
curves,
all
as
a
part
of
your
normal
development
cycle.
A
It's
now
safe
to
let
subgraph
developers
rent
signal
some
amount
of
time
and
with
the
lower
l2
gas
costs,
it's
now
cost
efficient
for
them
to
top
off
their
subscriptions
on
a
regular
basis,
whether
it's
monthly,
quarterly
annually.
The
same
way
you
would
expect
when
using
a
traditional
sas
or
web
2
cloud
infrastructure
provider
and
just
to
give
you
the
an
example
of
you
know,
just
the
the
impact
that
we
expect
us
to
have
was
a
quote
from
brandon
from
pull
together
the
cto
there.
A
A
A
So
if
you're
interested
in
diving
deeper
on
any
of
these
topics,
you
know
we've
already
heard
about
the
five
different
working
groups.
Today,
I
highly
recommend
you
checking
out
the
roadmap
that
was
published
a
few
months
ago,
hop
onto
forums
dive
into
these
different
gips.
There's
really
so
much
incredible
work
happening
here
and
we've
really
just
scratched
the
surface,
and
I
want
to
give
a
shout
out
to
all
the
new
core
developers
that
have
joined
our
ecosystem
since
the
last
graph
day.