Network Transition FAQ
Developers will have plenty of time to migrate their subgraphs to the decentralized network. Exact timelines will vary from chain to chain based on Indexer and network readiness-the hosted service will not end support for all chains at once and will not be sunset abruptly.
Each chain on the hosted service, including Ethereum, will sunset gradually as it is supported on the decentralized network to achieve feature parity and a high quality of service. This will happen on a chain-to-chain basis with help from Indexers in the MIPs program, to enable full support for each chain on the decentralized network.
To add more clarity around continued support for each chain on the hosted service, these FAQs answer common questions regarding the specifics of the network transition process. If you would like to start the subgraph migration process now, here is a step-by-step guide. To skip to the migration FAQ, click here.
Will I have to migrate my subgraph before the decentralized network serves core functionalities for subgraphs?
Subgraph developers can begin migrating their Ethereum mainnet subgraphs now, but will not be forced to migrate subgraphs to the network before feature core functionality exists for the decentralized network and hosted service. Migration of Gnosis Chain subgraphs will also begin soon, with other chains to follow once Indexers have tested the chains and are ready to index them in production.
All chains will have their own timelines, depending on when they are enabled on the network and the timeline it takes to get through each phase. Core developers are working to migrate the majority of hosted service traffic to the decentralized network as soon as possible.
Most importantly, you will not lose access to the hosted service before core functionality is available for your specific chain/subgraph on the decentralized network.
The three distinct phases of hosted service deprecation for each chain are:
Phase 1 (The Sunray): Disable new subgraph creation for blockchains that have quality parity on the network
In this stage, developers will no longer be able to deploy new subgraphs to the hosted service for that chain. Developers will still be able to upgrade existing subgraphs on the hosted service.
No chain has yet begun Phase 1 of transitioning from the hosted service to the decentralized network.
As chains enter Phase 1, please note that developers can still use the rate limited Developer Preview URL in the Subgraph Studio to develop and test their subgraphs (up to 1,000 free queries) without acquiring GRT or interacting with protocol economics.
In this phase, upgrades to subgraphs must be made through Subgraph Studio and subsequently published to the decentralized network. Hosted service subgraphs for chains in this phase will still exist and will be queryable, but upgrades to subgraphs must be made on The Graph's decentralized network.
There are no exact timelines for when any chain will move to this phase, as the process is driven by exit criteria surrounding core functionality, not dates.
At this phase, subgraphs on the hosted service for chains supported by The Graph Network will no longer process queries. The only way to query blockchain data for subgraphs on chains in this phase will be through the decentralized network. Test queries will still be available in Subgraph Studio via the Development Query URL.
Chains will not move to Phase 3 until successfully moving to Phase 2 and giving developers ample time to migrate to the decentralized network.
Note: This diagram reflects the per-chain sunsetting process. Hosted service sunsetting times will vary and will not sunset all at once.
All chains and test-chains are eligible for a free Deployment Query URL in the Subgraph Studio. This URL is rate limited and intended for test and development traffic. Production traffic will require a subgraph published to The Graph Network in order to have production grade redundancy and stability.
Indexers on The Graph Network run the most recent network-approved release of Graph Node, and can support any subgraph features supported in that release.
Sometimes unreleased features which are still under development might be available first on the Developer Preview URL, which runs the latest main commit of Graph Node. These features will then become available on the network with the next Graph Node release.
Certain subgraph features are not eligible for indexing rewards, if they are not deterministic or verifiable on the network. Specific examples are fetching files from IPFS, and indexing networks not yet supported on The Graph Network.
Subgraphs with these features can be published to the network, but they may not be picked up by Indexers. However, subgraphs with sufficient signal may still attract Indexers interested in collecting query fees, which any subgraph is eligible for.
The Graph's decentralized network is 60-90% less expensive than running dedicated infrastructure, as shown in these case studies.
Hiding your hosted service subgraph is strongly recommended to avoid confusion. This video walks through the process.
There is no set timeline per chain, they will be dictated by Indexer readiness via the MIPs program where new chains are tested by Indexers. As new chains are supported on the network, users will receive ample notification to prepare for migration. Core devs and contributors to The Graph ecosystem are working to implement support for more chains as soon as possible.
While Ethereum was initially anticipated to begin transition off of the hosted service by the end of Q3 2022, this has been postponed to address user feedback. Additional improvements to user experience, billing, and other fulfillments of user requests will drive Ethereum's hosted service transition timeline. Stay up to date on when Ethereum will enter The Sunray phase via the integration status tracker below and via The Graph Twitter.
The table below illustrates where each chain is in the network integration process. If your preferred chain is not yet listed, integration has not yet begun, and that chain is still fully supported by The Graph's hosted service.
|Chain / Network||Announcing integration on The Graph Network||Network Integration complete||Phase 1: disable new subgraphs on hosted service||Phase 2: disable subgraph upgrades on hosted service||Phase 3: disable subgraphs on hosted service|
|Gnosis (formerly xDAI)||✓|
*This table will not include test chains, which remain free in Subgraph Studio.
Query fee prices are impacted by query demand on the decentralized network. Core developers created a query pricing cost model language called Agora. It enables Indexers to price queries efficiently. Learn more in the Agora documentation.
Please note that setting your max query budget too low will exclude Indexers, potentially leading to poor quality service in the form of failed queries, slow queries, etc.
As of the end of September 2022, it's best practice to stay within the $0.00035-$0.0004 range as the lowest max query budget.
Users are encouraged to restrict the API key by both subgraph and domain in the Subgraph Studio:
You can fill up your billing balance in the Subgraph Studio Billing Dashboard by pressing the "Add GRT" button. There is ongoing work to improve this experience to add more seamless and recurring payments.
This video has an overview of that process.
Users should set a billing alert to their email address here.
Also, a banner will flash within a user's UI to warn when a billing balance is getting low.
What are the best practices for managing my API key settings?
A max query budget of $0.0004 is recommended to maintain low average query prices while maintaining high quality of service. This can be done in the budget billing tab of the API Key section.
Yes. To apply for a grant, reach out here.
Is there any financial/technical/marketing support through the migration process from The Graph ecosystem?
There are migration grants for projects to use to curate subgraphs (to attract Indexers) and pay for initial query fees (apply here), a direct channel to engineers to help every step of the way, and prioritized marketing campaigns to showcase your project after migration, exampled in these Twitter threads: 1, 2, & 3.
Queries take an average of 150-300 milliseconds on the decentralized network.
Yes, the UX for the network is not yet at quality parity with the hosted service. The billing UX, in particular, is still in very early stages and there are many moving parts that the core dev teams are working to abstract away from the process. Much of these improvements will be made public in the near future.
In the coming months, the number of steps that users need to take to pay for their subgraphs will be vastly reduced. While payments will still be made in GRT, efforts to implement a fiat on-ramp and automated payment systems to convert fiat and crypto into GRT to make recurring payments are already underway.
While there is still work to do, the aim is to offer comparable if not better quality UX on The Graph Network than currently exists on the hosted service. Short term, the aim is to offer a more streamlined and predictable billing experience that helps users focus more time building high-quality dapps.
It is recommended to curate with at least 10,000 GRT, which users can do in the same transaction as when they publish. Users can also ask the curation community to curate their subgraph here.
There are migration grants for the early migrants to cover these initial costs. Feel free to apply here.
Why does a subgraph need curation signal? What if there isn't enough signal on my subgraph from curators?
The higher the curation signal, the more attractive a subgraph is to Indexers, as there is a linear correlation between higher signal and higher indexing rewards. Without curation, there is no incentive for Indexers to pick up a subgraph.
If you are the first to signal a subgraph, your GRT signaled amount will not go down. GRT used for curation can be removed later. Also, Curators get 10% of all query fees taken in by Indexers.
Short term, the initial curation model on Arbitrum will provide principle-protection to curation signal. Longer term, the core devs will prioritize offering developers the capacity to rent curation signal, opening up a more predictable pricing experience while still ensuring subgraphs are sufficiently indexed.
After at least one Indexer has fully indexed a subgraph, a user can query the decentralized network.
In order to retrieve the query URL for your subgraph, you can copy/paste it by clicking on the symbol next to the query URL. You will see something like this:
Simply replace [api-key] with an API key generated in the Subgraph Studio API Key section.
The average query cost within the network varies. For the month of September 2022, the average price per query fee cost ranged from $0.00012 - $0.00020.
Hosted service volume data is not public. Please reach out to get volume and cost estimates here.
The gateway process queries so Indexers can serve dapps. The gateways are in an intermediate phase that is being progressively decentralized. More on this soon.
Yes, it is 1% of curation signaled. The 1% is split evenly between Curators (0.5%) and subgraph developers (0.5%). So, for every 10K GRT signaled, it costs subgraph developers 50 GRT to upgrade.
Minimize the use of smart contract calls within the subgraph. Accessing a smart contract state requires an eth_call to the RPC, which slows down sync times.
Yes, multisig support has recently been added. You can find more information here.
Many projects keep 30-60 days worth of GRT in their API key, so they don't need to refill often. To understand what your 30-60 day GRT fees would be, please reach out here.
Fees are invoiced weekly and pulled out of a user's API Key, with GRT that is bridged to and sits on Polygon
API Keys empower users to have a say in both the max query prices they pay and to prioritize factors like price, economic freshness, and query speed.
How does quality of service currently compare between the hosted service and the decentralized network?
The hosted service and decentralized network have about the same median latency, but the decentralized network tends to have higher latency at higher percentiles. 200 rates for queries are generally similar, with both > 99.9%. As a result of its decentralization, the network has not had a broad outage across subgraphs, whereas the hosted service does on rare occasions have temporary outages as a result of its centralized nature.
Please reach out to [email protected] for any additional assistance.