GIP-0038: Epoch Block Oracle

Hello! Updating here on the basis of some ongoing conversations - I have updated the above GIP. Pulling out the most salient change, which is a proposal for the related governance process. Comments & considerations are very welcome.

Governance process for adding new chains

Adding a chain to the block oracle is an economically meaningful action for the protocol, if it is to enable indexing rewards. There should therefore be a ratification process for the addition of new networks.

This GIP proposes that The Graph Council should approve addition of new chains via an on-chain vote.

When assessing whether a given chain should be added, The Graph Council should require confirmation (from core developers, or otherwise) that an integration with Graph Node exists which allows for deterministic indexing of the chain. The Graph Council may also consider the chain itself and its ecosystem (for decentralisation, client availability, stability).

To reiterate: a chain being eligible for indexing rewards is an indication that subgraphs indexing a given chain can be verified as part of The Graph Protocol. It is not a statement on indexer readiness to support subgraphs on that chain.

Once a network has been approved:

  • The chain should be added to networks.md, including any relevant aliases to be used in subgraph manifests.
  • The Epoch Block Oracle & subgraph should be upgraded to support fetching blocks for that chain, for each epoch, including aliases. This may be a simple configuration change.

Once included in the Epoch Block subgraph, the Subgraph Oracle should then allow indexing rewards for all subgraphs indexing the newly supported network. This technical & economic support should then catalyse activity on the network, supported by ecosystem members and core developers.

4 Likes