GIP-0067: Deprecate the L1 (mainnet) protocol

(See the latest version of this GIP on GitHub)


With GIP-0052, we have moved Indexing Rewards from the L1 (mainnet) deployment of protocol to the L2 (Arbitrum One) instance. Now that this process is complete (at the time of this writing, executing the last step for 100% of rewards to be on L2), we propose deprecating the L1 protocol, with a 6 month timeline to remove the transfer tools and all references to mainnet in the products maintained by core devs.


The community decided on a move to Arbitrum One to allow scaling the protocol in the face of rising gas costs. The current setup with two protocols running in parallel is costly for many protocol participants, confusing for consumers and subgraph developers, and unnecessary now that the L2 protocol has been running in production successfully for over a year.

High-Level Description

Deprecation Timeline

The proposed timeline is as follows, and defined in relation to its first step, that is sending 100% of Indexing Rewards to L2:

  • T = 0 (June 28th, 2024): Indexing Rewards are set to 100% on L2. From this moment on, it is expected that most Indexers will wind down operations on L1. The backstop Indexer from Edge & Node can keep basic query capabilities running for the few remaining L1 subgraphs. The deprecation timeline is publicly announced, with community-wide efforts to inform all participants of the need to move to L2.
  • T = 1 month (July 28th): Support for querying subgraphs on L1 is removed. The backstop Indexer on L1 is stopped. The L1 instances of the Gateway are stopped. All data consumers must start using L2 Gateway endpoints.
  • T = 6 months (December 28th): Support for most transfer tools is removed (see below). The L1 protocol is considered officially deprecated, and L1 contracts are marked End-Of-Life and will get no new upgrades or support. Participants may still withdraw any remaining GRT from the protocol contracts.

Exact dates for removing functionality might vary based on core dev availability to deploy upgrades, but support for the deprecated tools will stop on the dates mentioned above.

Transfer tools deprecation

At the 6 month milestone, the following transfer tools will stop working:

  • Stake transfer
  • Delegation transfer
  • Curation transfer
  • Subgraph transfer

The following ones will keep working:

  • Vesting contract balance transfers to and from L2 will still be supported (note this is for GRT that is not staked or delegated, but held by the vesting contract itself).
  • Adding billing balance from L1 using the BillingConnector will still be supported.

This deprecation will allow removing all the transfer-tools-related code from the Staking and GNS contracts, reducing the complexity of the protocol and with it the attack surface.

The L1 GraphToken contract and the L1-L2 token bridge will of course stay operational with no plans to deprecate them.

Risks and Security Considerations

Moving completely to L2 and deprecating the L1 protocol makes the protocol more reliant on Arbitrum One. With Arbitrum having become the first Stage 1 rollup we believe its reached sufficient maturity to take this step. In a catastrophic scenario where Arbitrum One stops being operational, it should still be possible to use the last known state of the Arbitrum network to deploy a new protocol to another chain (for instance, a custom Arbitrum rollup) and recover participants’ funds. This would take some development effort and Council approval, but we believe is a sufficient mitigation for this low-probability risk.

Copyright Waiver

Copyright and related rights waived via CC0.


Thanks for this @Pablo

Maybe not a question directly about the on-chain changes but very relevant here.

Will deprecation of L1 break the indexer agent for those running in multi-network mode? It would be great if we could clearly communicate the changes a multi-network indexer will need to make in preparation for L1 deprecation.

1 Like

Good question @cryptovestor. Are any indexers still running multi-network with mainnet now that rewards are 100% on L2? In any case, unless we pause them, the L1 protocol contracts will keep working so I don’t anticipate any issues with Indexer Agent in those cases. There just won’t be any gateway making queries.

But my recommendation would be close allocations and to remove all stake, delegation, etc from L1 as those contracts won’t be monitored or maintained any more (and without rewards or queries, I don’t see any reason to use the L1 protocol anymore). Transferring everything to L2 before transfer tools are deprecated would be the best course of action imo.


We’re still running in multi-network mode, but the mainnet side sits idle with 100k stake which we’ll move before deprecation.

I guess my concern was more around the indexer agent software no longer functioning correctly in multi-network mode for an unexpected reason. Just trying to gauge whether we should try and get back to running in single-mode asap to avoid any operational risk. Theres’ a few things to consider in terms of configuration when going back to single mode, from what I recall. Maybe reverting from yaml network configs back to environment variables as an example.

I will try and bring this up on IOH if I can make a session, and clarify with @Ford

1 Like