Rewards eligibility: the gate nobody told you about

Allocating stake and submitting a valid POI used to be the whole of what indexing rewards required. Since GIP-0079 it is not. There is a second gate, asserted by an oracle, and an indexer who fails it earns nothing on allocations that are otherwise perfectly healthy.

The argument for the change was that rewards were reaching indexers who were not serving anybody. The gate is the answer to that: to collect issuance you must be demonstrably answering real queries from real users.

The criterion, in full.

It is one sentence, and it is worth reading slowly because almost every misunderstanding comes from reading it fast.

You must be active on 5 days within a rolling window of 28 days. A day counts as active if you served at least one qualifying query that day. A query qualifies only if it satisfies all three of these at once, on the same query:

• The response status was 200 OK.
• The response took less than 5,000 ms.
• The data served was less than 50,000 blocks behind chainhead.

A query that returns quickly but from a deployment three hundred thousand blocks behind is not a qualifying query. Neither is a fresh, correct answer that took six seconds. The three conditions are a conjunction, not a score.

What it is not.

This is the part people get wrong, and the error is expensive because it is an error in the direction of complacency.

It is not a rate. There is no queries-per-second threshold anywhere in the criterion, and no percentage of network traffic you have to capture. One qualifying query on 5 days is sufficient. A million queries a day on four days is not. The measurement is a daily boolean, and the count of true days is the only thing that matters.

It is not an uptime measure. GIP-0079 describes 5 days out of 28 days as roughly 18% uptime and says the initial thresholds were “intentionally set conservatively”. The bar is deliberately low. It is there to exclude indexers serving nobody, not to rank the ones who are.

It is not a competition. Nothing about your eligibility depends on how any other indexer performed. Every indexer who clears the bar clears it.

Where the number actually comes from.

Here is the part that costs people money.

The oracle does not read your indexer. GIP-0079 states that “the initial implementation of Oracle Nodes builds upon pre-existing data pipelines (from our geographically distributed gateways into Google BigQuery) and queries that data directly”. The input is the gateway’s record of what it routed to you and how that went.

Your own telemetry is a different measurement of a different population. An indexer-service query counter increments for everything that reaches your endpoint, including traffic that never came through a gateway and therefore never entered the pipeline the oracle reads. The two numbers are not the same number, and they can disagree in the one direction that hurts:

Two consequences worth internalising.

You cannot self-test eligibility by generating load against your own stack. Traffic you send yourself is invisible to the oracle by construction.

And a green local dashboard is not evidence of eligibility. If the gateway is not routing to you, every counter you own can look correct while the criterion is being failed continuously. The usual reasons the gateway routes you nothing are a cost model priced above the field and the gateway’s own performance policy, neither of which raises anything on your side.

Status, periods and renewal.

The oracle runs daily and publishes to a contract on Arbitrum One. Every registered indexer has a status from the moment the oracle runs, so the answer to “does my status only appear after I have been active for 5 days” is no. Before you qualify you are not blank, you are Unqualified, which is a stated result rather than an absence of one.

The statuses on the live dashboard read as follows.

• Eligible. You cleared the bar and are inside a current period.
• Grace. Eligible, with the end of the period approaching.
• Unqualified. Never renewed, or did not meet the criteria.
• Expired. A period ended and was not renewed.

Qualifying does not grant eligibility permanently and does not grant it for a single day. It grants a period, 14 days by default, and the criteria document is explicit that you keep earning for the whole of that period even if the criteria change afterwards. The default is worth checking rather than assuming: the oracle repository states the live value is readable from the contract.

Because evaluation is daily and the window rolls, there is no cliff to plan around. There is a continuous requirement that some real traffic reached you recently, and a buffer of roughly a fortnight behind it.

Is it actually enforced?

Worth asking rather than assuming, because until recently the answer was no. On 2026-08-20 the deployed Rewards Manager had none of the machinery to act on a verdict: getProviderEligibilityOracle() reverted, along with every other function GIP-0086 adds. The oracle published and nothing consumed it.

That changed at some point in the eleven days after. Read from Arbitrum One at block 500226907 on 2026-08-31, the Rewards Manager at 0x971B9d3d0Ae3ECa029CAB5eA1fB0F72c85e6a525 answers:

