►
From YouTube: Disputes & Arbitration
Description
Workshop recorded May 5th, 2021.
A
A
Hopefully,
all
of
you
guys
can
see
this
so
one
thing
I
want
to
emphasize
with
the
arbitration
charter.
This
is
the
the
gip
that,
like
I
said
that
we
went
through
yesterday,
is
that
this
isn't
giving
the
arbitrator
any
new
capabilities
right.
The
capabilities
of
the
arbitrator
are
sort
of
defined
and
you
know
hard-coded
into
the
smart
contracts
that
are,
you
know
in
solidity
that
have
already
been
deployed
to
the
network.
A
Most
of
you
should
know
what
the
arbitrator
does
at
this
point,
there's
effectively
two
types
of
disputes
that
I
guess
you
could
say
three
but
query,
and
in
dioxin
disputes
is
what
the
arbitrator
decides.
The
outcome
of
and
query
disputes
have
two
subtypes.
You
know
one
is
the
single
query:
attestation,
where
it's
just
the
fisherman
disputing
an
indexer
directly
and
then
another
is
where
a
fisherman
uses
two
indexers
to
kind
of
effectively
dispute
each
other.
A
A
big
part
of
you
know
what
felt
important
to
us
in
writing.
This
proposal
was
that
indexers
felt
confident
to
participate
in
this
kind
of
early
stage
of
the
network
without
the
fear
of
being
punished
for
things
that
are
outside
their
reasonable
control
or
outside
of
what
they
could
be
reasonably
expected
to
do
and
from
like
a
diligence
perspective,
and
so
a
big
part
of
that
is
like
we
don't
expect
all
indexers
to
be
graph
node
core
developers.
A
We
think
that
would
be
bad
for
decentralization
if
that
was
requirement,
so
the
arbitrator
has
the
discretion.
You
know
using
this
draw
outcome
mechanism
to
decide
disputes
as
draws,
if
there's
a
reasonable
evidence
that
it
was
due
to
a
you
know:
determinism
bug
in
graph
node
or
some
other
software-
that
the
kind
of
core
developers
have
shipped
to
to
indexers.
We've
seen
these
in
the
past.
A
A
Unfortunately,
today
the
attestation
data
structure
doesn't
have
any
replay
protection,
so
that
means
you
know
for
a
specific
query
request
response
pair
the
indexer
can
only
be
slashed
once
and
which
you
know
effectively
means
like
a
single
mistake
can't
be,
you
know,
can't
be
compounded.
You
know
by
someone
just
repeatedly
creating
disputes
for
that
mistake.
A
A
At
some
point
in
their
past,
right
and
and
so
like,
we
don't
also
want
to
punish
indexers
for
being
long
time,
honest
participants
in
the
protocol
by
saying
that
hey
you're,
just
constantly
accumulating
risk
of
being
slashed
for
something
you
did
at
some
point.
You
know
in
the
past,
so
we
think
the
statute
of
limitations,
kind
of
achieves
that
this
proposal
has
it
set
at
basically
two
thawing
periods,
so
56
epochs
mainly
to
give
the
arbitrator.
A
This.
This
should
be
pretty
straightforward,
but
disputes
can't
be
decided
as
a
in
anyone's
favor
if
the
data
isn't
available
to
look
at
the
dispute,
so
hopefully
we'll
get
to
some
of
this
in
the
tooling.
But
you
know
if
I
so.
As
you
know,
the
attestation
structure
just
has
like
the
content
hash
of
a
query
in
it
right.
It
doesn't
have
the
entire
query
body
itself
that
wouldn't
really
be
practical
to
store
on
chain
or
emit
in
a
solidity
event.
A
A
You
know
millions
of
queries
per
allocation,
and
so
if
each
of
those
queries
was
slashable,
and
even
if
the
slashing
percentage
was
like
really
small,
you
know
like
it
could
have
been
like
a
fraction
of
a
fraction
of
a
percent
that
would
still
be
potentially
enough
to
wipe
out.
You
know
an
indexer's
entire
stake
in
a
single
allocation.
A
This
also
piggybacks
some
of
the
work
that
rel
offers
some
of
the
work
that
rel
presented
yesterday
of
separating
the
slashing
percentages
and
the
protocol
for
indexing
aquarium.
So
today
it's
just
a
single
parameter
across
the
protocol.
You
know
an
indexing
dispute
and
a
query
dispute
are
punished
equally,
but
in
the
future.
If
that
proposal
is
accepted,
then
we'll
be
able
to
parameterize
the
query
slashing
percentage
lower
than
the
then
the
indexing
slashing
percentage
for
for
this
reason.
A
Valid
proofs
of
indexing
for
a
given
epoch,
it's
the
correct
behavior
for
an
indexers
to
submit
a
proof
of
indexing
for
the
first
block
of
the
epoch
in
which
they
closed
an
allocation
right
now
the
closed
allocation
transaction
doesn't
have
a
an
epoch
argument
or
parameter
so
there's
no
way
to
like
fail
that
transaction.
If,
for
some
reason,
let's
say
due
to
blockchain
congestion,
it
actually
ends
up
getting
mined
during
the
next
epoch.
A
So
for
that
reason,
if
a
proof
of
indexing
is
incorrect
for
the
epoch
in
which
an
allocation
was
closed,
but
it
is
correct
for
the
previous
allocation,
then
that
dispute
would
be
a
draw.
It's
basically
sort
of
a
there's,
a
little
grace
grace
window
there
in
the
future.
We
might
add
that
argument
to
the
to
the
closeoutlocation
method
in
the
future
proposal,
in
which
case
you
know
some
of
this
stuff
could
could
be
more
automated
and
then
the
last
one.
A
This
doesn't
really
impact
the
indexers,
but
this
is
just
more
about.
The
arbitrator
is
expected
to
settle
disputes
in
a
timely
manner
in
it
and
it
kind
of
defines
what
that
means,
and
so
the
rest
of
this
gip
is
just
rationale,
for
you
know
some
of
the
stuff
that
we
just
talked
through,
but
I
guess
I'll
pause
there.
Yesterday
we
didn't
get
a
lot
of
time
for
questions.
So
are
there
any
questions
specifically
on
the
contents
of
this
charter?
Zorro
slash
oliver,
I
know
you
had
some
feedback
in
the
forums.
A
A
A
Is
there
a
role
that
fishermen
and
arbitrators
should
be
independent?
There
isn't
a
rule
like
that
in
the
charter
right
now
and
it's
impossible
to
enforce
at
the
protocol
level
yeah.
I
guess
I
would
have
to
understand
the
motivation
behind
the
question.
If
it's
that
you
wouldn't
want
the
the
same
like
indexers
to
be
assigned
to,
I
I
guess
your
concern
is
that
you
don't
want
a
fisherman
to
basically
submit
a
dispute
and
then
just
arbitrate
themselves.
A
A
A
B
A
Cool
yeah,
thank
you
so
yeah.
This
has
been
posted
to
the
forum
for
about
a
week
or
so.
Oliver
has
some
great
feedback
in
there
that
we'll
try
and
incorporate.
So
I
encourage
you
guys
to
take
a
look
at
that.
Obviously
this
affects
you
know
indexers
quite
a
bit,
so
we
look
forward
to
your
feedback
and,
with
that
I'll
hand
it
off
to
ford
he'll
be
walking
through
so
the
splashing
penalty.
That's
going
to
be
covered
in
a
separate
gip.
A
A
And
yeah
and
feel
free
to
keep
posting
questions
in
chat.
We'll
move
on
to
forward
for
now,
but
we'll
have
some
time
for
q
a
at
the
end,
and
we
can
cover
this
stuff
as
well.
So
ford
will
be
talking
through
the
index
or
agent
which
is
used
for,
among
many
other
things,
detecting
bad
pois
from
other
indexers,
so
we'll
hand
off
the
ford.
C
What
do
I
mean
by
cryptographically
strong
here?
It
is.
There
is
no
chance
of
collisions
between
different
proof
of
indexing,
so
they
will
be
unique
and
it
does
not
leak
information.
So
you
cannot
use
a
poi
from
another
indexer
to
try
to
derive
one
for
yourself.
For
example,
each
poi
is
specific
to
a
deployment,
an
indexer
address
and
a
block
number.
C
The
information
in
the
poi
is
exposed
by
the
graph
node
indexing
node
graphql
endpoint.
So
you
can
query
that
on
your
infrastructure
at
any
point,
and
that
is
what
the
indexer
agent
uses
to
compare
against
the
network
pois
to
try
to
identify
disputes
and
the
poi
is
important.
It
must
be
submitted
with
an
allocation,
closed
transaction
in
order
for
that
allocation
to
be
eligible
for
rewards,
and
that
also
makes
it
eligible
to
be
disputed
and
potentially
slashed.
C
C
So
here's
my
indexer
agent
running,
you
can
see
a
log
here
that
shows
that
it
has
monitored
a
disputable
allocations
on
chain
and
has
found
some
valid
allocations
and
no
potential
disputes
in
that
in
that
run,
and
then
I'm
going
to
go
over
here
into
the
index
or
cli
and
what
I
can
do
is
I
can
call
that
disputes
get
command
and
list
any
potential
disputes
that
have
been
flagged.
So
you
can
see
here.
I
have,
I
think,
eight
disputes
that
have
been
flagged
and
you
can
see
the
information
from
those
allocations.
C
C
So
not
too
many
on
test
net
broken
out
by
deployment,
and
this
kind
of
just
gives
you
a
good
overview
of
what's
been
going
on
on
testnet
and
how
you
can
look
at
this
data
and
then
once
you've
identified
potential
disputes.
The
next
step
would
be
to
look
a
little
bit
closer
at
them
identify
ones
you
might
want
to
submit
as
disputes,
and
then
we
have
another
tool
that
ariel
is
going
to
talk
about
here
for
actually
submitting
those.
A
C
Yeah
so
that
endpoint
does
take
the
index
or
address
as
an
argument
along
with
the
deployment
id
and
a
block
identifier
and
so
in
normal
operation.
Your
indexer
will
use
your
indexer
address
to
create
pois
and
then
submit
those,
but
when
you're
checking
against
another
indexer
you'll
use
their
address
to
create
that
poi,
that's
unique
to
them.
C
A
D
Yeah
I'll
share
my
screen.
I
want
to
show
the
the
how
the
dispute
process
works
related
to
the
unchained
part.
The
first
thing
that
you
need
to
do
is
to
identify
a
potential
dispute
like
ford
show,
but
then
there's
a
process
of
submitting
that
dispute
on
chain
to
a
contract,
so
the
the
visuals
are
currently
managed
by
a
contract
called
the
dispute
manager.
D
This
is
the
implementation
I
was
looking
at
the
proxy,
so
the
the
first
thing
you
need
to
do
is
to
to
interact
with
this
contract
by
creating
a
dispute
passing
the
information
related
to
the
allocation
id
or
the
query.
That
is
wrong
and
for
doing
that,
you
can
use
any
tool
because
the
contract
is
open
and
it's
out
there
and
you
can
use
remix.
You
can
use
etherscan,
but
we
created
a
tool
to
do
that
easily
a
cli
tool.
D
D
If
you
go
to
network
you'll,
see
that
variable
here,
2.5
and
this
is
set
by
governance
and
is
stored
in
the
dispute
manager
contract
that
I
show
so.
This
dispute
manager,
whenever
you
present
a
dispute
and
is
resolved
by
the
arbitration,
will
talk
with
this
taking
contract
and
will
slash
based
on
the
indexer
stake
and
this
2.5
percent.
Okay.
D
So
that's
that's
one
of
the
important
variables
you
want
you
you
want
to
see,
then
there's
a
different
governance
parameter
related
to
disputes.
That
is
the
percentage
of
the
slash
that
the
the
the
submitter
of
the
dispute
we
get.
So
when
I,
when,
when
a
dispute
is
resolved
accepted
and
the
indexer
is
slashed,
50
of
that
slash
is
going
to
go
to
the
submitter
of
the
of
the
dispute.
D
That's
another
value
that
is
set
by
governance
and
the
last
one
is
the
the
bond
that
you
need
to
present
as
a
submitter.
If
you
find
a
dispute-
and
you
want
to
dispute
that
and
present
that
in
the
in
the
difficult
manager
you
need
to
deposit
10
000
grt,
now,
okay,
so
so
that's
something
that
you
need
to
to
have
before
creating
a
dispute.
D
D
You
need
an
ephedium
node,
because
it's
going
to
interact
with
the
contrast.
You
need
the
networks
graph
url,
because
it's
going
to
query
for
allocations
and
and
some
information
to
present
on
the
in
the
in
the
script,
you
will
need
a
private
key,
so
you
send
the
transaction
to
the
field
manager
contract
and
you
need
the
funds,
the
10k.
If
you
are
going
to
dispute,
then
this
this
all
the
things
are
configurable.
D
In
these
cases,
the
the
parameters
that
you
need
to
pass
change
a
bit
in
the
case
of
an
indexing
dispute,
you
will
pass
the
allocation
id
that
you
find
it's
using
a
bad
proof.
In
the
case
of
a
query
dispute,
you
will
present
an
attestation
that
the
indexer
is
going
to
send
you,
okay
as
a
response,
then
you
can
pass
it
the
deposit
that
I
said
like
the
minimum.
D
The
minimum
deposit
is
10k,
but
you
can
you
can
pass
any
number
about
that
10k
and
then
it
also
provides
some
commands
that
will
be
used
for
arbitration
to
reject,
accept
or
draw
the
dispute.
This
is
this
is
going
to
be
used
by
the
by
the
arbitrators
to
to
basically
decide
what
to
do
with
that
dispute.
D
D
What
you
need
to
do
you
need
to
know
is
that
anyone
can
dispute.
It's
like
a
public
process
like
anyone
can
call
this
create
dispute
function,
so
anyone
that
is
monitoring
the
network
can
create
a
dispute
on
our
location
id,
but
there
are
some
conditions
well
first,
this
is
the
the
an
example
of
the
how
you
would
call
the
cli
to
to
create
the
transaction
that
will
submit
the
dispute.
D
So,
when
you're
creating
these
these
disputes,
there
are
some
things
that
are
enforced
by
the
contract.
You
can't
you
can't
create
multiple
disputes
from
the
same
allocation.
That's
one
thing:
the
allocation
must
exist
in
the
seeking
contract.
If
you
pass
like
a
random
allocation
id,
it's
not
going
to
work.
It's
going
to
revert,
the
indexer
must
have
some
stake.
D
D
Then
the
other
type
of
dispute
is
the
query.
Disputes
indexers
are
responding
to
queries
and
it's
going
to
sign
attestations
based
on
the
response,
and
these
attestations
can
be
used
as
a
receipt
that
if
the
consumer
finds
the
query
to
be
invalid,
it
can
use
this
attestation
to
submit
a
file
a
dispute.
Okay.
D
So
in
this
case
we
will
use
instead
of
create
indexing,
we'll
create
query
the
query
dispute
and
we
will
pass
the
bytes
this.
This
is
the
basically
this
structure
getstation,
but
in
invite
format,
and
this
will
submit
the
equity
dispute
in
the
in
the
dispute
manager
contract.
Okay,
an
additional
information
that
needs
to
be
available
is
the
the
actual
query
that
you
did
and
that
needs
to
be
available
in
ipfs,
because
this
whole
process
is,
we
need
to
reproduce
the
the
the
dispute,
so
we
can
know
if
it's
right
or
wrong.
D
So
this
the
request
needs
to
be
available
in
ipfs,
so
some
conditions
enforced
by
the
contract.
Only
one
dispute
with
the
same
data
and
some
meter
can
be
active
if
the
any
of
these
conditions
will
revert.
If
it's
not
fulfilled
the
index
might
have
a
available
stake
and
the
deposit
must
be
over
the
minimum
required
again.
In
this
case,
the
the
cli
will
help
to
enforce
the
charter
by
not
submitting
disputes
that
are
going
to
be
draw
by
the
arbitrator.
Okay.
D
A
D
D
D
D
D
So
in
this
case
the
reference
poise
doesn't
match
with
the
one
with
this
one
in
this
case,
there's
a
lot
of
leading
ceos.
It's
a
bit
strange
and
it's
a
it's
a
bad
proof,
so
the
arbitrator
can
assume
that
this
poi
is
is
really
a
wrong
one
and
then
decide
to
accept
the
the
dispute.
Okay.
But
anyone
can
use
this
this
tool
to
list
the
the
current
disputes
in
the
contract.
D
The
other
condition
could
be
to
be
rejected,
and
that
means
that
the
indexers
won't
be
slashed
and
the
fisherman
will
lose
all
the
the
deposit
and
the
last
condition
will
be
a
draw
where
the
indexer
is
not
slow
is
slashed
and
the
fisherman
will
not
lose
the
deposit,
basically,
okay,
so
that's
more
than
like
the
neutral
one.
One
note
is
that
the
dispute
id
that
I
showed
here
is
created
within
the
contract.
It's
basically
a
hash
of
some
fields
to
to
avoid
duplication
of
of
the
of
the
issues
you
present.
A
Yeah,
I
think
I
think
these
things
types
of
things
are
all
in
the
design
space.
One
thing
actually
that
that
relates
to
is
another
question
that
I
saw
come
up
from
state
machine
which
basically
asks
you
know.
If
an
indexer
knows
that
he
submitted
a
bad
poi,
can
he
open
a
dispute
on
itself
and
minimize
splashing
effect?
In
any
case,
the
reason
I
think
both
your
questions
are
related
is
because
it
relates
to
like
what
are
the
true
penalties
for
being
slashed.
A
So
I
don't
know
how
many
of
you
guys
were
in
I'm
trying
to
think
the
last
time
we
did
a
workshop
on
indexer
selection.
It
might
have
been
even
the
test
net
might
have
been.
You
know,
after
the
network
launch,
but
the
indexer
selection
algorithm
that's
run
by
both
the
gateway
and
the
query
engine.
It
actually
takes
into
account
a
whole
list
of
factors
that
it
basically
applies.
Utility
functions
to
so
some
of
those
are
things
like
performance.
You
know
throughput
latency
availability,
you
know,
are
you
always
online?
A
A
A
There's
a
couple
that
I
can
list
off
the
top
of
my
head
and
I
think
ford
might
be
able
to
elaborate
on
some
more
that
that
we've
seen.
But
you
know,
one
example
could
be
like
your
ethereum
provider
or
ethereum
know
that
you're
running
being
faulty
right
so
either
like
you
know,
right
now,
the
graph
node
relies
on
calls
to
like
eth
get
logs
to
make
sure
that
it's
getting
events.
A
You
know
we've
seen
cases
in
the
past
where
either
events
were
missed
or
events
were
duplicated
by
the
ether
by
the
ethereum,
node
or
ethereum
node
provider,
and
so
that
could
be
a
cause
outside
of
graph
node
that
leads
to
determinism
issues,
because
you're,
basically
double
processing
or
missing
an
event
another
one
that
we
talked
about
yesterday.
This
will
be
a
new
kind
of
case.
Is
that
graph
nodes,
starting
with
1.0
release,
is
going
to
adopt
december
conventions?
A
So
the
idea
is
that
the
protocol,
at
any
given
point
will
have
like
an
official
major
version
of
graph
node,
but
that
minor
versions
are
meant
to
be
backwards
compatible
with
one
another.
With
respect
to
you
know
the
proofs
of
index
seen
in
queries
that
would
be
produced,
so
you
could
imagine
like
a
bug
that
the
core
developers
introduced
where
they
just
accidentally.
A
C
C
Maybe
your
index
or
agent
is
talking
to
a
mainnet
sub
graph
and
getting
the
incorrect
epoch
value,
and
so
it
submits
for
the
wrong
block
number
or
other
other
small
issues
like
that.
That
often
will
lead
to
the
poi
being
valid,
but
not
lining
up
with
the
arbitration
charter
and
being
for
the
correct
epoch.
A
Yeah,
that's
a
great
point
and
we've
gotten
pretty
good
at
I'd,
say
debugging
and
root,
causing
a
lot
of
these
determinism
bugs.
I
know
ford
and
rdl
spent
a
lot
of
time
actually
when,
when
implementing
the
index
or
agent
cross,
checking
specifically
looking
at
that
last
class
of
determinism
bugs
so
one
thing
I
forgot
to,
I
guess:
drill
down
on
the
arbitration
charter
was
just
what
do
you
do
when
you
see
yourself
being
disputed
on
shane
like
what
should
your
next
steps
be?
A
That's
where
you
know
that
root
cause
analysis
can
happen
so
like
if
you
were.
You
know
if
you
believe
that
you
know
the
proof
of
indexing
was
incorrect
because
you
thought
the
epoch
was
wrong
or
you
know,
or
you
think,
there's
a
determinism
bug
in
the
you
know
the
graph
node
or
you
think
there
was
an
issue
with
your
ethereum
node
provider.
That's
that's
the
place
where
we
can
share
logs.
We
can
you
know
we
can
kind
of
investigate.
It's
meant
to
be
a
collaborative
process.
A
A
So
you
know
we've
already
seen
this
with
like
the
subgraph
migration,
I
would
say
there
was
like
a
you
know,
certain
set
of
indexers
that
were
like
ready
and
saw
that
the
subgraphs
were
migrating
and
like
took
action
immediately
and
we
saw
other
indexers
were
a
little
bit
slower
to
respond
because
they're
sort
of
not
actively
engaged
in
the
network.
So
I'd
say
at
the
phase
that
we're
at
now
it
is.
A
It
is
primarily
the
indexers
responsibility
to
be
active
and
engaged
and
make
sure
that
they're,
you
know
participating
with
the
mec
the
the
mechanisms
of
the
protocol
responsibly
in
the
future.
There
should
be
a
lot
more
tooling
available,
so
someone
already
asked
in
the
chat
whether
there
was
a
way
to
query
the
disputes
outside
of
looking
at
the
contracts
directly.
There
is
a
disputes
entity
in
the
network
subgraph,
which
a
lot
of
community
members
have
already
been
built
using
to
build
their
sort
of
third-party.
A
You
know
dashboards
and
network
explorers.
I
fully
expect
that,
as
you
know,
as
we
see
more
usage
of
the
mechanism,
we'll
see
a
lot
more
of
that
incorporated
into
those
explorers.
It's
also
on
the
roadmap
for
the
some
of
the
web
apps
products
that
edge
node
is
working
on,
although
it
won't
be
part
of
the
it
likely
won't,
be
part
of
the
the
mvp
release.
That's
happening
at
the
end
of
the
the
phase.
Three
migration.
A
A
And
I
believe
to
your
follow-up
question:
what
about
rebate
pull
rewards
so
all
so
for
the
indexer
like
once
rewards,
are
settled,
I
believe,
they're
all
part
of
the
same,
like
pool
of
funds
from
the
perspective
of
the
protocol.
So
at
the
point
that
once
they're
in
there
they're
they're
slashable,
I
don't
think
the
part
of
the
rebate
pool
that
goes
to
like
delegators
that
wouldn't
be
slashable.
For
example,.
A
Yes,
right
now,
so
someone
asked
is
this
over
the
allocated
stake
on
the
specific
subgraph
today.
The
way
that
it
works
in
the
mechanism
is
that
it
is
over
the
total
index
or
stake.
I
actually
just
as
an
aside.
I
do
believe
there.
There
would
be
there's
valid
reasons
for
shifting
that
to
the
allocated
stake.
That's
kind
of
on
my
personal
backlog
of
proposals
to
work
on,
but
today
the
way
that
it
works
in
the
contracts
is
that
it's
the
total
the
total
stake
owned
by
the
indexer.
C
A
One
one
question
that
sounds
like
we
might
have
missed
was:
how
long
does
it
take
to
resolve
a
dispute?
So
the
expectation
that's
set
in
the
arbitration
charter
is
that
the
arbitrator
should
attempt
to
settle
dispute
within
one
bond
period.
That's
kind
of
logical
since
an
attacker
would
presumably
exit
immediately,
and
then
we
only
have
one
thawing
period
to
slash
them
in
practice.
That
might
not
always
be
possible.
A
So
this
isn't
the
kind
of
thing
that's
gonna
like
if
an
arbitrator
is
not
gonna
be
removed
for
not
always
meeting
that
goal
specifically
because
the
arbitrator
needs
to
be
able
to
recreate
the
work,
that's
implied
in
the
dispute,
and
so
sometimes
that's
going
to
be
a
quick
and
easy
process.
Sometimes
that
might
be
a
longer
process.
A
As
I
mentioned
earlier,
the
the
initial
arbitrators
that
are
set
in
the
multi-sig
are
or
are
that
are
part
of
the
arbitrator.
Multisig
rather
are
ariel
dave
and
giannis,
and
so
they're
sort
of
proactively
running.
You
know
kind
of
their
indexer
to
basically
be
in
a
position
where
they
can
reproduce
work
very
quickly.
But
if
a
dispute,
for
example,
were
to
come
up
for
like
some
subgraph
that
somehow
they're
not
already
indexing,
then
it
might
take
longer
as
they
you
know,
index
this
new
subgraph
from
scratch.
A
A
So
it
kind
of
your
last
question
kind
of
made
me
made
me
think
of
this,
which
is
just
you
know
what,
if
someone,
what,
if
the
malicious
indexer
submits
a
you
know,
subgraph
that's
impossible
for
the
arbitrator
to
index
and
reproduce
the
work
on
or
is
exceedingly
difficult.
For.
You
know
some
known
set
of
reasons.
So
that's
the
role
of
the
subgraph
oracle.
A
State
machine
is
asking
what
about
serving
bad
data
for
queries.
So
that's
that's
the
second
like
big
category
of
disputes
that
we
talked
about.
I
think
it
was
the
first
category
that
or
the
second
category
that
rl
showed
in
the
tooling,
but
that's
the
query.
Attestation
disputes
so
there's
a
couple
different
types
of
those
but
yeah,
absolutely
there's
a
dispute
process
for
those.
B
A
B
Thought
was
the
idea
of
an
appeal
process,
which
I
don't
think
I've
seen
in
the
arbitration
charter,
and
I
don't
know
if
that
is
something
to
consider.
But
the
idea
would
be
that
an
indexer
has
an
opportunity
to
appeal
the
decision
of
the
arbitration,
not
necessarily
based
on
content
but
maybe
based
on
process.
A
Yeah,
so
that's
a
really
interesting
idea.
One
thought
I
had
here
that
I
didn't
put
into
the
arbitration
charter,
because
mainly
the
charter
was
about
non-code
changes,
but
I
think
it
could
be
interesting
to
put
like
a
waiting
period
on
this
flashing.
That's
something
we
could
explore
in
the
future
so
like
the
arbitrator,
makes
their
decision
and
the
indexers
stake
at
that
point.
A
Can't
exit
the
protocol,
so
it's
sort
of
like
frozen,
but
but
maybe
they're
not
slashed
right
away,
and
that
would
actually
you
know,
give
the
graph
council,
for
example,
time
to
act
as
in
like
an
appeals
body,
if
you
know,
for
some
reason
the
arbitrator
needed
to
be
removed
if
they
were
making
like
a
string
of
bad.
You
know
bad
decisions,
so
I
think
these
are
really
great
suggestions
that
could
either
be
worked
into
either
this
charter,
or
you
know,
just
future
proposals
for
improving
and
hardening
the
arbitration.
A
B
I
think
most
of
the
other
items
that
I've
posted
on
the
forum
have
since
been
addressed
by
just
getting
deeper
insight
into
the
clutter
and
also,
as
far
as
I
had
one
comment
on
the
penalty
and
what
levels
but
ariel
walked
us
through
that
today
as
well.
So
I
think
you
know
what
I've
brought
up
were
the
ones
that
I
think
are
still
maybe
valid.
Ideas
to
consider
everything
else,
I
think
is,
is
addressed.
A
C
C
A
Cool,
so
it
looks
like
we're
at
the
top
of
the
hour
here.
If
you
guys
have
any
other
questions,
you
know
please
find
us
on
discord.
Performs
you
kind
of
know
know
how
to
reach
us,
but
yeah
thanks
for
everyone,
for
your
questions
for
showing
up
and
yeah
good
luck
with
the
rest
of
the
migration
workshops.