Every number, with its receipt.

Minimum Indexer self-stake

The minimum stake for an Indexer is currently set to 100K GRT.

Maximum delegation ratio

The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.

Maximum POI staleness

The maxPOIStaleness parameter is currently set to 28 days.

Allocation lifetime

Under Graph Horizon, allocations can remain open indefinitely. There is no requirement to close an allocation to collect rewards.

The protocol permits indefinite allocations. The shipped indexer stack does not yet use them. The Horizon changes page states: "At Horizon launch the indexer stack will continue to operate using the current 'short lived' allocation lifecycle for an easier transition. This means that allocations will be recycled typically every 28 days." Teach the protocol capability and the operational reality as two separate facts, because an indexer planning capacity needs both.

2025-12-11 Capped, closed to collect rewards → Indefinite in the protocol, still recycled by the shipped stack via Graph Horizon

Maximum slashable percentage

Arbitrators now have the flexibility to determine appropriate slash amounts based on the severity and context of infractions, up to a cap of 10% of the indexer's stake.

2025-12-11 Fixed by the protocol → Judged by arbitrators, capped at 10% via Graph Horizon

Recommended slash amount

The recommended value is 2.5% of the indexer's stake.

Fisherman dispute deposit

A deposit of a minimum of 10,000 GRT is required by the Fishermen.

Undelegation (thawing) period

When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.

Delegation tax

The 0.5% delegation tax has been completely removed.

Removed by Graph Horizon. The tokenomics page has not caught up: as read on 2026-08-30 it still states "There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network." Two official pages, two answers. The Horizon pages are the current ones. A delegator who budgets for a 0.5% haircut on deposit is working from stale documentation.

2025-12-11 0.5% → 0% via Graph Horizon

Simultaneous undelegation requests

Horizon supports up to 1,000 simultaneous undelegation requests, removing the previous restriction to a single active undelegation at a time.

The two official pages disagree, and both were read on 2026-08-30. The Delegating page says 1,000. The Horizon changes page says "Delegators can now have multiple undelegation requests processing simultaneously (up to 100)." Unresolved. The practical guidance does not turn on which is right, because both are far above what any delegator queues in practice, but the registry records the conflict rather than picking a winner. Resolution requires reading MAX_THAW_REQUESTS on the deployed HorizonStaking contract.

2025-12-11 1 → 1,000 or 100, sources disagree via Graph Horizon

Delegated stake slashable

Horizon introduces the technical capability for delegated stake to be slashed in the future. This capability is not currently enabled for SubgraphService.

A capability that exists and is switched off. Teach it as a future risk, never as current behaviour, and never omit it.

2025-12-11 Not possible → Capability present, disabled for the Subgraph Service via Graph Horizon

Curation tax

Curators pay a 1% curation tax when they curate a new Subgraph. This curation tax is burned, decreasing the supply of GRT.

L2 curation bonding curve

The curation bonding curves on L2 are flat, which makes it easier for other Curators to curate on subgraphs, increasing the rewards for Indexers.

Signal and unsignal cost the same regardless of who signalled first. The L1 early-mover advantage is gone.

2023 Bonding curve → Flat via The move to Arbitrum One

Suggested self-curation signal

Subgraph developers are encouraged to curate their Subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.

Annual GRT issuance

The total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.

Initial GRT supply

The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on Subgraphs.

Query fee burn

1% of the query fees paid to the network are burned.

Protocol settlement layer

The Graph protocol contracts and GRT operate on Arbitrum One.

Rebate function lambda

We believe setting lambda=0.6 and alpha=1 ensures there will be enough stake to secure the network without putting too much of a staking burden on indexers.

The value proposed in GIP-0051. The deployed value lives in contract storage as lambdaNumerator / lambdaDenominator and can be changed by governance without a new GIP number. The GIP's own worked figures reproduce exactly at lambda 0.6 and alpha 1: a stake ratio of 4 returns 90.9% of fees, 6 returns 97.3%, 8 returns 99.2%. Anyone sizing real stake should read the contract rather than this page.

Rebate function alpha

Where 0 <= alpha <= 1 and lambda > 0 are protocol parameters.

Query fees burned under Cobb-Douglas

Query fee burn would be less than 7%, which is in stark contrast to the current mechanism which historically has burned over 50% of query fees.

The mechanism this replaced. Retained because the size of the improvement is the argument for the change, and because pre-2023 material still teaches Cobb-Douglas as current.

2023 Cobb-Douglas, over 50% of query fees burned → Exponential rebates, under 7% projected via GIP-0051

Issuance redirected to the Innovation Allocation

The Graph Council has approved GIP-0089, directing 20% of protocol issuance to the Innovation Allocation.

Approved by Council on 2026-08-26 and now flowing. The gap this entry used to record is closed: at Arbitrum One block 504192623 the Issuance Allocator at 0xb64f29b2d81140ffc3a135e319561a1bd03b1a7e allocates 96.584 GRT per block to the Rewards Manager out of a total 120.73, so 20% goes elsewhere. Confirmed by a second read at block 504322516 against a public RPC. The date it activated is not established here; what is recorded is the first block at which it was observed, which is the honest claim.

2026-08-26 0% → 20% approved via GIP-0089

2026-09-12 20% approved, 0% flowing → 20% flowing via IssuanceAllocator

Issuance reaching the Rewards Manager

The SubgraphService Rewards Manager receives 96.584 GRT per block, a reduction of 24.146 GRT per block from 120.73.

The approved figure and the deployed figure are the same figure now. Read from Arbitrum One at block 504322516: the Issuance Allocator at 0xb64f29b2d81140ffc3a135e319561a1bd03b1a7e returns 96584000000000000000 for the Rewards Manager at 0x971B9d3d0Ae3ECa029CAB5eA1fB0F72c85e6a525, out of a total of 120730000000000000000. Reproduce with cast against any public Arbitrum One RPC; it takes a minute and it beats trusting this file. This entry used to be reconciled against issuancePerBlock() on the Rewards Manager, which still returns 120.73 and is not the same question. That is the manager's own configured rate; what reaches it is decided by the allocator, and this label says "reaching". The check agreed with a figure that had stopped being true, because it was reading the wrong function.

2026-08-26 120.73 GRT/block → 96.584 GRT/block approved via GIP-0089

2026-09-12 120.73 GRT/block → 96.584 GRT/block via IssuanceAllocator

Active days required for rewards eligibility

Indexers must be active for 5+ days in a given 28 day period for rewards eligibility.

Rewards eligibility evaluation window

Indexers must be active for 5+ days in a given 28 day period for rewards eligibility.

Rolling, not calendar. GIP-0079 describes it as a rolling 28-day evaluation window and notes the 5-day requirement is roughly 18% uptime across it. Numerically equal to max_poi_staleness_days and unrelated to it.

Rewards eligibility period

can continue claiming indexing rewards from the protocol for the duration of the qualification period (default is 14 days)

Confirmed on chain rather than taken from the document: getEligibilityPeriod() on the oracle at 0x02753BaE61C08AbD4351Bce7F48524935C2Cc78E returned 1209600 seconds, exactly 14 days, at Arbitrum One block 500226907 on 2026-08-31. It is a governable default, so read it again rather than planning around this line.

Maximum latency for a qualifying query

Query Response Latency: < 5,000 ms

Maximum chainhead distance for a qualifying query

Query Freshness: < 50,000 blocks behind chainhead