An oracle address is set, a reclaim address is set, and getRevertOnIneligible() is true. That last one is the operationally interesting flag: the contract is configured to revert on an ineligible indexer rather than quietly return zero. A reverting transaction is at least a loud failure, which is a mercy on a site whose recurring theme is that nothing here fails loudly.

The 2026-08-20 reading is graph-support #23, which carries the reverting calls in full. Neither this page nor that issue has established the block at which the upgrade landed.

Two honest limits on the current reading. It is a point in time, and these values are governable, so re-run the calls rather than trusting this paragraph. And a configured flag is evidence that the path exists, not a measurement of it firing on a real ineligible indexer, which is not something this page has observed.

What “rolling” actually means, and the mistake it causes

The window is the last 28 days, counted backwards from today, and it moves forward a day at a time. Nothing resets it and nothing starts it. There is no enrolment.

Two consequences follow, and the second one catches people.

A bad day costs you nothing except itself. Days you did not serve do not subtract, they simply fail to count. A month of silence followed by five good days qualifies you.

Fixing the cause does not start a five-day clock. This is the mistake, and it is an easy one to make. The counter advances only on days you actually served a qualifying query, and serving one requires the gateway to route you a query in the first place. Those are different events, days apart, and repairing your side only enables the second.

So “I fixed it more than five days ago and I am still Unqualified” is not a contradiction and usually is not a bug. It means fewer than 5 days of those days produced a qualifying query, and the reason is almost always that the gateway was not sending you any. An indexer it has recently found unreachable does not get traffic back the instant the firewall changes, and nothing announces when it resumes.

Count qualifying days, not days since the repair. They are rarely the same number.

How to check while you are still Unqualified

Three instruments, and it is worth being precise about what each can and cannot see.

The contract, for the verdict. Eligibility is published on chain and you can read your own without a dashboard. The oracle proxy is 0x02753BaE61C08AbD4351Bce7F48524935C2Cc78E on Arbitrum One:

That is the answer, not a view of it. What it will not give you is a history: there is no public getter for when you last renewed or which days counted, so the contract tells you where you stand and not how you got there.

Your own metrics, for a fast negative, read carefully. An indexer-service query counter cannot prove you are eligible, because it counts traffic the oracle never sees. A flat counter does tell you something, but less than it appears to, and getting this wrong sends people chasing the wrong half of the system.

A query has to clear receipt validation before it is served, and the query counter sits after that gate:

So a flat counter means no query was served. It does not tell you which of the two reasons applies, and they need opposite responses:

• Nothing was routed to you. Then the question is coverage, price and the candidate-set thresholds, and it is about how you look to the gateway.
• Everything was routed and rejected. Then the gateway is doing its job, the queries are arriving, and something in your own receipt configuration is throwing them away before they reach graph-node.

Break the counter down per deployment either way. Total traffic hides the case where one busy deployment carries you and the rest get nothing.

Somebody else’s view, for the population that counts. The oracle reads gateway records, so gateway-side query volume attributed to you is the closest public proxy for its input. Graph Explorer and Lodestar both surface it. Neither is the oracle’s own pipeline, so treat agreement as reassurance and disagreement as a question rather than either as proof.

Where the trust sits.

Eligibility is an oracle assertion, and that puts it in a different category from everything else that determines what you are paid.

A POI is a claim you make, and the protocol’s answer to a wrong claim is a dispute with staked capital behind it. An eligibility verdict is not a claim you make. It is an assertion about you, derived from data you do not hold, published by an oracle appointed through governance. There is no arbitration path for it in the way there is for a disputed POI.

That is not an accusation. Some facts genuinely cannot be computed on chain and this is one of them. But it does mean the recourse for a wrong verdict is governance rather than adjudication, and it is worth knowing which of the two you are in before you need one.

What to monitor.

The failure is silent in the usual way. Allocations stay open, POIs keep being accepted, nothing errors, and the rewards are simply not there.

• Your status on the oracle, directly. It is the only measurement that counts, and it is published. Do not infer it from your own metrics.
• Whether the gateway is routing to you at all, per deployment. Zero routed traffic is the actual failure mode behind most ineligibility, and it looks exactly like an absence of demand. Alert on a query counter that stops moving, not only on one that errors.
• Latency and chainhead distance as a pair. Each is fine alone and the criterion needs both at once. A deployment falling behind stops producing qualifying queries while continuing to answer every one of them with a 200.