Based on discussions that have been going on in the past few months (see this Forum discussion, and our notes from the R&D retreat in February), we’d like to explore an Arbitrum protocol implementation that works initially as a devnet, with no indexing rewards and therefore useful for experimental subgraphs. This would be a first step towards a full Arbitrum protocol implementation, assuming the devnet is a successful experiment.
This devnet would require, among other things, a way to bridge GRT from L1 into L2 and back. This bridge should be the canonical way to send GRT into Arbitrum, but it should be extensible to support any protocol-specific behavior that may be necessary, both for the initial devnet deployment and the eventual "mainnet” release.
This document will detail the requirements for this bridge in the initial version (the devnet, which we’ll call Stage 1), and preliminary requirements for the eventual mainnet implementation (which we’ll call Stage 2).
We will also describe the proposed interface for this bridge, subject to change as we make progress with the implementation.
The (work in progress) PR implementing this spec is available at:
WIP: Arbitrum bridge implementation by pcarranzav · Pull Request #552 · graphprotocol/contracts
We propose using a custom bridge rather than Arbitrum’s standard ERC20 bridge because:
It’s worth noting that creating custom bridges can be done by reusing Arbitrum’s gateway code; Arbitrum provides a Custom Gateway example contract that is based on their default Gateway implementation, so we can easily override the escrow logic.
Even if we’re implementing a custom bridge, Arbitrum provides a Gateway Router where ERC20 contracts can register the address of the gateway contract to use for bridging. It would be desirable to use this router so that GRT bridging can still play nicely with the Arbitrum community, and for the bridge to be more easily recognizable as the canonical bridge for GRT. This will also allow users to use https://bridge.arbitrum.io/ to bridge GRT.
Sadly, the gateway router requires the L1 token to implement an interface that GRT doesn’t currently have, so the straightforward approach of using L1GatewayRouter.setGateway will not be feasible, as we can’t update the GRT contract. We are discussing with the Arbitrum team to see if there’s a path forward that doesn’t require changes to GRT - it seems we can either use a token wrapper, or ask the Arbitrum team to perform an admin registration for us (which will require the Council to publicly signal that we want this).