Thegraph
Thegraph delegation rewards depend on Indexer cuts, pool shares, and usable capacity
Thegraph lets GRT holders delegate to Indexers and receive a share of their rewards. Comparing Indexers requires understanding which reward share each retains and how much delegation their stake can support. A lower cut doesn't establish a higher return when capacity or indexing activity limits the reward pool.
Lower cuts and spare capacity can favor different Indexers
An Indexer that retains a smaller reward share leaves more of that reward stream for its delegation pool, while an Indexer with more usable capacity can put additional delegated stake to work within the relevant service. These advantages don't necessarily belong to the same operator. Comparing them requires looking at the reward stream, the pool's size, and the stake available for the relevant service. The indexing reward cut concerns rewards from protocol issuance. The query fee cut concerns the separate stream from paid queries, so one percentage can't describe both.
An Indexer-retained cut and a delegation-pool share describe opposite sides of the split. Horizon's payment contract applies its delegation cut to the pool's share of the remaining payment. Read the named recipient before interpreting a percentage.
Under Graph Horizon, delegation identifies both an Indexer and a data service. SubgraphService handles the subgraph indexing use case, and the standard delegation interface supports that service. Horizon's architecture permits other data services; that doesn't establish their availability through the same interface. Each comparison therefore needs matching service context. An operator's unrelated activity elsewhere doesn't establish earnings for the pool receiving the delegation.
When does additional delegation dilute rewards?
Additional delegation dilutes rewards when it enlarges a pool without a corresponding increase in the rewards that the pool can earn through usable stake.
Capacity limits how much delegated GRT can contribute to a service's available stake. Under Horizon, the calculation uses the Indexer's available stake provisioned to that service and the applicable delegation ratio. Stake that the operator holds elsewhere doesn't automatically back this pool. Thawing also changes the available amounts. Delegated GRT above the service's usable capacity cannot increase its available stake. Excess delegation can still participate in the pool's reward distribution, spreading earnings across a larger delegation base.
Overdelegation doesn't itself mean that the contract rejected the deposit.
The comparison needs available headroom, rather than the pool's maximum capacity alone. Headroom describes the space remaining after existing active delegation. Another deposit, a reward distribution, or a change in provisioned stake can alter it. Raw token totals may include amounts that are thawing, so they don't necessarily describe active reward-earning delegation. A pool that fits a proposed amount now can later become overdelegated.
Pool shares determine each delegation's reward portion
A delegation receives pool shares that represent its interest in the active delegation pool. Reward payments increase the GRT backing those existing shares. Share counts and token amounts therefore measure different things. An existing pool issues new shares using its active token balance and total shares. It doesn't necessarily issue one share for each GRT deposited. Comparing token balances without their share conversion can misstate how much of the pool a delegation owns.
The reward fraction follows the delegation's shares divided by total active pool shares. Equal participation means proportional shares, not equal payments per wallet.
For a given distribution, the delegation's attributable reward equals the GRT added to the active pool multiplied by that fraction. This calculation starts after the relevant reward-sharing split. It can't treat all Indexer earnings as delegate earnings. Horizon's payment accounting also distinguishes protocol and data-service deductions from the amount that reaches the pool. The indexing reward stream and query fee stream can contribute different amounts under different sharing terms. A single retained-cut percentage doesn't establish a wallet's combined reward.
An effective reward cut expresses the operator's retained portion relative to rewards attributed to delegated stake. It differs from the raw cut on total rewards, which also reflect the operator's own stake. Pool size and the balance between owned and delegated stake therefore change the meaning of the displayed comparison. A reward credit can increase the token value of existing shares without minting additional shares to each delegate. That increase belongs to the delegation position; it doesn't establish a payment into the wallet.
A delegation comparison with tokens still thawing
Consider a hypothetical comparison in which every amount, capacity reading, and relative cut is an illustrative input. A GRT holder plans to delegate 735 GRT to one of two Indexers on the same data service. That GRT is still thawing from an earlier delegation, so it isn't available for a new deposit.
The first Indexer retains a smaller reward share and has 615 GRT of usable delegation headroom. The second retains a larger reward share and has 1170 GRT of headroom. The holder checks whether the full proposed delegation fits within productive capacity. For the first pool, 735 minus 615 leaves 120 GRT beyond headroom. For the second, 1170 minus 735 leaves 435 GRT of headroom.
The holder waits for the existing request to finish thawing and completes a withdrawal. Assuming the wallet receives the full 735 GRT, the second pool fits the proposed amount under these unchanged inputs. The first pool doesn't fit the full amount, so the holder rules it out for this deposit. A different delegation amount or changed headroom would require a fresh calculation. Neither retained cut supplies a forecast of future earnings. The new deposit also requires sufficient token allowance and separately funded network fees.
With those requirements satisfied, the holder delegates the available GRT to the second pool. A successful on-chain delegation records the selected Indexer, data service, deposited tokens, and issued shares. Those shares confirm the position; an approval or submitted transaction alone doesn't. After the deposit, the second pool has 435 GRT of headroom, assuming no intervening change in the pool.
How does indexing activity change a delegation estimate?
Indexing activity changes delegation estimates because the operator's allocations and collected rewards determine how much GRT reaches the pool. Allocations assign available stake to subgraphs. Their curation signal and allocated stake affect indexing rewards. Horizon permits reward collection through periodic Proof of Indexing submissions without requiring allocation closure. Stale proofs can cause lost rewards, so collection history matters alongside allocation size. A historical annualized estimate extrapolates earlier earnings; changes in activity, sharing terms, or active pool size can change future rewards. Cumulative lifetime earnings alone don't describe the earning pace of a new delegation.
Exit timing changes the cost of switching Indexers
Moving delegated GRT requires allowing the selected amount to thaw, which creates an interval when that amount no longer earns delegation rewards, while the active delegation's remaining shares continue to represent its remaining interest. Horizon attaches thawing duration to the service provision, and the resulting request records its withdrawal eligibility time. That request's state controls when the amount becomes available. A broad statement about waiting periods can't replace the timing attached to a particular request.
Withdrawal then releases eligible tokens. Horizon also supports redelegating thawed tokens directly into another existing provision. This contract capability doesn't imply that every interface exposes the same route. Neither withdrawal nor redelegation skips the thawing requirement. The selected amount loses earning time during thawing, while network transaction fees remain separate from the reward-sharing cut.
Graph Horizon removed the protocol's delegation tax.
That change doesn't remove network fees or compensate for missed rewards during thawing. Changes in the operator's retained share can also alter the reason for remaining delegated. For an existing request, the relevant figure is its thawingUntil timestamp.
What readers ask about Thegraph
-
Does GRT delegation require operating an indexing node?
- GRT delegation doesn't require operating an indexing node. The Indexer runs the infrastructure that indexes subgraphs and serves queries. The delegator supplies GRT to the selected service's delegation pool and participates through pool shares. Infrastructure operation remains the Indexer's responsibility, so its ability to perform the work affects the rewards available to that delegation.
-
Can a wallet delegate GRT to more than one Indexer?
- A wallet can delegate GRT to multiple Indexers. Each delegation has its own pool shares and reward-sharing terms within the relevant data service. Capacity available with one operator doesn't increase capacity with another. Separating positions changes exposure to each operator's activity, although all positions still involve GRT and the protocol's applicable withdrawal rules.
-
Why does approving GRT leave my delegation balance unchanged?
- Approving GRT authorizes the staking contract to transfer tokens; it doesn't create a delegation. A successful delegation must also deposit tokens and record pool shares for the selected Indexer and service. An existing allowance may already cover the intended amount, so a fresh approval isn't universally necessary. The allowance and delegation position describe separate permissions and balances.
-
What happened to delegations created before Graph Horizon?
- Existing delegations migrated automatically to SubgraphService for their original Indexer when Graph Horizon launched. The migration didn't require holders to undelegate and redelegate their GRT. That continuity didn't perform the operator's infrastructure upgrade: the Indexer still needed compatible software for Horizon operations. Migration of a delegation and readiness of its operator are separate conditions.
-
Is delegated GRT subject to slashing under Graph Horizon?
- Delegation slashing isn't enabled for SubgraphService under Horizon's present configuration. The architecture includes the capability to enable delegation slashing through a future governance change. If enabled, the mechanism consumes the relevant Indexer's provisioned stake before touching delegation funds. That ordering provides a buffer; it doesn't promise a permanent exemption under every future configuration.