GIP-0018: Subgraph ownership transfer

The GNS contract allows anyone to publish a subgraph with associated metadata and a target subgraph deployment. The new Subgraph will then be tied forever to the account that created it. The impossibility of transferring the Subgraph ownership makes some use cases very inconvenient, such as moving your control to a multisig or a community member creating it on behalf of a DAO, etc. This proposal intend to solve those issues.


App developers create subgraphs to index blockchain data. Then, they want indexers to run their subgraphs in the decentralized network. To achieve that, they publish a Subgraph in the GNS that targets a Subgraph Deployment. Once they publish a subgraph, they work to attract curators that delegate signal to the Subgraph so that the app developer can properly incentivize indexers.

For many reasons, the app developer might want to transfer ownership of the subgraph to a different account, a valid use case, not possible with the current implementation.


The proposed implementation involves a number of changes to make it easier to manage a subgraph. In addition to that, it simplifies many of the contract interfaces.

Subgraph Primary Key

The current primary key that defines a subgraph is a combination of graphAccount and subgraphNumber that gets passed to every function used to interact with the GNS.

To make it easier to store and reference, we will change that for a single subgraphID. A subgraphID will be determined at the moment of publication, and calculated like KECCAK(creatorAccount, seqID).

  • creatorAccount is the msg.sender that calls publishNewSubgraph

  • seqID is a sequential ID that gets incremented for that creator to avoid collisions

NFT-based Ownership

Whenever an app developer publishes a new subgraph, the GNS will mint an NFT. Whoever owns the NFT controls the subgraph. The NFT is based on a standard ERC721, so it can be easily transferred to different accounts.

All access control for the following functions will be NFT-owner based:

  • updateSubgraphMetadata()

  • publishNewVersion()

  • deprecateSubgraph()

Interface Simplification

All functions and events where graphAccount and subgraphNumber were passed will be changed for just a single subgraphID. This is a breaking change for clients that will need to adapt to the new interface. The fact that the new subgraphID is the keccak(graphAccount, subgraphNumber) makes it easier to translate old IDs into new ones.

Remove Unused Functionality

The GNS included a feature to transfer the account identity that is not currently used and should be removed. For that it used the EthereumDIDRegistry contract.

Migration Facilities

The new implementation will expose a function that owners of old-type subgraphs can call to mint their NFTs. This function must ensure that it is only called once per old-type subgraph.

Additionally, the contract will keep track a mapping of subgraphID => (graphAccount, subgraphNumber) for old subgraphs to make them backward compatible.

Operational Considerations

Performing this upgrade involves:

  • Migration of old subgraph types and minting of NFTs by calling a function exposed by the contract.

  • Any frontend that integrates GNS functionality needs to start using the single subgraphID.

  • Update the Core Network Subgraph to read the new events emitted by the contract.


See @graphprotocol/contracts#497

Backwards Compatibility

The proposal has a number of breaking changes.

Function Interfaces

Functions that change from taking (graphAccount,subgraphNumber) to subgraphID:

- updateSubgraphMetadata

- publishNewSubgraph

- deprecateSubgraph

- mintNSignal -> mintSignal

- burnNSignal -> burnSignal

- withdraw

- tokensToNSignal

- nSignalToTokens

- vSignalToNSignal

- nSignalToVSignal

- getCuratorNSignal -> getCuratorSignal

- isPublished


Updated Events

  • SubgraphMetadataUpdated

  • SubgraphDeprecated

  • GRTWithdrawn

Deprecated Events

  • SubgraphPublished

  • NameSignalEnabled

  • NSignalMinted

  • NSignalBurned

  • NameSignalUpgrade

  • NameSignalDisabled

New Events

  • SubgraphCreated

  • SubgraphUpgraded

  • SubgraphVersionUpdated

  • LegacySubgraphClaimed

  • SignalMinted

  • SignalBurned



The implementation has not yet been audited.


The implementation has not yet been deployed to Testnet.


This one is super important.

If you have the network to amplify this proposal to subgraph developers to get input, please do so!


Really happy to see the simplification of the GNS abstraction. The new interface & events feel much cleaner than before :tada:


I support this proposal!


This is crucial, and would significantly increase subgraph quality by enabling skilled independent developers to build bespoke subgraphs. This would allow project developers to further compress their timeline by outsourcing this element to those who have experience with the nuances of The Graph protocol.


we have been waiting for “NFT-based Ownership” for a while. thank you!

1 Like

Hey, I posted a new GIP that supersedes this one GIP-0023: Subgraph ownership transfer using external NFT contract

The new GIP describes a refactored implementation I had to do to get the ERC-721 properly indexed by NFT marketplaces and wallets that depend on them. I’m happy with the refactor, the architecture makes more sense, less bloated GNS code and is not changing the core behaviour of the GNS like GIP-0018.


Could NFT Based ownership mean subgraph ownership can be auctioned and sold?! Very cool! I support this proposal.