Update indexing FAQ and delegating guide for Graph Horizon

website/src/pages/en/indexing/overview.mdx

@@ -3,6 +3,8 @@ title: Indexing Overview
 sidebarTitle: Overview
 ---
 
+> **Graph Horizon is live.** The protocol upgrade changes how allocations, rewards, and delegation work. See the dedicated [Graph Horizon section](/graph-horizon/overview/) for a full overview of what changed, and the [migration guide](/graph-horizon/migration-guide/) for indexer setup instructions.
+
 Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.
 
 GRT that is staked in the protocol is subject to a thawing period and can be slashed if Indexers are malicious and serve incorrect data to applications or if they index incorrectly. Indexers also earn rewards for delegated stake from Delegators, to contribute to the network.
@@ -23,17 +25,29 @@ The minimum stake for an Indexer is currently set to 100K GRT.
 
 ### How are indexing rewards distributed?
 
-Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across Subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that Subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+Indexing rewards are collected by Indexers through periodic Proof of Indexing (POI) submissions while allocations remain open. Under Graph Horizon, allocations can remain open indefinitely — there is no requirement to close an allocation to collect rewards.
+
+Indexers must submit a valid POI before it becomes stale. The `maxPOIStaleness` parameter is currently set to **28 days** — if no POI is submitted within this window, any network participant can force-close the allocation. There is no retroactive recovery of rewards.
+
+Rewards are distributed proportionally based on curation signal and the amount of GRT allocated to each subgraph deployment.
+
+> **Note:** During the current transition period, the indexer-agent continues to recycle allocations approximately every 28 days for compatibility. A future agent version will leverage long-lived allocations natively. Check the [Graph Horizon migration guide](/graph-horizon/migration-guide/) for current agent requirements.
 
 Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
 
 ### What is a proof of indexing (POI)?
 
-POIs are used in the network to verify that an Indexer is indexing the Subgraphs they have allocated on. A POI for the first block of the current epoch must be submitted when closing an allocation for that allocation to be eligible for indexing rewards. A POI for a block is a digest for all entity store transactions for a specific Subgraph deployment up to and including that block.
+A Proof of Indexing (POI) is a cryptographic proof that an Indexer has correctly indexed a subgraph deployment up to a given block. A POI for a block is a digest of all entity store transactions for a specific Subgraph deployment up to and including that block.
+
+Under Graph Horizon, POIs are submitted periodically to collect accrued indexing rewards. Indexers do not need to close an allocation to submit a POI. However, if a POI becomes stale (exceeds `maxPOIStaleness`, currently **28 days**), the allocation can be force-closed by any network participant, resulting in loss of uncollected rewards with no ability to reclaim them retroactively.
+
+POIs are generated by the indexer-agent and verified on-chain by the SubgraphService contract.
 
 ### When are indexing rewards distributed?
 
-Allocations are continuously accruing rewards while they're active and allocated within 28 epochs. Rewards are collected by the Indexers, and distributed whenever their allocations are closed. That happens either manually, whenever the Indexer wants to force close them, or after 28 epochs a Delegator can close the allocation for the Indexer, but this results in no rewards. 28 epochs is the max allocation lifetime (right now, one epoch lasts for ~24h).
+Under Graph Horizon, there is no maximum allocation lifetime. Allocations remain open until explicitly closed by the indexer, or force-closed due to POI staleness. Rewards accrue continuously and are collectible via periodic POI submission.
+
+The previous mechanism allowing Delegators to force-close allocations after 28 epochs was removed by Horizon. However, any network participant can now force-close an allocation if its POI becomes stale (no submission within 28 days).
 
 ### Can pending indexing rewards be monitored?
 
@@ -75,6 +89,8 @@ Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
 - If the dispute is settled as a draw, the Fishermen's deposit will be returned, and the disputed Indexer will not be slashed.
 - If the dispute is accepted, the GRT deposited by the Fishermen will be returned, the disputed Indexer will be slashed and the Fishermen will earn 50% of the slashed GRT.
 
+> **Graph Horizon update:** Slashing parameters are now flexible, with a maximum cap of 10% (the recommended default is 2.5%). Fishermen who raise valid disputes can reclaim their bond if the dispute is not resolved within the required timeframe.
+
 Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
 
 ### What are query fee rebates and when are they distributed?
@@ -91,6 +107,8 @@ The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that
 
 - **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
 
+> **Graph Horizon update:** Under Horizon, `indexingRewardCut` and `queryFeeCut` parameters are set by the indexer per data service (e.g., SubgraphService), rather than globally in the staking contract. The concept is the same — indexers share a portion of rewards with delegators — but the configuration is now per-service. See [What changes with Graph Horizon?](/graph-horizon/what-changes/) for details.
+
 ### How do Indexers know which Subgraphs to index?
 
 Indexers may differentiate themselves by applying advanced techniques for making Subgraph indexing decisions but to give a general idea we'll discuss several key metrics used to evaluate Subgraphs in the network:
