The Graph Network: Subgraph Migration Is in Full Swing

The pace of Ethereum subgraph migrations to the decentralized network is picking up fast, up 30% quarter-over-quarter, as more dapp developers champion decentralized web3 infrastructure. Here are some answers to common migration questions, alongside what’s next as the network prepares to onboard a new wave of subgraphs.


The Graph’s decentralized network has blossomed into a flourishing data economy since its launch in December 2020. This permissionless and open-source blockchain data ecosystem is now home to 160 Indexers, 2500+ Curators, 8,600+ Delegators, and 282 subgraphs (with more migrating each week). Building a robust, decentralized network requires measured and methodical improvements.

Since launching Subgraph Studio and enabling permissionless migrations, the network has seen over 282 subgraphs transition from the hosted service to the decentralized network. These early migration participants span most verticals in the blockchain space such as DeFi, music, art, analytics, wallets, NFTs, video streaming services, social media, metaverse, and much more. All things considered, this is still just the tip of the iceberg.

The network is ready to scale thanks to its superior uptime compared to the hosted service, while boasting performance metrics as good – if not better than – the hosted service. The most important goal within the ecosystem is to migrate all Ethereum mainnet subgraphs from the hosted service to the decentralized network. This is imperative for web3 dapps to fulfill their missions of building on decentralized infrastructure. The Graph community encourages you to migrate your Ethereum subgraphs and experience the network for yourself, as well as allow the world to call your application truly decentralized. Note that subgraphs with full text search and IPFS dependencies are not ready to migrate just yet - that functionality will come soon. Five core developer teams and many more contributors are continuing to push progress forward to improve subgraph features, indexing performance, and network economics to support all dapp needs.

Why migrate now? Apply for a Migration Grant!

The Graph Foundation and the core devs contributing to The Graph recognize the minor points of friction that exist throughout this process and have a number of programs underway to make the process as seamless and effortless as possible. These include:

Questions and feedback come up often about the network, which are always appreciated. Below we have answers and give clarity to some of the most common questions posed by the community. If you ever have feedback, either contact the core dev teams directly in Discord or send your questions to: [email protected].


I thought that publishing our subgraph to the decentralized network would be difficult, but we went from the hosted service to the decentralized network in just under half an hour. The transition was pretty seamless - one Indexer started indexing our subgraph immediately, four more joined within the day. It’s a good feeling to be able to credibly say that our dapp isn’t dependent on a centralized API like it used to be. As an added bonus, we haven’t seen any degradation to the speed or uptime of our subgraph. Quite the opposite in fact… the independent Indexers serving our subgraph have been a few milliseconds faster and a few points more reliable thus far. From personal experience, I would definitely recommend publishing to the decentralized network as soon as your subgraph is ready to be queried in production.
JordanEmblem

Is it difficult to migrate?

Migrating to the decentralized network can take as little as 30 minutes, and takes just 4 steps!

  1. Deploy the subgraph to the subgraph studio
  2. Create an API key in the studio and fill it with GRT (on Polygon)
  3. Publish the subgraph and signal (curate) with GRT on the network to attract Indexers (10K GRT curation signal is recommended to ensure the best Indexer experience.)
  4. Migrate API endpoints from the hosted service to the decentralized network as soon as the indexers on the network have successfully indexed the subgraph.

AT ETHDenver 2022, Opyn, Hop Protocol, Emblem and POAP published their subgraphs to the decentralized network in person.

Gas Costs

What are some costs associated with migrating?

Based on numbers from February 1st to March 3rd:

  • Publishing a new subgraph : median of 0.044 ETH (~124.64 USD)
  • Upgrading a subgraph: median of 0.016 ETH (~47.9 USD)
  • Updating metadata of subgraph: median of 0.00258 ETH (~7.44 USD)

Query Fees

Why is there sometimes little to no fee volume on the Network Explorer?

Query fees on The Graph Network are paid weekly on Polygon. Dapps (or any other type of subgraph users) load up their account with GRT and payments are accrued when each query to their dapp is made. Billing cycles for subgraph users are weekly as well. However, both the initial deposit by the dapp and the point at which an Indexer collects the fees they have accrued on Polygon involve an on-chain transaction on Ethereum to be visible in The Graph Network Contracts and the network subgraph.

With Ethereum gas fees soaring over the past year, gas costs have had a significant impact on how often Indexers close allocations to collect their fees. Indexers have chosen to close their allocations more sporadically, when gas prices are low, rather than on a regular basis. A couple of months ago, a change was introduced to the Indexer Agent which optimized Indexer costs by reducing how often they close allocations which resulted in a decrease of observable query fees on the network. Here is the dashboard where you can keep track of fees over time to observe where spikes on the Network’s fees take place. It’s important to note that fee volume only shows up in the Explorer when Indexers close allocations. When gas costs are high, this disincentivizes Indexers from collecting fees.

When will there be a Layer 2 implementation for all transactions on The Graph Network?

In the future network activities are planned to move to Layer 2 (L2) to decrease transaction costs and increase profitability for ecosystem participants. The core devs are currently researching and assessing the best L2 solutions for the network’s needs. A proposal to the community and Council will go out once ecosystem stakeholders come to agreement on a path forward. The core devs recognize the urgency around enabling scalability in The Graph ecosystem.

Curation

How does the curation bonding curve work?

In the curation bonding curve, the earlier a wallet signals (curates), the more curation bonding curve exposure they receive and therefore the more they participate in the curation query fee share. This bonding curve dynamic places those who publish subgraphs or those who manage to curate a subgraph first at a financial advantage as they amass a larger share of the curation exposure. There is currently not a great mechanism to allow early curators to take the time it would take to evaluate a subgraph for technical merit before racing to signal. Front running has also posed a problem for subgraph developers. So that subgraph publishers are not front-run, they now have the option to publish and curate simultaneously. All subgraph developers are encouraged to signal with their initial publishing to ensure that they are first on the bonding curve. Until changes are introduced to the curation mechanism, we should assume that the main curators on a subgraph are the subgraph publisher.

The value of curation shares fluctuates depending on when a user joined the bonding curve. A proposal to revise this model has been raised within the community. This proposal, if approved and implemented, would mean that initial GRT signal will not change and the bonding curve will only apply to curation rewards. With the implementation of this GIP, the updated system will solve the issues that Curators have been facing, improving their ability to monetize their talents.

Here is a more in-depth explanation of curation and the bonding curve currently.

Migrate now for a truly decentralized app

Using The Graph Network adds a layer of robustness, security, and reliability to your Ethereum application. Each additional day relying on centralized infrastructure poses a risk to your application’s uptime and user experience. Migrate your subgraph and be a part of the wave of leaders committed to shaping a radically better internet.

The assistance program to help migrate your Ethereum subgraph won’t last forever, so it’s highly recommended to migrate your Ethereum subgraphs before the grant is depleted. Please reach out to understand how Edge & Node can help you with migration.

If you continue to have migration questions that have not yet been answered by this blog, please submit your feedback via this form in order to receive assistance.


Category
Graph Updates
Published
March 8, 2022

The Graph Foundation

View all blog posts