►
From YouTube: The Graph's Testnet: Curators Phase 2 Workshop
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
welcome
everyone
to
phase
two
of
the
curator
program.
We
hope
you
had
a
fantastic
phase
one
and
enjoyed
it
as
much
as
we
did.
I
can
say
from
myself
and
the
graph
team
we
are
just
so
humbled
shocked
impressed
with
the
interest
that
you
guys
have
had
in
both
learning
about
the
graph
and
also
elevating
everest.
A
Just
a
few
stats
to
share
so
everest
currently
has
over
1600
projects.
It's
incredible.
You
know
we're
really
looking
at
the
entire
web
3
ecosystem
and
we
hope
you
continue
to
add
to
it
ethereum
base
and
other
blockchains
as
well.
In
terms
of
submissions
for
phase
one.
We
had
1400
1400
yep.
We
had
over
400
mission
control,
curator
issues
and
over
37
prs.
A
We
also
had
several
bots
made,
which
is
really
awesome,
so
one
was
for
telegram
and
for
discord.
We
had
hundreds
of
translations
really
awesome
to
see
how
global
our
community
is,
in
particular
in
russia
and
japanese
we've
also
had
hundreds
of
thousands
of
memes
made
the
graph
team
every
single
day,
we're
sharing
between
our
team.
These
incredible
memes
of
our
team,
of
how
you
guys
are
interpreting
the
vision
and
it's
so
exciting
to
see
the
community
growing.
We've
also
had
a
few
discord
mvps.
A
We
want
to
shout
out
so
king
z,
slim
chance,
booby
and
traitor
pain.
You
guys
have
been
incredible,
keep
it
up
and
we
look
forward
to
hearing
more
from
you
in
phase
two.
So
now
I'll
pass
it
off
to
yaniv
our
founder
to
speak
more
about
evaluating
subgroups.
B
Yeah
thanks
eva,
so
I
actually
want
to
start
just
with
a
quick
recap
of
phase
one.
So
I
personally
went
through
everybody's
issues
that
you
created
in
the
everest
repo
in
the
mission
control,
curator
repo,
and
it
was
really
amazing
to
see
just
how
much
people
really
understood
the
vision-
and
you
know
hopefully,
you've
had
a
chance
now
to
you
know,
create
a
project
on
everest
browse.
B
Maybe
do
some
challenges
and
you
know
I
think,
we're
at
a
a
really
remarkable
place
now
with
you
know
the
1600
projects,
so
you
know
really
great
a
starting
point,
so
appreciate
everyone
who
you
know,
challenged
projects
and
and
were
active.
B
I
think
it's
pretty
clear
that
there
are
some
things
that
have
been.
You
know
rough
around
the
edges,
and
so
there
were
some
really
great
suggestions
in
the
issues
on
github
for
improvements
to
make.
B
So
so
things
like
you
know,
I
know
that
the
the
the
challenge
and
claiming
flows
right
now
are,
you
know
a
little
bit
difficult
and
it
would
be
much
better
if
you
could
get
like
a
notification,
for
example,
if
you're
the
project
owner
and
somebody
wants
to
claim
it,
you
know
you
really
should
get
like
a
push
notification
and
be
able
to
take
action
right
away.
So
you
know
clearly
that
would
be
an
improvement.
B
There
were
some
really
great
discussions
about
how
reputation
is
assessed
right
now
we
calculate
reputation
just
based
on
how
long
you've
been
on
the
registry,
but
there
were
some
really
great
ideas
about
other
ways
that
you
could
do
reputation
and
and
and
generally
there
were
just
you
know-
a
lot
of
really
great
suggestions.
B
So
you
know,
I
hope,
people
you
know,
keep
thinking
about
how
to
improve
something
like
this
and
and
recognize
that
you
know
this
is
a
pretty
simple
flow
that
we're
doing
here,
just
allowing
people
to
create
projects
and
challenge
projects
and-
and
really
you
know,
maintain
a
quality
registry,
and
you
know
if
we
continue
to
iterate
on
this
and
make
these
types
of
improvements,
then
I
think
we'll
we'll
have
a
really
great
template
that
we
can
use
for
lots
and
lots
of
of
different
registries,
and
you
know
I
could
see
many
thousands
of
these
types
of
registries.
B
B
B
So
you
know
people
had
a
lot
of
ideas
of
you
know
more
data
that
they
would
want
to
have
linked
to
these
projects.
So,
for
example,
you
know
being
able
to
see
the
assets
that
a
project
has
created,
or
maybe
you
know
the
dows
associated
with
the
project
or
the
team
members
or
you
know
it
really
just
goes
on
and
on,
and
so,
if
you
start
with
the
data
model
in
mind,
then
you
can
think
about.
B
Where
is
this
data
going
to
come
from
and
maybe
there's
an
existing
protocol
that
you
want
to
get
the
data
from?
And
so
in
that
case,
all
you
need
to
do
is
create
a
sub
graph
to
index
that
data
and
bring
it
onto
the
graph.
B
Maybe
it's
you
know
simple
data.
You
know
like
these
everest
projects
and
the
right
solution
is
a
registry
just
like
this.
You
know
a
kind
of
curation
gap,
just
a
registry
that
that
people
can
can
vote
on.
But
you
know
something
like
projects.
You
know
we're
kind
of
bootstrapping,
this
kind
of
social
consensus
over
who
should
own
the
project
listing
and
then
once
somebody
owns
a
project
listing.
B
Maybe
that
gives
them
rights
to
create
data
without
having
other
people
challenge
it,
because
they're,
basically
like
the
source
of
truth
for
that
project.
So
you
know
if,
if
I
own,
you
know,
if
we,
if
we
hop
into
governance-
and
I
own
you
know
colony-
maybe
I'm
the
source
of
truth,
then
for
who
the
the
teammates
right,
the
team
members
of
the
colony
project
are,
and
so
that's
not
subject
to
challenge.
B
So
you
know
these
types
of
rules
are
really
going
to
depend
based
on
the
domain
and-
and
so
I
think
you
know,
these
experiences
will
be
very
customized,
and
sometimes
the
solution
to
managing
data
in
a
decentralized
way
is
going
to
be
a
registry,
and
sometimes
it
might
be
like
a
really
complex
protocol.
And-
and
the
answer
is
you
know.
B
First,
we've
got
to
build
a
protocol
on
a
blockchain
like
ethereum,
and
then
you
can
build
the
sub
graph
behind
it,
but
I
think
it's
an
interesting
lens
to
kind
of
start
with
the
data
model.
You
know
what
data
do
we
want
to
have
on
the
graph
curated
in
a
decentralized
way
and
then
from
there
work
through?
B
B
And
you
know
we've
been
working
on
this
now
for
a
while
and
we've
experimented
with
different
ways
of
incentivizing
people
to
build
subgraphs.
So
you
know,
we've
participated
in
a
lot
of
hackathons
things
like
the
eth
global
events
and
then
we've
also
hosted
our
own
hackathons.
B
So
this
is
one
that
we
did
last
december
called
indexing
the
new
economy
and
we
had
prizes
for
people
to
build
sub
graphs,
and
for
this
one
we
decided
to
have
specific
sub
graphs
that
we
wanted
to
have
built
for
protocols
that
were
built
on
ethereum,
and
we
focused
this
one
on
on
defy
protocols,
and
these
were
ones
where
you
know
we
didn't
have
good
subgraphs
yet,
and
you
know,
I
think
this.
This
was
a
really
fun
event.
We
had
a
lot
of
participation.
B
We
got
some
great
sub
graphs,
built
and
part
of
what
we
did
here
was
come
up
with
a
list
of
requirements
so
that
developers
that
wanted
to
build
these
sub
graphs
could
get
a
sense.
For
you
know
the
complexity,
and
you
know
what
it
was
that
we
were
looking
for
out
of
these
sub
graphs.
B
So
here
you
can
see
you
know
our
best
attempt
to
estimate.
You
know
the
prizes
that
you
know
would
be
worth
paying
out
for
developers
to
build
these
subgraphs
and-
and
this
is
something
that
we
did
kind
of
you
know
in
a
centralized
way.
You
could
say
where
we
single-handedly
like
chose
hey.
You
know
these
would
be
subgraphs
that
are
valuable.
Here's
roughly
how
much
work
we
think
it
would
be
to
build
these
subgraphs
now
going
into
the
future.
B
This
is
the
kind
of
thing
that
we
would
love
to
see.
You
know
done
in
a
decentralized
way
where
you
know
curators,
you
know,
are
closest
to
the
ground
they're
involved
with
different
projects
and
protocols,
and
you
know
you
would
probably
be
in
the
best
position
to
know
which
subgroups
would
be
valuable
to
the
community,
and
so
you
know,
there's
you
know
a
skill
here
in
being
able
to,
you
know,
identify
subgraphs
that
need
to
be
built,
be
able
to
scope.
B
You
know
how
difficult
would
it
be
to
build
this
type
of
subgraph
and
you
know
how
valuable
would
it
be
to
the
community
and
then,
similarly,
you
know
a
job
of
a
curator
is
to
evaluate
existing
subgraphs.
So
maybe
there
are
some
graphs
that
are
already
deployed.
You
know
now
on
the
hosted
service
in
the
future
on
the
network
and
maybe
there's
like
really
important
data.
B
That's
missing,
or
maybe
some
data
is
inaccurate,
so
the
ability
to
dive
in
assess
the
quality
of
subgraphs
see
what
improvements
need
to
be
made
and
then
ultimately
organize
resources
you
know
to
deploy.
You
know
the
protocol
treasury
to
fund
the
development
of
new
subgraphs
is
is
going
to
be
a
really
key
component
of
being
a
curator,
so
we're
going
to
have
dave
go
through
and
give
you
more
of
a
starting
with
an
introduction
of
you
know
what
sub
graphs
are
more
in
depth.
B
I
know
we've
done
this
at
a
high
level,
but
now
we're
actually
going
to
dive
in
and
then
explain
how
to
go
about
evaluating
different
subgraphs.
C
So
what
I'm
going
to
go
over
is
you
know,
kind
of
like
subgraphs
that
already
exist
in
the
network
and
I'm
gonna
go
a
little
bit
in
depth
on
how
they
work
and
how
you
can
actually
evaluate
them.
C
How
complex
they
are
kind
of
looking
at
blockchain
data
and
determining
what
subgraphs
could
be
built
in
the
future
and
just
going
into
all
the
details
of
what
it's
like
to
be
a
curator
and
also
what
it's
like
to
be
a
subgraph
developer,
or
else
evaluates
subgraph
developers
who
have
created
subgraphs-
and
you
know
a
really
a
really
good
place
to
start
is
just
the
explorer.
I'm
sure
you
guys
have
seen
this
before
it's.
You
know
it's
right
on
our
website
and
it's
just.
C
This
is
where
you
can
see
a
lot
of
the
featured
sub
graphs
that
are
very
popular
in
the
community,
and
you
may
have
heard
of
a
lot
of
these
projects
and
it's
a
really
good
idea
to
just
like
go
into
these
and
kind
of
look
at
them
and
check
out.
What's
going
on
and
uniswap's,
actually
one
that
we're
going
to
look
at
a
little
bit
later.
C
But
the
first
place
that
I
would
like
to
start
is
just
like
a
primer
with
the
documentation,
so
the
documentation
on
our
website
is
very,
like
all,
encompassing
and
will
teach
you
everything
you
need
to
know
about
the
graph,
but
for
this
specific
tutorial
that
I'm
giving
here,
I'm
just
gonna
really
go
over
like
the
high
level
stuff
about
defining
what
a
sub
graph
is.
C
So
there's
always
three
parts
of
a
subgraph
that
I
really
think
are
like
the
main
key
components
when
you
want
to
describe
it
at
a
high
level
and
the
first
one
is
the
subgraph
manifest
and
the
way
that
I
always
think
about
the
subgraph
manifest.
Is
it's
like
the
instruction
book
or
like
the
instruction
manual
for
the
graph
node
and
for
the
graph
network
to
know
what
data
to
actually
index
from
a
blockchain
or
from
ethereum
right?
So
this
is
you
know
this
is
a
very
simple
file
right
here.
C
It's
it's
just
these
lines
right
here,
it's
very
easy
to
read,
and
it's
very
straightforward,
and
what
I
want
to
point
out
is
some
of
these
really
key
components
here
is
like
so
this
line
right
here
is
telling
us
look
at
the
ethereum
mainnet
for
some
blockchain
data
that
we
want
to
look
at,
and
then
we
start
drilling
down
even
more,
and
it's
like
go
to
this
address
on
the
ethereum
mainnet,
and
this
is
the
one
that
we're
concerned
about.
C
This
is
the
one
that
we
care
about
for
the
sub
graph
and
then,
when
you
drill
it
down
even
more,
you
start
to
pay
attention
to
the
specific,
like
events
that
are
emitted
by
that
contract
or
even
like
functions
that
are
called
on
that
contract.
So
what
the
whole
point
of
the
manifest
is,
is
it's
just
you
know
we
have
all
this
blockchain
data
out
there.
C
It's
all
kind
of
not
organized
very
well,
and
it's
all
just
like
on
the
on
ethereum
and
what
we're
telling
the
graph
note
to
do
is
focus
in
on
this
specific.
This
is
specific
network
on
the
specific
contract
on
these
specific
events
that
happen.
So
a
subgraph
manifest
can
actually
contain
a
lot
of
different
contracts.
C
You
can't
really
tell
how
complex
a
sub
graph
is
going
to
be
just
from
looking
at
this,
but
you
can
get
an
idea
that
you
know
you're
going
to
be
looking
at
the
uniswap
smart
contracts
and
this
in
this
case
it's
it's.
This
contract
called
gravity,
but
it's
kind
of
like
a
high
level
kind
of
like
introduction,
telling
you
what
this
subgraph
is
going
to
be
about
the
next
really
big
part
of
a
subgraph
is
the
graphql
schema.
C
So
if
you
don't
know
about
graphql
highly
remain
highly
recommend
like
looking
it
up
and
reading
our
docs
and
reading
their
own
documentation.
It's
a
really
good
querying
language
that
really
fits
itself
well
to
web
three,
and
it's
the
reason
why
we
chose
it
for
to
be
part
of
like
graph
notes
and
part
of
the
graph
network
and
how
it's
all
organized
and,
like
part
of
the
tech
stack-
and
you
know
really
briefly
not
to
get
too
into
details
on
the
code.
But
you
know
this
is
you
know
this?
C
Is
an
entity
in
a
graphql
schema
that
that
would
be
in
a
subgraph
right.
So
what
this
is?
It's
just
a
data
object
and
it's
actually
really
easy
to
read.
You
know
it's
it's
this
thing
called
gravatar,
but
it
has
an
owner
and
a
display
name
and
an
image
and
a
boolean
of
what,
if
it's
true
or
false,
if
it's
been
accepted
or
not,
so
anybody
can
kind
of
read
this
and
understand.
What's
going
on
and
we'll
we'll
look
at
a
much
larger
schema
very
soon,
but
basically
what
the
schema
is.
C
Compare
it
to
the
the
manifest
which
is
the
instruction
book.
What
to
look
at
on
the
blockchain
and
then
the
graphql
schema
for
a
sub
graph
is
basically
what
the
subgraph
developer's
idea
is
for
what
they
want.
Their
data
to
be
kind
of
like
presented
in
or
organized
in
a
way.
C
So
like
all
the
data
right
now
is
on
ethereum
and
it's
unorganized,
we've
told
the
graph
node
to
get
that
specific
data,
and
now
the
subgraph
developer
is
organizing
it
in
the
certain
kind
of
like
the
schema
that
they
want
with
the
entities
and
it's
gonna
basically
organize
the
database
in
like
that's
built
into
the
subgraph
into
that
order,
and
it
allows
this
data
to
be
easily
readable
from
people
from
the
outside.
C
C
C
You
know,
because
you
don't
even
really
have
to
know
how
to
write
code,
to
be
able
to
look
at
a
schema
and
understand
what's
going
on
because
it
should
be
human
readable
and
because
it's
this
open
api
that
other
people
are
supposed
to
be
able
to
come
to
and
be
able
to
tie
into.
So
you
know
if
you're,
a
curator
and
you're
trying
to
determine
the
complexity
and
the
usefulness
of
a
subgraph.
It's
definitely
the
graphql
schema.
C
That
is,
is
what
you
would
want
to
look
at
and
the
last,
like
really
big
part,
are
mappings,
and
I
won't
get
into
too
much
detail
on
these
today.
It
is
a
little
bit
more
complex
in
the
code
kind
of
that
you
have
to
understand
it's
all
written
in
typescript,
and
so,
if
you
know
typescript
or
even
if
you
know
javascript,
you
can
definitely
like
read
this
and
understand.
C
What's
going
on,
but
and
if
you
read
the
mappings,
it
will
be
able
to
tell
you
how
complex
a
subgraph
is
and
what
it's
doing,
but
at
the
end
of
the
day
like
what
the
mappings
are,
is
it's
kind
of
it's
basically
like
the
piping
between
the
subgraph
manifest
and
the
graphql
schema,
and
it's
it's
saying
like
the
subgraph
manifest
gives
you
the
raw
data
off
of
ethereum,
and
then
the
graphql
schema
is
what
the
subgraph
developer
wants
to
be
put
out
in
the
end
and
for
allowed
to
people
to
read
that
blockchain
data
and
the
mappings
are
what
like
kind
of
translates,
the
data
from
the
blockchain
into
the
subgraph.
C
C
Basically,
if
you
can
read
the
mappings
and
also
graphql
schema,
you
can
really
determine
what
a
sub
graph
does
and
how
complex
it's
going
to
be,
and
so
next,
what
I
want
to
do
is
I
want
to
really
get
into
the
unit
swap
subgraph.
Just
going
to
refresh
this
here
so
unit
swap
sub
graph
is
right
here,
it's
probably
one
of
the
most
popular
subgraphs.
C
It's
used
a
ton,
there's
so
much
data,
that's
coming
out
of
uniso,
because
it's
probably
the
most
popular
protocol
on
ethereum
and,
as
you
can
see
here,
on
the
right
side,
this
is
the
public.
You
know
the
graphql
schema.
These
are
all
the
basically
data
objects
that
the
subgraph
developer
decided
they
wanted.
You
know
to
be
available
and
and
they've
organized
it
in
a
way
that
makes
this
sub
graph
unique
like
this
subgraph
is.
C
I
don't
like
this
specific
unit
swap
subgraph
has
a
lot
to
do
with
like
data
analytics
and
also
like
aggregating
data,
because
this
is
actually
the
website
that
gets
powered
by
the
uniswap
subgraph.
So
this
is
the
uniswap
subgraph.
This
is
called.
You
know
this
is
the
playground
on
just
on
the
on
the
explorer
and
you
can
see
like
we
have
a
query
over
here
on
the
right
side.
We're
asking
for
data
about
tokens,
we're
asking
for
data
about
the
human
swap
factory
and
the
subgraph
actually
has
all
this
data.
C
You
know
this
is
blockchain
data
that
has
been
indexed
and
organized
with
the
sub
graph
and
now
is
very
easily
queryable
and
also
very
fast
to
query,
which
is
one
of
the
huge
improvements
that
sub
subgraphs
give,
and
it's
part
of
the
reason
why
the
graph
network
exists.
It's
this
big,
like
middle
middleware
kind
of
protocol
that
allows
all
this
data
to
be
to
be
stored
and
indexed
by
the
graph
and
for
people
to
be
able
to
easily
query
it
and
actually
see
what's
going
on
on
the
blockchain.
C
I
want
to
also
get
into
how
complex
you,
the
uniswap
subgraph
is,
and
that's
basically
what
I'm
going
to
be
breaking
down
over
the
next
10
minutes
and
for
anybody
who
doesn't
know
unit
swap
I
just
want
to
really
quickly
show
you
that,
like
this
is
basically
the
uniswap
application
and
it's
a
really
simple
app
like
the
main
two
functions,
are
adding
liquidity,
basically
providing
like
tokens
to
for
people
to
be
able
to
trade
off
of
in
a
pool
and
then
swapping
one
token
back
and
forth,
so
you
might
swap
like
each
between
die.
C
So
this
is
like.
If
you
look
at
this
application,
you
realize
right
away
that
there's
not
too
much
complexity
and
it's
actually
built
to
be
simple
right.
C
As
you
know,
like
wrapped
ether,
and
you
can
see
here
like
we
have
this
aggregate
data
of
how
much
volume
is
actually
being
transacted
on
chain.
So
this
data
isn't
actually
stored
directly
in
you
know
the
uniswap
smart
contracts.
This
is
aggregated
data
that
is
created
by
the
sub
graph,
that
this
subgraph
developer
recognizes.
Useful
information,
like
people
really
do
want
to
know
how
much
volume
unit
swap
is
creating
each
day
for
each
token
pair.
C
They
also
want
to
know
the
usd
price
of
all
the
tokens,
as
well
as
the
price
in
ether,
and
they
also
want
to
see
like
how
how
is
unswapping
growing
over
the
last
three
four
months.
All
this
data
is
is
very
rich
data
that
was
created
by
the
subgraph
developer,
and
it
was
basically
it's
what
the
sub
wrap
does
it's?
What
makes
the
subgraph
very
useful
and
very
unique?
C
So
now,
I'm
actually
going
to
get
a
little
bit
more
into
the
swap
sub
graph
itself,
and
this
is
going
to
be
very
high
level,
but
I
kind
of
want
to
go
over
like
how
you
determine
what
a
sub
graph
is
and
how
complex
it
is
so
really
really
quickly.
I
just
want
to
open
the
main
uniswap
smart
contract
code,
and
here
we
have
like
there's
only
about
200
there's
three
files
and
in
total
these
three
files
are
about
350
lines
of
code.
C
So
like
right
away,
you
know
you
saw
the
the
front
end
interface
and
the
application.
It
was
pretty
simple
and
then
you
kind
of
look
at
the
solidity
code.
You
don't
even
have
to
read
it,
but
it
is
readable
if
you
don't,
if
you
don't
know
code,
but
essentially
you
look
at
this
you're
like
okay.
This
protocol
is
not
that
complex.
You
know
it
has
a
good
chance
of
being
a
simple
subgraph.
C
You
can't
glean
all
that
information
from
this,
but
it's
like
a
good
indicator
of
the
fact
that
the
subgraph
might
not
be
that
complex.
It
might
not
be
that
big,
and
so
you
know
that's
the
uni
swap
smart
contract
code.
I'm
not
going
to
go
into
detail
on
it
here.
What
I
will
go
into
a
little
bit
more
detail
on
is
the
the
actual
sub
graph
files
we
have
for
it.
C
We
have
these
things
called
data
source
templates,
and
so
the
ethereum
or
the
uniswap
factory
makes
you
know
a
pair
of
tokens
that
are
being
traded.
It
might
be
ethereum
and
like
die,
and
then
each
of
these,
each
of
these,
like
templates,
is
going
to
be
made
for
each
of
those
pairs
and
then
what's
happening
is
like
this.
Subgraph
is
indexing.
C
These
five
events
on
these
token
pairs
that
are
trading-
and
this
is
really
the
bulk
of
all
the
information
that
we're
we're
getting
from
ethereum.
This
is
pretty
much
going
to
be
most
of
the
whole
entire
subgraph
and
we're
going
to
do
a
lot
of
like
data
analytics
with
all
this
and
kind
of
organizing
of
the
data.
C
C
And
if
you
look
at
it
it
is
it's
very
human
readable.
You
don't
have
to
know
the
code
to
understand.
What's
going
on,
you
know
we
have
like
a
specific
token
and
you
can
imagine
exactly
what
that
is.
We're
gonna
have
how
many
times
this
token's
been
traded.
The
total
liquidity
that
is
stored
in
unispot.
For
this
token,
the
trade
volume
over
time,
the
trade
volume
in
usd-
and
so
you
have
all
this
kind
of
stuff.
It's
actually
pretty
easy
to
read
and
understand.
You
can
kind
of
see
okay.
C
You
know
this
is
probably
a
uniswap
sub
graph
and
it's
probably
doing
a
lot
of
data
analytics
just
by
reading.
You
know
the
names
that
the
subgraph
developer
has
given
to
all
the
entities
in
the
entities
fields,
and
so,
if
you
look
at
some
of
these
things,
this
is
going
to
get
like
a
little
bit
more
in
detail
about
looking
at
a
at
a
schema
like
a
graphql
schema.
C
A
lot
of
these
fields
like
right
here
are
just
direct
direct
values
that
are
admitted
by
ethereum
events,
and
it's
actually,
whenever
you
see
that
and
we're
just
copying
over
static
data
from
the
blockchain
into
the
sub
graph,
it's
kind
of
a
good
signal
that
it's
going
to
be
a
pretty
simple
subgraph,
because
it's
not
hot,
it's
not
hard
to
copy
over
data.
What
what
is
hard
is
to
like
build
those
charts
so
like
this
chart
very
complex
to
build,
took
the
subgraph
developer
a
lot
of
time
to
get
done.
C
But
if
you
look
at
something
like
this,
a
transaction
like
this
is
just
a
transaction
that
happened
on
ethereum.
It's
just
kind
of
storing
these
static
values.
You
know
you
could
go
to
ether,
scan
and
see
this.
If,
if
that's
all
the
developer
did
was
the
uniswap
transactions,
then
it's
going
to
be
a
very
simple
subgraph.
So
that's
something
to
note
is,
like
you
know,
there's
there's
not
one
unit
sub
graph.
There
is
a
bunch
of
data
on
uniswap
and
you
can
decide
what
your
uniswap
subgraph
is
going
to
be
so
like
this
developer.
C
Their
main
goal
was
for
it
to
be
like
an
analytics
subgraph
and
that's
what
it
does.
So
I
would
actually
what
I
would
say
like
this,
this
sub
graph
itself.
The
complexity
is
like
medium
to
medium
hard
and
the
reason
it's
because
it's
doing
all
this
aggregate
data
and
if
you
kind
of
look
at
the
you
know
if
you're
reading
the
use
or,
if
you're,
reading
the
schema
right
here,
you
see
this
stuff
like
pair
hour
data
and
paired
day
data
which
I'm
not
yeah
per
day.
C
C
One
of
those
transactions
adds
to
this
value
and
then
they'll
figure
out
how
much
has
been
done
in
that
day.
So
they
take
like
a
24
hour
period
depending
on
like
the
timestamp
of
of
the
the
blockchain
and
like
the
blocks
that
are
being
created
on
ethereum
and
they're
aggregating
all
this
data.
C
So
all
of
a
sudden
you
can
see
the
subgraph
has
just
gotten
a
lot
more
complex
because
we
have
aggregate
data
and
not
only
are
we,
you
know
adding
it
up
to
show
it
in
this
kind
of
nice
chart
or
this
kind
of
table
right
here.
It's
also,
you
know
we're
building
these
charts.
So
that's
why
I
say
it's
medium
hard.
This
subgraph,
you
know
the
first
thing
was
when
I
looked
at
the
smart
contract
code,
I
kind
of
thought
you
know
350
lines
of
solidity.
This
is
not
that
complex.
You
know.
C
C
So,
very
briefly,
I
want
to
go
over
the
mappings
as
well.
So,
like
I
said,
this
is
kind
of
the
piping
between
the
subgrip
manifest
and
then
getting
the
graph.
The
the
data
to
be
in
the
schema
that
you
have
and,
as
you
can
see,
the
mappings
are
are
a
lot
of
code
like
this
one
file,
you
know
600
lines
of
code
200
about
100
there.
C
And
so
really
here.
This
is
there's
a
lot
of
details
in
here.
So
if
you're,
if
you're
like
a
developer-
and
you
know
javascript
or
typescript,
you
should
be
able
to
read-
you
know
these
files
and
understand.
What's
going
on,
you
also
obviously
have
to
understand
what
new
swap
does,
but
essentially
yeah
like
this.
C
This
is
the
the
most
complex
part
of
the
subgraph.
Luckily,
because
unit
swap
is
kind
of
a
simple
protocol,
that's
why
I
would
call
it
like
medium
hard
and
so
as
like
as
a
somebody
who's.
You
know
I
kind
of
described
the
last
10
minutes
from
the
perspective
of
a
subgraph
developer.
C
You
know
some
some
graph
tokens
to
in
order
to
say
like
I
think
this
sub
graph
is
of
high
value
for
a
lot
of
people,
and
so,
if
you
look
at
the
uniswap
subgraph,
we
like
you
know
we
just
explored
it,
and
it
says
right
here,
historical
data
for
analytics.
C
You
might
realize
that
you
like
uniswap,
is
a
very
big
decentralized
exchange
and
there
actually
are
a
lot
of
tokens
that
are
only
traded
on
uniswap
and
so
some
of
the
big
websites,
like
coin
gecko
and
like
coin
market
cap,
actually
tie
into
uniswap
to
get
price
information
so
like
price
information
for
uniswap
is
very
high
quality
high
sensitive
data,
because
people
make
trades
on
that
decisions.
People
actually
have
money
involved
on
what
the
prices
are
from
some.
C
If
they're
hitting
the
unit
swap
api,
so
as
a
curator
or
else
somebody
who's
like
a
curator,
slash,
subgraph
developer,
you
might
look
at
this
and
say:
well,
you
know,
maybe
somebody
should
make
a
uniswap
subgraph.
That
is
just
specifically
about
price
feeds,
and
then
that
would
be
a
simplified
sub
graph
would
be
more.
C
It
would
have
less
area
for
errors,
because
it's
only
doing
one
thing
and
then
maybe
even
like
coin
gecko
would
end
up
tying
into
it
and
so
like
if
you
saw
that
one
come
up
and
you
are
a
curator
and
you
recognize
that
kind
of
business
scenario
where
you
know,
price
data
is
super
important
and
that's
true.
For
for
all
protocols
on
ethereum
like
if
you
want
to
look
at
compound
or
other
protocols,
you
know,
price
is
always
going
to
be
very
valuable
because
that
has
to
be
accurate.
C
And
so,
if
we
look
at
the
everest
code,
I
want
to
quickly
just
open
up
the
everest
smart
contract.
C
Maybe
it's
going
to
be
more
complex,
but
if
you
also
look
at
everest
right,
it's
basically
a
registry
of
projects
and
it
has
voting
and
challenges
and
those
are
kind
of
the
three
main
functions.
So
it's
also
like
uniswap
in
the
sense
that
it's
a
very
simple
application
right
and
that's
the
way
that
everest
was
meant
to
be
built.
C
It
was
supposed
to
be
simple
and
it
was
supposed
to
like
champion
what
it's
like
to
be
a
fully
decentralized
web
3
application,
and
so
you
know
that,
like
you
know,
the
dap
itself
has
about
three
functionalities.
You
look
at
the
code,
it's
750
lines
of
code,
you're,
saying:
okay
like
how
how
complex
is
the
subgraph
and
what
does
it
do
exactly
so
then
we're
going
to
go
and
look
at
the
actual
subgraph
code
again,
and
so
that's
the
manifest.
C
C
And
if
we
look
at
the
mappings
here,
the
mappings
for
everest
are
actually
a
lot
shorter,
and
this
is
what
I
was
kind
of
talking
about
like
that
static
data
that
one-to-one
data
like
what
I'm
doing
here
is,
is
just
basically
copying
over
data
from
ethereum
and
putting
it
into
my
own
schema.
My
my
voting
entity.
My
voting
object
data
object
that
I
made
I'm
kind
of
just
copying
it
over
and
the
good
thing
is
like.
C
I
wrote
the
the
smart
contracts
for
everest,
so
I
also
knew
in
my
head
what
they
were
gonna
look
like,
and
this
made
it
easier
for
me
to
actually
write
the
subgraph.
It's
a
little
bit
different
when
somebody
else
developed
like
someone
else,
did
the
uniswap
protocol
right.
But
if
I
write
the,
if
I
write
the
subgraph
for
it,
I
have
to
recognize
what
the
protocol
is
doing
and
I
have
to
kind
of
study
it
myself
to
determine
what
the
mappings
are
going
to
do.
C
But
anyhow,
like
this,
this
set
of
mappings
it's
about
200
lines
and
then
there's
also
like
a
helper,
a
helper
file
with
100.
But
I
look
at
it
and
it's
it's
not
too
complex,
it's
not
too
long,
and
then,
if
I
look
at
the
actual
schema,
I
realize
it's
also
pretty
short,
and
then
you
start
reading
it
right.
Even
if
you
didn't
really
know
what
everest
was
you
read
it
and
you're
like
okay,
it's
got
a
description.
It's
got
a
website.
C
It's
got
a
twitter
handle
it's
like
very
high
level
kind
of
it's
some
sort
of
project
or
like
account
that
somebody's
displaying
we're
just
we're
storing
what
time
it
was
created
at.
So
you
start
to
get
this
image
in
your
head.
You're
like
okay,
this
isn't
too
complex.
This
is
just
kind
of
like
static
web
data
that
somebody's
going
to
be
reading.
There's
not
any
prices,
there's
not
any.
Like
data
aggregation,
you
look
at
it
and
you
see
you
know,
challenges
and
voting.
C
It's
a
little
bit
more
complex
and
you
say:
okay,
what
is
a
challenge?
Maybe
I
don't
know,
let's
look
at
it
scroll
down.
What's
a
category,
you
read
it
and
you're.
Okay
yeah!
Once
again,
it's
kind
of
like
a
static
kind
of
piece
of
web
text
that
somebody's
going
to
be
reading
and
trying
to
understand.
C
So
you
read
that
over
you
say:
okay,
I
understand
that
and
then
you
read
a
challenge
and
you
realize
okay,
it's
something
that
people
are
voting
on
and
then
project
that
is
being
challenged
owner
of
the
challenge,
which
is
a
project,
and
you
start
to
get
this
kind
of
idea
in
your
head.
What
it
is
and
you're
like.
Okay,
you
know:
there's
these
things
called
projects,
people
vote
on
them.
You
can
challenge
a
project
and
that's
pretty
like
and
all
these
projects
fit
into
categories.
C
So
you
look
at
that
and
you
kind
of
think,
like
you
know,
maybe
you
can.
I
don't
know
how
long
it
would
take
somebody
to
figure
out
what
the
everest
subgraph
is
doing,
but
it
definitely
would
be
a
lot
shorter
of
an
amount
of
time
than
the
uniswap
one.
So
that's
why
I
would
say,
like
everest
is
actually
like
for
complexity.
C
Everest
is
an
easy
subgraph
for
somebody
from
the
outside
to
come
and
look
at
and
kind
of
like
determine
how
complex
it
is
and
what
it's,
what
data
it's
providing
to
the
community
and
then
also
determining
like,
if
it's
worth
it
to
be
a
curator
and
to
signal
on
that
subgraph
and
like
there
were.
There
were
some
really
good
examples
too.
From
from
just
the
phase
one
missions,
this
one,
this
one
person,
zoltar
seven,
came
in
and
pointed
out
like
they
even
said
you
know
I'm
kind
of
new
to
writing
subgraphs.
C
But
this
looked
a
little
bit
weird
to
me
and
they
pointed
out
that
this
part
of
the
code
looked
a
little
bit
different
and
then
they
suggested
that
you
know.
Maybe
it
should
be
this
with
the
derived
from
property,
and
then
you
know
what
I
realized
is.
Basically
there
wasn't
an
error
in
the
subgraph,
but
what
zoltar
pointed
out
was
that,
like
what
I
ended
up,
realizing
is
the
way
that
he
was
doing.
It
was
actually
more
efficient
and
we
don't
have
to
get
in
the
details
about
that.
C
You
know
you
can
go
read
this
issue.
It's
it's
in
the
mission
control
curator
issues
on
on
on
github,
but
basically
I
realized
I
was
like
yeah
like
that's
a
good
point.
This
is
actually
a
better
way
to
do
it
and
I'm
gonna
update
that
later
this
week.
So
that's
the
great
thing
about
all
this
subgraph
kind
of
like
curators
and
like
open
apis
is
you
know
this
guy
zoltar
7
came
in
and
just
was
able
to
contribute
like
right
away
and
and
said
even
they
weren't,
you
know
an
experienced
subgraph
developer
or
anything.
C
So
that's
really
cool.
It
goes
to
show
that
a
lot
of
people
are
able
to
like
read
these
subgraphs
and
figure
out
if
they're,
if
they're
useful
and
like
what
what
kind
of
data
they're
providing
and
there
was
also
another
person
who
provided
all
these
subcategories.
C
C
You
know
these
subgraphs,
because
you
know
this,
you,
obviously
they
had
to
understand
what
everest
is
doing
and
you
know
all
you
have
to
understand
is
categories,
and
now
they
provided
feedback
that
is
actually
really
good
and,
like
we
should
probably
add
in
a
lot
of
these
suggestions
to
everest
for
sure
it
just
goes
to
show
that,
like
you
know,
depending
on
what
type
of
subgraph
we're
looking
at
you
know,
different
people
can
contribute
in
different
ways
and
a
lot
of
people
can
and
the
last
one
that
I
really
wanted
to
go
over
briefly
is
just
compound.
C
C
C
So
that's
just
one
indication
like
if
you
look
at
compounds
schema
it's
actually
not
that
big
and
it's
kind
of
readable.
So
you
might
say:
oh
it's
like
medium
hard
or
medium.
C
But
once
you
look
at
the
actual
compound
protocol,
you
realize
you're
gonna
have
to
understand
what
all
this
solidity
code
and
like
smart
contract
code
is
so
then
right
there,
it's
kind
of
like
it's
kind
of
clear
that
it's
going
to
be
a
hard
sub
graph
to
write,
but
also
very
valuable,
because
compound's
a
huge
project,
and
so
that's
like
when
I'm
evaluating
subgraphs,
I'm
basically
the
my
main
two
things.
I'm
going
to
look
at
is
like
first
look
at
the
solidity
code.
C
If
it's
long
and
complex,
I
know
the
subgraph
will
probably
also
be
complex,
look
at
the
actual
application
itself
and
determine
if
it's
you
know
if
it's
complex
or
if
you
think
it's
actually
pretty
simple
like
uniswap
and
then
really
focus
in
on
the
schema
and
read
it
because
it
should
be
human
readable.
It
should
be
able
to
like
if
the
subgraph
developer
is
doing
their
job.
C
You
should
be
able
to
read
all
these
fields
and
really
understand
what
they
mean
as
long
as
you
understand
the
protocol
from
a
high
level,
and
those
are
really
the
two
big
indicators
for
me.
If
you
want
to
like
determine
what
a
good
sub
graph
is
and
like
how
complex
it
is
and
how
valuable
it
is,
and
so
just
to
like
cap
it
off.
C
You
know,
like
I
said,
like
one
thing,
I
I
think
I
really
like
to
drive
home
that
isn't
maybe
clear
to
like
the
the
community
at
large
today
is
that
yeah
a
sub
like
there's,
not
a
single
sub
graph.
For
compound
it's,
not
a
single
subgraph
for
uniswap.
C
There
can
be
many
different
subgraphs
that
look
at
the
data
in
different
ways,
so
you
could
be
a
subgraph
developer
or
a
curator,
and
you
could
look
at
you
know.
This
is
maybe
the
most
popular
compound
v2
subgraph,
but
you
could
make
a
completely
new
one
or
somebody
else
could
make
a
new
one.
That
looks
at
the
data
in
a
different
way
and
it
could
actually
be
better
and
both
of
these
subgraphs
could
live
beside
each
other
and
both
be
queried.
C
So
that's
something
that
I
think
will
start
to
happen
a
lot
more
as
as
more
and
more
development
and
resources
go
to
web
3
is
we'll
see
like
all
this
crossover
of
different
subgraphs
for
like
the
same
protocol,
and
one
thing
also
is
like
a
subgraph
also
doesn't
have
to
be
tied
to
one
protocol.
There's
no
reason
you
couldn't,
you
know,
use
the
uniswap
subgraphs
and
a
compound
subgraph
in
one
subgraph.
C
We
also
have
something
called
subgraph
com-
composability,
that's
coming
in
the
future,
but
that
that's
kind
of
like
a
separate
thing.
What
I'm
talking
about
here
is
like.
If
you
wanted
to
build
a
decentralized
price
oracle,
you
could
use
all
you
could
use.
Uniswops
uniswap
has
an
ability
to
be
a
price
oracle,
so
you
could
use
that
you
could
go
get
the
price
feeds
that
are
released
from
link.
You
could
get
there's.
Definitely
other
protocols
out
there
that
also
have
price
oracle.
C
Like
kind
of
end
points
that
you
can
hit
mostly
like,
like
decentralized
exchanges,
and
you
could
kind
of
aggregate
all
of
these
to
get
one
like
like
total,
like
decentralized
kind
of
price
oracle,
for
you
know,
eth
usd,
and
it
would
be
more
robust
because
it
it's
not
just
based
on
a
single
protocol
like
uniswap
right,
so
that's
kind
of
like
what
I
want
to
get
across
is
there's
a
lot
of
different
subgraphs
that
can
be
built
and
so
going
forward
like
when
the
graph
network
is
actually
launched.
C
C
And
you
know
if
you're,
not
a
subgraph
developer,
but
you're
still
a
curator,
and
you
can
recognize
that
you
should
be
watching
for
those
types
of
subgraphs
and
like
when
you
see
them.
Definitely,
like
you
know,
signal
towards
it
and
and
like
you
like.
That's
the
whole
point
of
the
graph
protocol
like
these
curators
are
meant
to
drive
signal
and
like
and
like
notifications
on
what
subgraphs
out
there
are
going
to
be
very
valuable
for
the
community
at
large,
and
so
that's
that's
pretty
much
all.
C
I
have
to
say,
I'm
just
going
to
pass
it
off
to
eva
and
I
think
we'll
do
a
q
a
or
something.
A
Awesome,
thank
you
so
much
dave
that
was
so
thorough
and
if
anyone
you
know
wasn't
able
to
keep
up
with
that,
we
will
have
a
recording
to
share
afterwards
and
phase.
Two
is
all
about
you
learning
more.
So
we
had
a
few
questions
and
even
dave.
A
So
the
first
one
was
about
aggregation,
and
so,
if
your
goal
is
to
do
analytics,
what's
the
trade-off
between
having
the
aggregation
and
the
subgraph
like
for
uniswap
versus
keeping
it
so
sorry
doing
the
aggregation
in
the
subgraph
versus
keeping
it
simple
and
aggregating
client
side,
and
then,
where
is
that
calculation
stored.
B
Yeah
so
today
all
of
the
mapping
logic
runs
at
ingestion
time,
so
you're
pre-computing,
all
of
those
aggregates
and
all
of
those
values,
and
basically
the
trade-off,
is
it's
more
expensive
to
compute
ahead
of
time,
but
it
makes
querying
that
data
a
lot
faster.
B
B
We
are
entertaining
ways
of
doing
query
time
kind
of
aggregations,
but
that
hasn't
been
implemented
yet
so
you
know
that
that
could
be
an
improvement
if
there's
data
that
is
very
kind
of
like
optimistic,
like
very
few
people
are
going
to
want
to
query
it,
and
maybe
it
is
kind
of
you
know
wasteful
to
do
all
of
that
computation
ahead
of
time,
but
but
generally
our
finding
is
that
you
know
making
sure
that
all
of
the
data
is
already
processed
organized
ready
to
go
so
that
applications
can
query
that
data.
B
You
know
really
quickly
is
actually
a
a
great
kind
of
point
in
the
trade-off
space
to
make,
and
so
so
that
that's
how
it
works
today
and-
and
I
think
that
it's
it's
good
for
95
percent
of
the
use
cases,
and
only
if
basically,
the
sub-graph
that
you
want
to
build
is
intractable.
A
Awesome,
another
question
is:
how
long
does
it
take
for
a
subgraph
to
update,
and
maybe
you
can
speak
more
to
what
the
differences
are
in
the
length
of
time
for
different
subgraphs.
C
Yeah
sure
I
I
can
take
that
one.
It
really
depends
on
like
the
the
complexity
of
the
subgraph
and
how
much
data
is
kind
of
being
ingested.
So
like
the
fact
that
uniswap
gets
used
so
much,
I
don't
know
how
many
transactions
happen
a
day,
but
it's
definitely
like
thousands,
maybe
tens
of
thousands.
But
that
means
that
the
subgraph
is
going
to
have
to
ingest
all
that
data.
C
And
so,
whenever,
like
whenever,
you
and
the
thing
is
like
we
have
to
start
from
when-
let's
say
uniswap
v2
launched
was
which
was
around
like
block
10
million.
So
as
uniswap
keeps
going
and
going
and
going,
and
we
want
to
start
a
brand
new
uniswap
subgraph,
you
have
to
start
from.
You
know:
block
10
million,
which
might
be
seven
or
eight
or
ten
months
ago,
and
you
have
to
you
know
basically
process
all
that
data,
and
so
you
it's
not.
C
Sometimes
you
really
won't
learn
it
until
you
build
the
subgraph
and
you
actually
launch
it
and
you
watch
it
start
to
sync
and
it'll
say
like
okay,
it
syncs
and
it
syncs
in
two
hours
or
you
might
watch
it
and
sometimes
it'll
take
like
a
day
or
two
right,
and
so
then
you
have
to
determine
like.
Why
is
it
taking
so
long?
Well,
uniswap's
been
around
for
eight
months,
it's
the
most
used
protocol
and
I'm
I'm
tracking,
every
single
transaction.
C
Then
all
of
a
sudden
you
might
realize,
like
you,
might
want
to
split
the
subgraph
into
two.
You
know.
Maybe
one
is
for
transactions
and
one
is
for
analytic
data
and
the
idea
is
just
you
know
as
a
subgraph
developer,
if
you
can
kind
of
get
a
visualization
of
the
protocol
and
how
it's
been
used
in
the
last
year
or
two
years
on
ethereum
and
then,
if
you
kind
of
get
an
idea
of
how
many
transactions
have
happened
in
that
time,
you
should
be
able
to
get
a
rough
estimate
of
how
long
it'll
take.
B
Yeah
and-
and
so
you
know-
that's
you
know
regarding
the
indexing
time,
how
long
it
takes
to
index
and
sub
graph,
which
you
know
could
take
anywhere
from
minutes
to
days.
Of
course,
that
work
is
done
ahead
of
time
and
then
once
the
subgraph
is
synced
by
an
indexer,
then
querying
it
is
really
fast,
but
as
far
as
how
long
it
takes
to
update
data,
let's
say
that
you
know
a
transaction
was
included
in
a
block.
B
You
know,
processing
that
block
I
can
can
take
just
tens
or
hundreds
of
milliseconds,
so
that
the
data
updates
really
quickly
that's
going
to
depend
on
how
much
work
any
individual
graph
node
is
doing.
So
if
a
graph
node
is
indexing,
you
know
a
thousand
sub
graphs,
it's
processing,
a
new
block
that
touches
you
know
a
hundred
different
subgraphs.
B
It's
going
to
take
it
a
little
bit
longer
to
process
that
block,
and
so
you
know
those
are
the
types
of
optimizations
that
the
indexers
are
making
to
decide.
You
know
how
many
sub
graphs
should
I
be
indexing
on
each
node
to
make
sure
that
I
can
process
data
efficiently
and
they're
kind
of
competing.
You
know
based
on
price
performance
and
security,
and
that's
you
know
really.
Nice
part
of
kind
of
separating
the
curator
roles
from
the
indexer
roles
is
the
curators
can
just
be
thinking
about.
B
You
know
what
data
do
we
want
to
expose?
What's
going
to
be
useful
to
the
community,
it's
very
declarative,
and
then
the
indexers
can
figure
out
what
are
the
right
ways
to
to
optimize
to
make
sure
that
that
data
is
being
processed
quickly
and
and
is
being
served
efficiently.
A
Awesome
so
another
quick
question
was
what
would
make
a
bad
sub
graph.
B
You
know,
I
think,
there's
there's
three
measures
that
we
look
at
for
sub
graphs,
there's
complexity,
completeness
and
accuracy,
and
all
three
of
those
are
really
important.
You
know
if
you
have
a
sub
graph
that
you
know
has
all
of
the
fields
that
you
could
want,
but
the
the
numbers
that
you
get
back
are
wrong.
That's
obviously
really
bad!
You
don't
want
that.
So
accuracy
is
like
a
must-have.
B
You
know
completeness,
you
could
say
is
like
a
nice
to
have.
You
know
a
subgraph
that
has
more
fields
that
are
more
useful
for
more
applications
right.
That
would
be
more
valuable
than
a
sub
graph.
That's
like
missing
half
of
the
data,
so
you
know
I.
I
think
that
kind
of
a
good
minimum
bar
for
a
subgraph
is
you
want
to
include
like
all
of
the
raw
data,
that's
in
the
protocol
that
you're
ingesting,
because
you
know
if
you're,
just
like
missing
data,
for
no
reason.
B
That's
unfortunate
then
there's
questions
of
you
know
what
additional
views
do
you
want
to
build
on
top
of
that,
so
different
aggregations
different.
You
know
insights
that
you
can
pull
from
that
data.
Those
are
nice
to
haves
and
the
more
of
those
additional
insights
and
aggregations
and
computations
you
surface.
That
can
make
a
subgraph
more
valuable
and
then
you
know
the
complexity.
B
I
guess
that's
that's
just
inherent
in
which
protocols
you
end
up
indexing,
so
I
shouldn't
you
know,
really
impact
like
a
good
subgraph
or
is
a
bad
subgraph.
A
Well,
I
think
we
have
time
for
one
last
question,
so
someone
had
a
question
about
incentives.
They
understand
the
incentives
around
curation
and
indexing,
but
what
is
the
incentive
for
a
subgraph
developer
and
if
they
independently
develop
a
subgraph
for
adapt
that
gets
heavy
usage?
How
are
they
incentivized
for
that.
B
Yeah
great
great
question,
so
on
the
curator
side
there
is
a
natural
incentive
there.
If
you're
the
developer,
that
built
a
subgraph,
then
you
can
be
the
first
curator
to
signal
on
the
subgraph
and
since
curation
happens
on
a
bonding
curve.
That
means
that
you'll
own
more
of
those
curation
shares,
so
that's
a
great
natural
incentive
there
just
to
be
like
the
first
curator
and
then
other
than
that.
B
A
I
would
also
add
that
the
implicit
incentive
for
a
subgraph
developer,
if
you're,
also
the
one
that
built
the
protocol,
is
that
subgraphs
can
actually
make
it
a
lot
easier
for
applications
to
integrate.
So
if
your
your
objective
is
to
get
more,
you
know
volume
to
your
d5
protocol.
Then
you
want
a
sub
graph
that
makes
it
really
easy
for
front
end
developers
to
integrate.
A
Awesome
if
there
aren't
any
more
questions,
I
think
this
might
be
a
good
place
to
wrap
it
up
and
we'll
be
sending
more
information
about
phase
two.
What
are
the
missions
and
also
sharing
a
recording,
either
later
today
or
tomorrow,.