@@ -725,10 +743,38 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 ### The life of an allocation
 
-After being created by an Indexer a healthy allocation goes through two states.
+Under Graph Horizon, allocations follow a new lifecycle managed by the SubgraphService:
+
+**1. Open**
+
+An indexer opens an allocation by staking GRT against a subgraph deployment via a provision to the SubgraphService. The allocation is now active and the indexer begins accruing indexing rewards proportional to their allocated stake and the subgraph's curation signal.
+
+**2. Active (ongoing POI collection)**
+
+The indexer submits Proofs of Indexing (POIs) periodically to collect accrued rewards. The allocation remains open — there is no time limit. Submitting a POI does not close the allocation.
+
+If a POI becomes stale (exceeds `maxPOIStaleness`, currently **28 days**), any network participant can force-close the allocation. There is no retroactive recovery of uncollected rewards.
+
+**3. Close (optional)**
+
+An indexer may close an allocation at any time. Closing is optional and is not required to collect rewards.
+
+---
+
+> **Transition period note:** The current indexer-agent (`indexer-agent` v0.x) continues to cycle allocations approximately every 28 days during the transition to Horizon. This is a compatibility behavior, not a protocol requirement. Future agent versions will support long-lived allocations natively.
+
+Indexers are recommended to utilize offchain syncing functionality to sync Subgraph deployments to chainhead before creating the allocation onchain.
+
+### Provisions and Data Services
+
+Graph Horizon introduces a modular architecture where indexers explicitly assign ("provision") staked GRT to specific data services before it can be used for indexing.
+
+**SubgraphService** is the first and currently primary data service. To index subgraphs and earn rewards, an indexer must:
 
-- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a Subgraph deployment, which allows them to claim indexing rewards and serve queries for that Subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+1. Stake GRT in the core staking contract
+2. Create a provision assigning that stake to the SubgraphService
+3. Open allocations against subgraph deployments via the SubgraphService
 
-- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+Stake that has not been provisioned to a data service cannot be used for indexing or earn rewards.
 
-Indexers are recommended to utilize offchain syncing functionality to sync Subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for Subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.
+See the [Graph Horizon migration guide](/graph-horizon/migration-guide/) for step-by-step provisioning instructions.

website/src/pages/en/resources/roles/delegating/delegating.mdx

@@ -43,6 +43,23 @@ This makes it crucial for Delegators to evaluate an Indexer's current Delegation
 
 Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
 
+## Delegating under Graph Horizon
+
+Graph Horizon introduces per-data-service delegation. When delegating, you choose:
+
+- **An Indexer** — the operator you are delegating to
+- **A data service** — currently SubgraphService (the primary data service for subgraph indexing)
+
+Your delegation earns rewards based on the indexer's activity on the specific data service you delegated to.
+
+**Existing delegations:** If you delegated GRT before Graph Horizon launched, your delegation was automatically migrated to SubgraphService. No action was required.
+
+**Multiple undelegations:** Horizon supports up to 1,000 simultaneous undelegation requests, removing the previous restriction to a single active undelegation at a time.
+
+### Future Slashability
+
+Horizon introduces the technical capability for delegated stake to be slashed in the future. This capability is not currently enabled for SubgraphService, but delegators should be aware it may be activated in future protocol upgrades. Monitor governance proposals for any changes to slashing parameters.
+
 ## Delegation on The Graph
 
 <VideoEmbed title="How to Acquire GRT" youtube="HVyIrMcNu7I" />
@@ -58,15 +75,11 @@ There are two sections in this guide:
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The Delegation Tax
-
-Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
-
-As a Delegator, it's important to understand the following:
+### No Delegation Tax
 
-- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+Under Graph Horizon, there is no delegation tax — the parameter has been removed from the protocol entirely. You can delegate and undelegate without incurring any protocol-level fee on your principal.
 
-- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+> **Note:** The 0.5% delegation tax that existed prior to Graph Horizon has been permanently removed.
 
 ### The Undelegation Period
 
@@ -82,7 +95,7 @@ If you choose an Indexer that is not trustworthy or not doing a good job, you wi
 
 As a result, it’s recommended that you choose an Indexer wisely.
 
-![Delegation unbonding. Note the 0.5% fee in the Delegation UI, as well as the 28 day unbonding period.](/img/Delegation-Unbonding.png)
+![Delegation unbonding. Note the 28 day unbonding period.](/img/Delegation-Unbonding.png)
 
 #### Delegation Parameters