►
From YouTube: The Graph’s Town Hall Feb 23rd, 2021
Description
The Graph’s Community first Graph Protocol Townhall
This video was recorded: Tuesday, Feb 23 @ 8am PST, 2021.
If you want to receive calendar invites for future calls, you can register here: https://airtable.com/shrz0v0bZw1nkAGTZ
About The Graph
The Graph is the indexing and query layer of the decentralized web. Developers build and publish open APIs, called subgraphs, that applications can query using GraphQL. The Graph currently supports indexing data from Ethereum, IPFS, and PoA with more networks coming soon. To date, over 8,000 subgraphs have been deployed by over 10,000 active developers for applications such as Uniswap, Synthetix, Aragon, Gnosis, Balancer, Livepeer, DAOstack, AAVE, Decentraland, and many others.
If you are a developer building an application or Web3 application, you can use subgraphs for indexing and querying data from blockchains. The Graph allows applications to efficiently and performantly present data in a UI and allows other developers to use your subgraph too! You can deploy a subgraph or query existing subgraphs that are in the Graph Explorer. The Graph would love to welcome you to be Indexers, Curators and/or Delegators on The Graph’s mainnet.
Join The Graph community by introducing yourself and learning more:
Discord Server: https://thegraph.com/discord
Telegram chat: https://t.me/GraphProtocol
Twitter: https://twitter.com/graphprotocol
Website: https://thegraph.com/
Forum: https://forum.thegraph.com/
Graph developers and members of the community are always eager to chat with you and The Graph ecosystem has a growing community of developers who support each other.
The Graph Foundation oversees The Graph Network. The Graph Foundation is overseen by the Technical Council.
There were more than 2K Curators from over 90 different countries and over 200 Indexers from more than 50 countries in The Graph’s testnet. The Graph community is globally distributed, with over 4,500 GRT holders from more than 99 different countries world-wide. Delegation can happen by anyone who holds GRT. Today, there are over 5k Delegators and over 200 Indexers on The Graph Network.
A
Welcome
everyone
to
the
graphs
first
protocol
town
hall
so
excited
to
see
over
170
people
here.
So
that's
really
exciting
for
us.
You
know
at
the
foundation
just
wanted
to.
Firstly,
thank
everyone
for
coming
on
this
journey
with
us.
You
know
it's
been
over
six
months
of
us
engaging
with
indexers,
starting
on
the
test
net,
where
we
had
over
200
indexers
set
up.
You
know
over
90
countries,
and
now
we
have
over
160
on
mainnet
with
over
5000
delegators.
So
I
think
this
is
like
a
round
of
applause
for
everyone.
A
You
know
the
community
has
been
so
fruitful
and
helpful
in
bringing
in
new
users
and
we'd
love
to
see
it.
Next.
I
just
wanted
to.
You
know,
bring
up
a
few
of
the
things
that
we're
focusing
on
in
the
foundation
and
how
that
might
relate
to
you.
So
we've
got
a
few
members
of
the
graph
council
here.
You
know
from
live
pierre
from
zeppelin
who
are
also
here
to
help
out,
but
one
of
the
other
focuses
has
been
grants.
A
So
we've
been
doing
a
lot
of
interviews
across
protocol
infrastructure,
decentralized
applications,
community
building
and
really
encourage
you
indexers
to
apply.
If
you
have
any
either
community,
you
know
operations
or
building
initiatives,
or
you
know,
index
improvements
and
even
on
the
indexer
side,
we've
had
a
few
great
initiatives
start
such
as
know
your
indexer,
which
is
highlighting
an
indexer
every
week.
B
Thanks
eva
yeah,
great
to
see
so
many
familiar
faces
here
and
I'll
echo
what
eva
said
about
just
being
blown
away
by
all
the
community
contributions
in
the
last
month,
plus
and
obviously
before
that
as
well.
So
today,
I'm
going
to
be
talking
about
the
gip
process
that
we're
proposing,
like
other
gip
processes.
This
is
actually
a
a
self-bootstrapping
process,
as
we've
seen
in
other
protocols.
B
Let
me
just
make
sure
I've
got
the
right
browser
up
here,
perfect,
so
gip001
is
basically
what's
going
to
define
this
process
we're
going
to
be
hosting
these
gips
in
a
radical
repository.
So
I
don't
know
how
many
folks
are
familiar
with
the
radical
on
the
call,
but
it's
kind
of
the
decentralized
version
of
github.
B
B
You
know
so
there's
a
few
different
lanes
depending
on
the
type
of
poles,
that's
being
worked
on
the
kind
of
main
one
that
you
know,
most
folks
will
think
about
are
gips.
You
know
which
are
you
know?
Improvements
and
changes
to
the
protocol
could
also
be
improvements
to
processes
that
surround
the
protocol
or
you
know
the
ecosystem,
but
these
these
are
things
you
know,
typically,
that
are
going
to
involve
changes
to
graph
node
to
the
subgraph
api
to
the
smart
contracts
they
might
require.
You
know
a
protocol
upgrade
those
types
of
changes.
B
Grc's
are
similar
to
ercs
in
the
ethereum
community,
in
the
sense
that
these
are
application
layer
standards.
You
know
that
develop
so
like
right
now
we
don't
have
a
lot
of
standardization
across
the
ecosystem
and
how
to
build
sub
graphs
and
like
what
are
the
application
layer
patterns
for
incorporating
subgraphs
into
your
app.
We
think
you
know,
as
in
the
future,
subgraphs
support.
You
know
more
features
such
as
like
pipelining,
you
know
data
across
subgraphs
or
doing
composition
at
query
time
across
step
graphs.
B
Having
some
level
of
standardization
actually
will
make
it
a
lot
easier,
for
you
know,
subgraphs
to
compose
right
being
able
to
implement
common
interfaces
and
then
the
last
one
here
is
grps,
and
this
is
basically
a
way
of
kind
of
like
helping
the
community
find
the
most
valuable
problems
to
work
on
at
any
given
point
in
time.
So,
obviously,
like
the
initial
team
and
early
contributors
that
have
been
working
on
the
graph
have
been
thinking
about
this
problem
for
a
long
time,
and
it's
probably
not
surprising
to
learn
that
we've.
B
You
know
personally
only
worked
on
maybe
a
small
percentage
of
like
the
long-term
problems
and
opportunities
that
we
see
in
the
space
and
so
by
like
formalizing
and
like
defining
these
problems,
really
clearly
it
kind
of
gives
other
contributors.
You
know
in
the
ecosystem
a
way
to
just
kind
of
jump
in
and
like
hop
into
a
meaty
problem
right,
so
that
might
be
like
you
know
what
is
the
best
way
to
design
mutations?
B
You
know
in
subgraphs,
or
you
know
what
is
the
best
way
to
make
the
you
know
the
delegation
market
more
efficient
and
dynamic,
and
so
by
really
like
specifying
those
problems.
Well,
you
kind
of
create
a
common
language
and
a
common
reference
point
for
other
community
members
to
you
know
to
hop
hop
on
and
make
contributions,
which
is
what
we
want
right.
We
want
to
grow
the
ecosystem.
B
We
want
to
grow
the
you
know
the
community
of
of
collaborators,
so
I'll
walk
through
the
different
stages
in
a
moment,
but
before
that
I
wanted
to
like
take
a
zoom
out
a
little
bit
and
kind
of
focus
on
the
meta
process
here.
So
what
happens
in
the
repo?
Isn't
the
whole
story
right
like
there's
stuff
happening
before
during
and
after
this
process
that
makes
it
meaningful
so
before
you
know
folks,
let's
see
before
folks
even
create
a
proposal.
B
I
think,
especially
if
you're
you
know
a
new
or
early
contributor
to
the
graph.
Probably
a
good
step
is
to
hop
in
some
of
the
forums
right
talk
to
some
of
the
existing
contributors.
Talk
to
other
people
in
the
community
see
if
they
have
the
same
problem
as
you,
you
know
make
sure
that
this
is
actually
a.
B
You
know
a
problem
worth
solving
and
a
problem
worth
your
time
of
going
through
and
like
crafting
this
gip,
which
is
you
know,
we've
tried
to
keep
it
lightweight,
but
it
is
a
more
involved
process
right
than
just
posting.
You
know
in
the
forum
we've
already
kicked
off
this
process
by
the
way,
so
we've
had
some
amazing
forum
posts
and
discussions
over
the
last
you
know
month
or
so.
I
think
we
kicked
off
the
forum
in
like
early
to
mid
january.
B
So
some
of
the
speakers
that
we
have
today
are
folks
that
have
actually
posted
ideas
already
in
the
forum
and
have
been
kind
of
driving
conversations
there
and
that's
going
to
continue
throughout
this
process.
But
in
addition,
while
a
proposal
is
being
worked
on,
you
might
do
things
like
form
working
groups,
you
know,
so
there
might
be
other
people
in
the
community
that
have
your
same
problem
or
have
the
same
skills
required
to
solve
a
given
problem.
B
And
so
you
know
both
the
foundation
and
other
members
in
the
community
can
play
a
coordinating
role
and
help
bringing
the
right
people
together
to
solve
a
problem.
We
have
improv
graph
improvement
town
halls
like
we're
at
today.
Welcome
you
made
it
to
the
first
one.
There
will
be
continued
discussions
in
the
forum
as
we
discussed,
and
then
we
also
have
snapshot.
B
That's
likely
to
be,
you
know,
accepted
by
the
wider
community,
so
let's
zoom
back
in
really
quick
and
we
can
get
into
the
stages
of
these
proposals,
so
grc's
and
grps
really
only
make
it
up
to
the
draft
stage,
whereas
you
know
gips
make
it
have
a
couple
stages
after
that,
and
the
first
three
stages
are
roughly
the
same.
You
know
for
all
three
yeah,
the
straw
person
is
kind
of
the
high
level
idea
right.
So
it's
like,
if
you
were,
writing
a
one
of
these
proposals.
B
You
know
from
the
template
which
I'll
get
to
in
a
second.
This
would
kind
of
be
like
your
abstract
and
your
motivation
right,
just
like
sort
of
the
high
level
inkling
of
an
idea.
Maybe
you
know
the
the
way
of
solving
it.
Isn't
that
concrete
in
your
mind,
yet
you
don't
have
a
specific
solution
in
mind,
but
you
kind
of
want
to
put
something
out
there
to
get
comments.
You
want
something
out
there
to
see
like
hey.
Is
it
worth?
Moving
to
the
next
step,
the
proposal
is
kind
of
a
high
level
design.
B
You
know
so
think
of
this.
Almost
like
a
you
know,
a
detailed
prd
right
like
there
might
be
like
high
level
architecture
diagrams.
There
might
be
some
pseudo
code.
There
might
be
some
math
formulas,
but
it's
still
relatively
at
a
high
level,
but
someone
should
be
able
to
walk
away
from
a
proposal
with
like
an
understanding
of
like
yeah.
I
I
get
how
this
would
work
and
then
a
draft
specification
is
really
like.
B
Almost
at
the
level
of
like
an
engineering
plan,
you
know
it's
getting
down
into
like
the
implementation
details
like
specific
apis
specific
interfaces.
Different
technical
considerations
should
definitely
be
at
the
stage
if
there's
things
around
like
backwards
compatibility,
interoperability,
anything
that's
kind
of
affected
at
that
level
like
this.
Should
kind
of
this
should
fully
flesh
out
what
the
proposal
is
going
to
look
like
in
practice,
so
grc's
and
grp's
just
kind
of
stop
there
right
once
you're
at
this
level
of
specificity.
There's!
No!
B
B
So
the
the
next
stage
for
draft
specification
is
candidate
and
the
candidate
stage
indicates
that
there
is
a
reference
implementation.
That's
been
put
out
for
this
proposal
that
people
can
actually
take
a
look
at.
They
can
try
it
out.
Maybe
it's
deployed
to
the
test
net.
Maybe
it's
you
know
deployed
to
you
know
some
hosted
service
somewhere.
Maybe
you
know,
depending
on
the
type
of
change.
I
think
this
is
going
to
look
different
right.
B
If
it's
a
smart
contract
change
or
a
you
know,
subgraph
api
change,
so
it's
either
gonna
be
in
a
test
net.
Maybe
it's
implemented
somewhere
as
an
ex
behind
an
experimental
flag.
So
it's
not
interfering
with
like
core
protocol
logic.
At
this
point,
it
can
go
through
security
audits;
it
can
go
through
economic
modeling
and
simulation
if
that's
relevant
and
really
the
the
validation
criteria.
B
For
these
things
is
going
to
be
different
depending
on
what
the
you
know,
what
the
type
of
change
is,
and
so
one
of
the
things
we'll
have
you
actually
specify
in
the
template
is
how
to
validate
this.
This
proposed
change,
and
then
the
last
thing
I'll
kind
of
mention
is
the
end
of
the
process
over
here.
So,
let's
start
we'll
start
with
the
governance,
so
zooming
out
again
real
quick.
You
know.
B
B
Initially,
they'll
be
contributors
who
are
really
familiar
with
the
protocol
and
you
know,
and
the
code
bases,
but
their
role
in
moving
stuff
through
this
process
is
purely
editorial
and
what
it
means
to
get
to
the
end
of
this
process
means
that
your
proposal
has
had
as
much
of
an
opportunity
as
possible
to
a
receive
thoughtful
comment
by
the
community
and
and
kind
of
be
given
the
spotlight
right.
So
like
the
most,
the
proposals
with
the
most
momentum
behind
them
will
be.
B
Given
you
know,
speaking
time
at
the
town
halls,
they'll
have
community
polls,
and
generally
they
have
a
chance
to
kind
of
build
some
inertia
and
then
actually
getting
those
included
in
the
protocol
is,
you
know
the
domain
of
decentralized
governance
and
so
for
the
graph.
Initially,
that
looks
like
the
graph
council.
You
know
in
the
future.
We've
talked
about
more,
you
know,
rep.
B
B
You
know
if
a
a
change
that's
been
worked
on
is
security
related.
It's
likely
that
the
graph
council
would
execute
a
governance
proposal
and
then
vote
on
the
proposal
for
transparency
reasons.
Afterwards
I
mean
that's
just
you
know,
because
while
the
graph
is
kind
of
in
this
bootstrapping
phase
right
we've
only
been
on
mainnet.
B
The
last
thing
I'll
mention
here
is
just
that.
Not
all
changes
to
the
protocol
have
to
go
through
this
process
right
like
if
you
look
at
some
of
the
various
software
repos
that
interact
and
comprise
the
protocol.
Things
like
graph
note
things
like
index
or
agent
index
or
service,
there's
tons
of
like
small
github
issues,
feature
requests
that
are
like
sort
of
at
the
level
of
like
minor
enhancements,
that
many
of
them
might
be
too
small
to
to
justify
like
a
full
gip
right.
B
Many
of
them
would
qualify,
probably,
but
but
there's
a
chance
that
these
repos
over
time
accumulate
changes.
You
know
so
maybe
the
graph
node
between
releases
accumulates
a
handful
of
enhancements
that
have
kind
of
been
made
in
the
normal
course
of
working
on
that
code
base
and
then
those
can
also
get
bundled
into
a
release
and
and
still
sort
of
be
given
to
sign
off
by.
You
know,
decentralized
governance
that
you
know
hey.
B
B
B
Given
that
we
won't
have,
you
know
github
issues
and
prs,
but
radical
team
is
working
on
a
kind
of
crypto
native
version
of
prs
and
issues,
and
so
we
expect
that
this
process
could
change
slightly
in
the
future.
As
you
know,
we
start
dog
footing
more
and
more
of
the
functionality
that
they're
working
on.
B
I
think
I've
mostly
touched
on
all
the
things
here,
I'll
just
mention
that
these
are
meant
to
be
guidelines.
You
know,
for
the
most
part
not
set
in
stone.
Most
of
these
sections
are
optional.
You
know
we
want
to
be
flexible
here
we
want.
We
want
to
acknowledge
that
not
every
change
to
the
protocol
is
the
same,
and
so
you
know,
as
an
author
of
a
proposal,
you're
encouraged
to
exercise
good
judgment
in
deviating
from
the
standard
or
deviating
from
the
template.
B
Just
to
you
know
just
to
get
your
ideas
across
as
effectively
as
possible.
That's
really
the
the
main
goal.
You
know,
according
to
the
criteria
that
are
laid
out
in
each
stage,
so
the
gip
zero
zero.
One,
like
I
said
mostly
just-
has
the
information
that
I've
kind
of
said
verbally.
So
we
won't
go
through
all
of
this.
It
outlines
the
editors
outlines
some
of
the
required
structure
of
a
gip
and
obviously
all
proposals
are
going
to
be
under
creative
commons.
A
C
Good,
okay,
great
all
right,
so
first,
I'm
gonna
dig
in
a
little
bit.
What
snapshot
is
for
all
of
you
who
are
not
aware
of
it?
It's
it's
kind
of
just
a
decentralized
voting
governance
application,
that's
been
created
by
snapshot
labs,
which
has
some
relationships
to
balancer
and
a
lot
of
the
projects
in
the
space
have
actually
taken.
C
You
know
taken
to
using
it
and
contributing
contributing
to
it
and,
as
you
can
see,
there's
over
500
of
them
that
are
using
it
and
you'll
recognize
a
lot
of
these
names.
Even
if
we
click
on
balance
early,
you
see
how
the
application
works.
There's
all
these
proposals
they're
closed.
That
means
people
are
voting
on
them,
there's
different
types
of
proposals.
C
We
can't
see
them
here
in
this
cui,
but
you
can
have
proposals
from
the
community.
You
can
have
proposals
from
the
you
know,
specific
teams,
maybe
the
council,
or
maybe
edge
and
node
something
like
that,
and
it
gives
you
a
lot
of
flexibility-
and
you
know
we've
created
a
page
here-
and
this
is
it's
still.
C
If
I
can
find
the
chat,
I
want
to
share
it,
so
people
can
go
to
it
right
now,
so
you
can
actually
go
there
now,
if
you're
holding
any
grt
and
I'm
quickly
going
to
explain,
you
know
how
the
voting
process
works
and
how
we're
scoring,
but
another
thing
to
understand.
You
know
this
is
kind
of
this
scoring
that's
being
proposed
right
now,
there's
no
curators
involved,
it's
just
delegators
indexers,
as
well
as
grt
in
the
balance
of
a
wallet,
but
this
can
also.
C
This
is
also
going
to
be
like
a
work
in
progress,
and
you
know
we're
the
way
that
we've
chosen.
The
votes
here
can
also
be
voted
on
in
the
future
or
talked
about
in
discourse
and
changed,
and
you
know
what
we
want
to
see
is.
This
is
really
voting
for
the
community
that
can
be
done
in
a
decentralized
way.
C
Anybody
on
snapshot
can
actually
propose
a
a
a
proposal
to
vote
on
in
here,
and
you
can
also
set
a
a
limit
you,
you
might
have
to
have
a
score
of
1
million,
which
could
relate
to
1
million
grt
or
it
could.
It
could
be
different
as
I'll
explain
in
a
second,
but
that
would
allow
you
know
people
can't
just
spam
the
proposals,
but
it
means
anybody
in
the
community
with
you
know,
maybe
100
000
grt
would
be
able
to
submit
a
proposal.
C
C
C
C
Just
hypothetically,
if
there
were
100,
000
grt,
total,
that's
100,
000
votes,
and
then
we
ended
up
normalizing
the
other
two
stakeholders
up
in
in
the
case
that
they
are
lower,
and
you
would
expect
to
see
that
there
will
be
more
grt
in
wallets
compared
to
total
grt
stake.
At
least
that's
what
we're
seeing
the
network
today
so
easily.
If
there's
20,
000
grt
state
by
indexers,
they're
gonna
get
five
votes
for
the
score
and
the
same
with
the
alligators.
C
C
It
doesn't
always
work
there,
it
does
work
down
here,
though
you
can
see.
So
this
was
me.
I
voted
on
this
proposal
just
to
check
it
out.
This
is
just
some
test
wallet
I
have
it
has
25
grt
in
the
wallet
and
it
has
4.6
delegated
grt
so
that
score
normalized
up,
I'm
pretty
sure.
I
actually
only
have
one
delegated
token
on
the
network.
So,
as
you
can
see
that
score
has
been
times
by
4.68,
and
this
has
been
another
feature
of
snapshot.
Is
you
choose
a
block
to
snapshot?
C
So
it's
just
snapshot
of
this
specific
block,
and
that
means
these
scores
are
going
to
be
calculated
for
everybody
who
votes
that
way,
and
so
this
is
just
a
test
snapshot
that
we've
created
to
kind
of
get
the
community
to
look
at
it
and
understand
how
it
works
and,
as
you
can
see,
we've
already
got
a
bunch
of
people
who
have
voted,
which
is
awesome,
just
as
I
posted
it
in
this
in
the
chat
there.
So
this
is
really
you
know
the
power
of
snapshot.
C
None
of
these
votes
cost
money.
What
sned
does
is
it
takes
a
signature
from
your
ethereum
wallet
and
uses
it
through
the
snapshot
hub
and
they
calculate
the
score
and
it
posts
it
here,
and
this
is
all
run
on
snapshots
ui.
So,
as
you
can
see,
that's
a
point
of
centralization
that
snapshot
or
back
or
back
or
whoever,
whoever
is
in
charge
of
the
hub
is
writing
the
ui
that
calculates
the
scores
now.
The
good
thing
about
that
is,
you
can
go
to
the
strategies
which
are
it
doesn't
pop
out
there,
but
js.
C
So
if
you
go
here
and
you
search
the
graph
you'll
find
we
have
our
three
strategies
there,
and
so
it
allows
us
to
confirm
that
it's
actually,
the
scores
are
being
run
correctly.
Now,
like
I
said
this
is
a
step
towards
decentralization,
and
you
know,
we've
seen
a
bunch
of
different
projects
use
snap
successfully
and
you
know
we're
we're
super
excited
to
work
with
snapshot.
B
B
B
C
Thanks
yeah
100
100
right
there
and
yeah.
I
think
I've
actually
kind
of
covered
everything
here.
There
are
more
strategies
we
want
to
see.
Specifically,
you
know,
sub
graph
developers
and
curators
are
obvious
ones,
but
anybody
from
the
community
could
write
the
strategy
as
well
and
comment
on
the
strategies
that
that
have
been
written
in
snapshot.
It
would
be
great
to
get
feedback
there.
C
Just
for
some
clarity
is,
if
you
are
a
holder
of
a
talk
wallet,
those
vote,
the
voting
power
from
those
token
lock
wallets
actually
get
attributed
to
your
beneficiary
account
and
that's
simply
because
token
lock
wallets
are
not
externally
owned
accounts
and
therefore
they
can't
actually
sign
anything
and
therefore
you
wouldn't
be
able
to
vote
with
the
token
lock
wallet.
So
it
just
is
natural
that
we
would
attribute
that
voting
power
to
a
beneficiary
address,
because
that
is
the
address
that
acts.
B
B
C
C
C
It
actually
goes
into
the
graph,
which
is
pretty
cool,
because
the
way
that
I'm
calculating
these
strategies,
I'm
actually
hitting
a
sub
graph,
which
is
great
because,
as
I
started
to
use
snapshot
and
and
integrate
with
it,
it
was
cool
to
see.
You
know
all
this
work
that
the
graph
protocol
has
been
doing,
that
I've
been
a
part
of,
is
something
that
I
actually
end
up
working
with
completely
early,
and
I
didn't
know
it
was
going
to
happen.
So
it
just
shows
you
the
power
of
decentralization
that
people
like
you
know.
C
C
So
that's
good
in
that
sense,
but
that
is
something
that
people
have
seen
in
the
past
in
decentralized
voting
is
you
know
these
exchanges
like
like
finance
and
kraken,
have
huge
balances
and
they're
able
to
swing
votes,
maybe
for
their
own
benefit,
and
that
is
something
really
important.
A
really
good
question
and
it's
worthwhile
considering
a
good
thing
to
note
is
there
are
ways
to
write
strategies
to
probably
keep
them
out
of
the
scoring.
B
Yeah-
and
one
thing
I'll
add
to
that-
is
just
that:
there's
nothing
magic
about
this
roll-up
score,
like
that's
kind
of
an
artifact
of
how
snapshot
works,
is
that
they
kind
of
want
multiple
strategies
on
the
same
page
to
roll
up
to
a
single
vote
score,
so
dave
kind
of
went
through
the
work
of
normalizing,
but
you
can
also
just
look
at
each
stakeholder
group
individually
and
that
in
many
cases,
might
be
more
interesting
right,
rather
than
looking
at
the
roll-up
score
to
see.
Okay,
what
did
delegators
think
about
this
proposal?
D
B
E
E
So
we
have
the
forum
where,
like
different
people
that
are
following
the
the
graph,
are
proposing
and
raising
issues
and
and
discussing
about
new
ideas
and
about
all
the
ideas
that
I
that
we
are
seeing
in
the
forum.
I
want
to
focus
on
a
couple
of
them
that
might
end
up
being
upgrades
in
the
protocol.
One
of
the
one
of
these
ones
is
the
rewards
for
indexers
when
they
are
paid
out
by
allocating
and
collecting
indexing
rewards.
E
E
That
means
that
an
indexer
if
he
wants
to
take
out
the
rewards,
needs
to
unstake
and
needs
to
wait
28
days
for
that.
The
third
period
there's
an
additional
issue
with
that,
because
it's,
I
would
say,
99
of
the
of
the
indexers
are
under
token
logs
and
the
token
logs
avoid
them
to
basically
withdraw
this
stake
and
allow
this
to
happen.
Only
if
the
contract
see
a
profit
and
to
see
a
profit,
they
need
to
understak
most
of
the
of
the
tokens.
E
So
that
means
that
they
need
to
remove
a
lot
of
capital
from
the
protocol
if
they
want
to
take
some
rewards
out
and
why
why
do
they
maybe
want
to
take
some
rewards
out
from
the
from
the
protocol?
They
are
paying
a
lot
of
like
infrastructure
costs.
They
are
paying
for
some
costs
by
sending
transactions
to
the
to
ethereum
for
paying
the
the
gas
price.
E
E
E
So
I
encourage
like
everyone
to
comment
on
the
on
the
code
and
maybe
look
at
it
at
it
and
review
it
so
that
you'll
see
like
this
discussion
around
the
the
pr
for
many
days
and
what
we
did
is
to
deploy
this.
This
fix
to
the
test
net,
so
we
are
giving
the
the
chance
to
index
to
test
the
implementation
using
the
the
test
net
with
actual
like
glt
from
the
test
net
and
using
even
token
locks,
destnet
and.
E
E
I
described
this
in
a
in
a
different
posing
in
the
forum.
This
is
happening.
This
is
something
that
is
not
like
affecting
the
operation
now,
because
it's
basically
on
an
edge
condition.
That
is
not
happening
in
the
network.
That
is
if
we
have
someone
curating
a
subgraph
and
this
and
we
have
indexers
allocating
and
that's
a
graph
and
for
some
some
reason,
the
complete
amount
of
signal
from
that
sub
graph
go
back
to
zero.
E
E
We
need
to
review
it,
and-
and
we
need
to
have
some
discussion
around
that,
so
I
encourage
again,
like
all
the
stakeholders,
to
look
at
the
at
the
proposed
implementation
and
discuss
that
and
to
provide
feedback.
Okay,
there's
one
more
one
more
proposal
I
want
to
discuss,
but
I
will
leave
gavin
to
to
propose
it
because
he's
the
one
that
wrote
the
the
books
in
the
forum.
Okay.
B
B
D
D
I
made
I
made
slides,
but
I'm
just
not
going
to
use
them
so
yeah,
I'm
gavin,
I'm
from
figment.
We've
got
a
few
indexers.
I've
been
personally
involved
in
staking
protocols
for
about
a
year
and
a
half
now
working
with
them
in
various
ways
and
involvement
in
governance
and
strategy
and
everything
staking.
D
I
propose
this,
it's
it's
a
very.
I
don't
know
if
this
would
be
considered.
Grc,
probably
you
know,
we've
been
talking
to
some
of
the
folks
that
worked
on
the
graph
and
some
of
the
people
who
are
involved
in
using
it,
and
our
understanding
is
that
that
essentially
the
graph,
the
way
that
the
you
know,
the
delegator
and
indexer
relationship
works.
D
Maybe
we
should
I'll
just
start
by
saying
that
what
what
I
think
is
in
scope,
you
know
what
I'm
looking
to
discuss
here
is
like
a
broad
overview
of
what
we
want
as
an
outcome
and
and
what
I
personally
would
like
to
see,
is
stable
cut
rates
and
and
what's
out
of
scope,
it
would
be
like
implementation
specifics.
I
think
that
that's
after
the
grc,
you
know
wasn't
brandon
outlined
in
that
process
or
no
sorry
is
that
brandon
knows
david
align
the
process.
D
D
How
could
we
make
things
better
and
so
from
from
what
I
can
see,
what
the
maybe
what
the
the
problem
is
here
is
that-
and
this
was
kind
of
misleading,
maybe
by
saying
unintuitive,
but
but
really
the
core
issue
here
is
that
the
commission
rates
or
sorry
the
the
cut
rates
are
volatile.
We
see
something
really
similar.
We
see
a
similar
kind
of
language
in
in
life.
Here
I
saw
yondin's
here
as
well.
D
This
called
a
cut
rate,
whether
it's
the
ward
cut
or
the
fee
cut,
and
then
and
then
after
it's
been
divided.
Then
there's
this
pro
rata
distribution
that
happens
just
for
the
delegators
and
it
technically
it
works.
But
I
I
think
it's
a.
I
think
that
we
should
change
it
so
that
so
that,
if,
if
a
delegation
changes,
it
doesn't
suddenly
throw
off
what
the
outcome
is
for
for
what
the
indexer
takes
from
the
delegator's
earnings.
D
Of
this
sort
of
change,
we
would
see
that
it
doesn't
matter
if
new
delegators
join
or
depart.
You
know,
delegators
that
have
stayed,
have
stayed
with
that.
Indexer
aren't
going
to
see
their
their
rip
the
what
they
effectively
pay
to
the
delegator
or
sorry
effectively
paid
to
the
index
or
varying
wildly.
D
So
in
this
demonstration,
in
this
scenario,
we've
got
an
indexer.
I
I
just
I
just
set
the
effective
rewards
rate
to
be
six
percent.
Assuming
that
you
know
fifty
percent
of
the
network's
staking
and
and
the
nuisance
rates
three
percent-
that's
also
called
inflation.
I
think
it's
a
poor
term,
blah
blah
blah,
so
so
indexer
has
a
hundred
grt
staked
and
then
they
have
two
delegators
and
200
and
300
respectively.
D
D
D
Okay
cool,
so
I
took
this,
and
actually
that
reminds
me.
I
took
this
to
the
forum
and
there
was
I'm
really
glad
to
see
that
there's
engagement,
I'm
sorry
that
I
I
had
difficulty
like
understanding
everything
that
everybody
said.
I
just
want
to
make
note
that,
like
this
work
is
kind
of
hard
like
to
propose
something.
New
is
really
hard
because
defaults
weigh
very
heavily
and
understandably
so,
that
people
are
reticent
to
consider
how
changing
might
mess
up
something
unexpectedly,
but
yeah.
D
D
You
know
if
our
goal
as
a
as
an
indexer
is
to
take
10
percent
of
of
what
our
delegators
are
earning
in
our
partnership,
then,
and
then,
and
that's
the
the
assumption
for
our
that's-
also
the
assumption
for
anyone
delegating
they
they
want.
They
see
that
that's
the
effective
take
from
from
this
relationship
and
and
that's
been
implemented
in
the
in
the
user
interfaces.
So
great.
You
know
I
got
this
effective
cut
calculator.
D
This
is
what
we
use
is
what
figment
uses
we
use
this,
because
we
need
to
kind
of
figure
out
if
we
want
to
take
10
percent.
We
need
to
do
a
calculation
in
order
to
ensure
that
we
set
the
right
cut
rate
to
get
10
effectively
and
then
we'll
reverse
it
as
well
to
make
sure
that
our
math
kind
of
makes
sense,
but
we
need
this.
We
need
this
because
of
the
because
of
the
volatility
of
of
the
current
implementation.
D
D
D
What
we're
effectively
taking
is
17
and
a
half
percent,
and
we
don't
want
to
do
that.
But
you
know
there's
this
cool
down
right.
If
our
cooldown
isn't
set
to
the
lowest
possible
amount
like
one
block
or
whatever
it
means
that
we
can't,
we
can't
adjust
it
so
now,
because
this
other
third
delegator
showed
up,
we
have
no.
We
have
no
latitude
to
be
able
to.
We,
we
are
t
you
know.
Delegator,
1
and
delegator
2
are
are
going
to
effectively
be
earning
less.
D
A
D
B
Yeah
I
so
I
ran
the
numbers
a
few
weeks
ago
for
a
presentation
and
I
think,
like
the
average
delegation
ratio
like
in
the
for
most
indexers,
was
somewhere
around
like
three
to
four
in
the
three
to
four
range.
You
know
and
that's
out
of
a
total
delegation
ratio
or
capacity.
That's
like
16x
right
now,
right,
that's
set
in
the
protocol,
so
that
means
that
most
indexers
in
the
protocol,
the
rewards
that
they're
giving
away
their
effective
cut.
B
As
you
know,
gavin
described,
it
is
probably
actually
a
lot
higher
than
like
the
actual
cut
that
they
set.
So
that's
just
an
example
of
how,
like
that
inconsistency,
is
kind
of
manifesting
in
the
in
the
protocol
that
most
indexers
today
are
probably
giving
away
some
amount
up
above
and
beyond
what
they
intended
to
and
then,
as
their
delegation
shifts
like
that
effective
rate
changes,
which
you
know
I
think
is
gavin,
has
communicated
well,
creates
a
lot
of
unpredictability
on
both
sides
of
that
market
right
for
indexers
and
for
delegators.
D
Yeah,
so
I
mean
the
we
we've
had
issues
on
other
networks
with
be
certain
service,
staking
service
providers,
setting
zero
commit
percent
commission
and
everybody
kind
of
being
a
little
bit
of
up
in
arms.
This
actually
allows
them
to
have
a
negative
commission
rate
to
to
bribe
people
to
stick
with
them,
and
then
you
can't
really
leave
very
easily
otherwise
you're
giving
up
rewards
for
28
days,
you're
burning,
you
know
and
then
there's
some
other
things
that
maybe
are
out
of
scope
like.
D
I
don't
think
that
there
should
be
ability
to
over
delegate
at
all,
and
maybe
we
should
re-examine
whether
we
want
stickiness
like
that
steak
is
already
sticky
in
networks
that
don't
have
incentive
mechanisms
to
make
it
sticky
so
but
anyway,
those
those
are
other
things
that
maybe
we
should
be
thinking
about.
If
anyone
has
questions
about
this
sort
of
thing,
please,
like
I
said,
try
to
streamline
them,
use
the
forum
and
use
you
make
a
copy
of
this.
Try
it
out
for
yourselves.
Thank
you
for
your
time.
I'm
gonna
run.