The registry
Every number, with its receipt.
No lesson on this site hard-codes a protocol number. They all call this registry, and every entry carries the source, a quote from it, and the date a human opened that page and read the value there.
This page is not live. It is a record of what official sources said on the dates shown. Before acting on any figure, confirm it against the linked source or the deployed contract.
No parameter here has gone more than 90 days without being re-read.
Where the sources disagree
Recorded, not resolved.
These are cases where two official pages give different answers, or where the protocol permits one thing and the shipped software does another. Picking a winner quietly would be more comfortable and less useful.
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.
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.
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.
primary source · conflicting source · settle it at HorizonStaking.MAX_THAW_REQUESTS
Indexing
| Parameter | Value | Status | Read on |
|---|---|---|---|
| Minimum Indexer self-stake min_indexer_self_stake | 100,000 GRT GRT | current | 2026-08-30 |
| Maximum delegation ratio max_delegation_ratio | 16x x self-stake | current | 2026-08-30 |
| Maximum POI staleness max_poi_staleness_days | 28 days days | current | 2026-08-30 |
| Allocation lifetime allocation_lifetime | Indefinite | disputed | 2026-08-30 |
| Maximum slashable percentage max_slash_pct | 10% % of stake | current | 2026-08-30 |
| Recommended slash amount recommended_slash_pct | 2.5% % of stake | current | 2026-08-30 |
| Fisherman dispute deposit fisherman_dispute_deposit | 10,000 GRT GRT | current | 2026-08-30 |
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.
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.
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.
Delegation
| Parameter | Value | Status | Read on |
|---|---|---|---|
| Undelegation (thawing) period undelegation_period_days | 28 days days | current | 2026-08-30 |
| Delegation tax delegation_tax_pct | 0% % | deprecated | 2026-08-30 |
| Simultaneous undelegation requests max_simultaneous_undelegations | 1,000 requests | disputed | 2026-08-30 |
| Delegated stake slashable delegated_stake_slashable | Not currently | current | 2026-08-30 |
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.
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.
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.
Curation
| Parameter | Value | Status | Read on |
|---|---|---|---|
| Curation tax curation_tax_pct | 1% % (burned) | current | 2026-08-30 |
| L2 curation bonding curve l2_curation_curve | Flat | current | 2026-08-30 |
| Suggested self-curation signal recommended_dev_signal | 3,000 GRT GRT | current | 2026-08-30 |
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.
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.
Tokenomics
| Parameter | Value | Status | Read on |
|---|---|---|---|
| Annual GRT issuance annual_issuance_pct | 3% % target | current | 2026-08-30 |
| Initial GRT supply initial_supply | 10 billion GRT GRT | current | 2026-08-30 |
| Query fee burn query_fee_burn_pct | 1% % of query fees | current | 2026-08-30 |
| Protocol settlement layer settlement_layer | Arbitrum One | current | 2026-08-30 |
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.
Query fee rebates
| Parameter | Value | Status | Read on |
|---|---|---|---|
| Rebate function lambda rebate_lambda | 0.6 | current | 2026-08-30 |
| Rebate function alpha rebate_alpha | 1 | current | 2026-08-30 |
| Query fees burned under Cobb-Douglas cobb_douglas_burn_pct | over 50% % historically | deprecated | 2026-08-30 |
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.
Issuance routing
| Parameter | Value | Status | Read on |
|---|---|---|---|
| Issuance redirected to the Innovation Allocation innovation_allocation_pct | 20% % of protocol issuance | current | 2026-08-30 |
| SubgraphService issuance after the redirect subgraph_service_issuance_per_block | 96.584 GRT/block GRT per block | current | 2026-08-30 |
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 effective 2026-08-31. This is a live change, not a proposal. It reduces the issuance reaching indexers and therefore the issuance reaching delegators, by 20% at the source. Any indexing APR quoted from data collected before 2026-08-31 is measuring a larger pie. The forum post gives the effective date as Monday 2026-08-31 in one place and 2026-09-01 in another. Read the Issuance Allocator contract if the exact block matters to you.
SubgraphService issuance after the redirect
The SubgraphService Rewards Manager receives 96.584 GRT per block, a reduction of 24.146 GRT per block from 120.73.
Was 120.73 GRT per block before 2026-08-31. The 24.146 GRT per block difference goes to the Foundation treasury through an existing DirectAllocation contract.
How to fix one
Found a number that has moved?
The registry lives in data/parameters.toml. Change the value, change
the source and the quote, set verified to the date you read it, and
open a pull request. Every lesson using it updates automatically, which is the
whole reason it works this way.