GIP-0019: Save gas when initializing a subgraph deployment

A subgraph-specific ERC20 token represents the signal on a subgraph deployment. When a curator mints signal for the first time, the Curation contract, among other things, deploys a new ERC20 token as part of the initialization process. This process is quite costly at about 1.2M gas. This proposal describes an update to make this protocol action much more efficient.


Reduce the gas cost for anyone initializing a subgraph deployment. This update is particularly beneficial for subgraph/app developers who do the first signal.


Use a Minimal Proxy to clone the Graph Curation Token (ERC20) based on an implementation contract deployed just once. The implementation bytecode is also called master copy.

The benefit of this solution is that the token interface remain the same, making it backwards compatible.

This solution involves the following changes:

  • Modify the initializer of Curation to accept the master copy contract address to use when cloning.

  • Expose a function in Curation contract so that governance can change the implementation in the future.

  • Leverage “@openzeppelin/contracts/proxy/Clones.sol” to spawn the Minimal Proxies.

  • Update the current Graph Curation Token contract code and make it upgradeable so it can be used from the context of a Minimal Proxy.

Additional improvements:

  • Avoid re-deployment of the subgraph ERC20 token when all the signal is burned back to zero.

Important notes:

  • Previously created ERC20 tokens for subgraph deployments will not be changed.

  • The implementation used as template for already deployed clones cannot be changed, it can only change for future ones.

Based on gas consumption reports, using a Minimal Proxy reduces the gas used on first mint from ~1,230,000 gas to ~432,000

Operational Considerations

Performing this upgrade involves:

  • Deploying the Graph Curation Token master copy and getting the address before doing the upgrade.

  • When doing the upgrade of Curation contract we need to pass the master copy address to use as implementation for every clone.


See @graphprotocol/contracts#505

Backwards Compatibility

The proposal is fully backward compatible.



The implementation has not yet been audited.


The implementation has not yet been deployed to Testnet.


Great to see these optimisations being rolled out! Thanks @ariel!


Having covered the gas fees for being the first to signal, I am strongly in favor based on how I understand this.

Just to clarify, if a developer were to publish, but not signal to their deployment this would not effect the total gas cost for publishing. Primarily focused on the initial signal (or a deploy & signal batch), correct?


Exactly, this only applies when you signal for the first time, if the developer just published they only pay for the publish transaction.

This also improves the cases of any upgrade, you call publishNewVersion and the signal is moved to the new deployment where everything is initialized again.

1 Like

Fantastic. I expect this to have pretty wide support from curators. I know I’m in favor.