diff --git a/website/pages/en/cookbook/arweave.mdx b/website/pages/en/cookbook/arweave.mdx index 8c1168fe2887..4d6c948dba27 100644 --- a/website/pages/en/cookbook/arweave.mdx +++ b/website/pages/en/cookbook/arweave.mdx @@ -2,7 +2,7 @@ title: Building Subgraphs on Arweave --- -> Arweave support in Graph Node and on the hosted service is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs! +> Arweave support in Graph Node and on the Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs! In this guide, you will learn how to build and deploy Subgraphs to index the Arweave blockchain. @@ -83,7 +83,7 @@ dataSources: ``` - Arweave subgraphs introduce a new kind of data source (`arweave`) -- The network should correspond to a network on the hosting Graph Node. On the hosted service, Arweave's mainnet is `arweave-mainnet` +- The network should correspond to a network on the hosting Graph Node. in Subgraph Studio, Arweave's mainnet is `arweave-mainnet` - Arweave data sources introduce an optional source.owner field, which is the public key of an Arweave wallet Arweave data sources support two types of handlers: @@ -150,12 +150,12 @@ Block handlers receive a `Block`, while transactions receive a `Transaction`. Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings). -## Deploying an Arweave Subgraph on the hosted service +## Deploying an Arweave Subgraph in Subgraph Studio -Once your subgraph has been created on the hosted service dashboard, you can deploy by using the `graph deploy` CLI command. +Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command. ```bash -graph deploy --node https://api.thegraph.com/deploy/ --ipfs https://api.thegraph.com/ipfs/ --access-token +graph deploy --studio --access-token ``` ## Querying an Arweave Subgraph diff --git a/website/pages/en/cookbook/cosmos.mdx b/website/pages/en/cookbook/cosmos.mdx index ef21e4bc0855..9e8966cda0d1 100644 --- a/website/pages/en/cookbook/cosmos.mdx +++ b/website/pages/en/cookbook/cosmos.mdx @@ -196,16 +196,14 @@ $ graph build ## Deploying a Cosmos subgraph -Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command after running the `graph create` CLI command: +Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command: -**Hosted Service** +**Subgraph Studio** -```bash -graph create account/subgraph-name --product hosted-service -``` +Visit the Subgraph Studio to create a new subgraph. ```bash -graph deploy account/subgraph-name --product hosted-service +graph deploy --studio subgraph-name ``` **Local Graph Node (based on default configuration):** @@ -236,7 +234,7 @@ Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testne ### Osmosis -> Osmosis support in Graph Node and on the Hosted Service is in beta: please contact the graph team with any questions about building Osmosis subgraphs! +> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs! #### What is Osmosis? diff --git a/website/pages/en/cookbook/grafting.mdx b/website/pages/en/cookbook/grafting.mdx index 489d41cccd64..9393e1538834 100644 --- a/website/pages/en/cookbook/grafting.mdx +++ b/website/pages/en/cookbook/grafting.mdx @@ -26,7 +26,7 @@ In this tutorial, we will be covering a basic usecase. We will replace an existi ## Important Note on Grafting When Upgrading to the Network -> **Caution**: if you are upgrading your subgraph from Subgraph Studio or the hosted service to the decentralized network, it is strongly recommended to avoid using grafting during the upgrade process. +> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network ### Why Is This Important? diff --git a/website/pages/en/cookbook/near.mdx b/website/pages/en/cookbook/near.mdx index 304e1202e278..34304aaa9ca2 100644 --- a/website/pages/en/cookbook/near.mdx +++ b/website/pages/en/cookbook/near.mdx @@ -2,8 +2,6 @@ title: Building Subgraphs on NEAR --- -> NEAR support in Graph Node and on the Hosted Service is in beta: please contact near@thegraph.com with any questions about building NEAR subgraphs! - This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/). ## What is NEAR? @@ -73,7 +71,7 @@ dataSources: ``` - NEAR subgraphs introduce a new `kind` of data source (`near`) -- The `network` should correspond to a network on the hosting Graph Node. On the Hosted Service, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet` +- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet` - NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/docs/concepts/account). This can be an account or a sub-account. - NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted. @@ -175,34 +173,35 @@ This includes a new JSON parsing function - logs on NEAR are frequently emitted Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released). -The Graph's Hosted Service currently supports indexing NEAR mainnet and testnet in beta, with the following network names: +Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names: - `near-mainnet` - `near-testnet` -More information on creating and deploying subgraphs on the Hosted Service can be found [here](/deploying/deploying-a-subgraph-to-hosted). +More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio). -As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On the Hosted Service, this can be done from [your Dashboard](https://thegraph.com/hosted-service/dashboard): "Add Subgraph". +As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph". Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command: ```sh -$ graph create --node subgraph/name # creates a subgraph on a local Graph Node (on the Hosted Service, this is done via the UI) -$ graph deploy --node --ipfs https://api.thegraph.com/ipfs/ # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash +$ graph create --node # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI) +$ graph deploy --node --ipfs https://api.thegraph.com/ipfs/ # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash ``` The node configuration will depend on where the subgraph is being deployed. -### Hosted Service +### Subgraph Studio ```sh -graph deploy --node https://api.thegraph.com/deploy/ --ipfs https://api.thegraph.com/ipfs/ --access-token +graph auth --studio +graph deploy --studio ``` ### Local Graph Node (based on default configuration) ```sh -graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 +graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 ``` Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself: diff --git a/website/pages/en/cookbook/upgrading-a-subgraph.mdx b/website/pages/en/cookbook/upgrading-a-subgraph.mdx index ef89481f0dfc..c3d932f75f23 100644 --- a/website/pages/en/cookbook/upgrading-a-subgraph.mdx +++ b/website/pages/en/cookbook/upgrading-a-subgraph.mdx @@ -87,11 +87,11 @@ More information about the nature of the network and how to handle re-orgs are d If you would like to update an existing subgraph on the network, you can do this by deploying a new version of your subgraph to Subgraph Studio using the Graph CLI. -1. Make changes to your current subgraph. A good idea is to test small fixes on Subgraph Studio by publishing to Goerli. +1. Make changes to your current subgraph. 2. Deploy the following and specify the new version in the command (eg. v0.0.1, v0.0.2, etc): ```sh -graph deploy --studio +graph deploy --studio --version ``` 3. Test the new version in Subgraph Studio by querying in the playground diff --git a/website/pages/en/deploying/deploying-a-subgraph-to-hosted.mdx b/website/pages/en/deploying/deploying-a-subgraph-to-hosted.mdx index 0a0b7122598a..a5451a6b9804 100644 --- a/website/pages/en/deploying/deploying-a-subgraph-to-hosted.mdx +++ b/website/pages/en/deploying/deploying-a-subgraph-to-hosted.mdx @@ -2,7 +2,7 @@ title: Deploying a Subgraph to the Hosted Service --- -> If a network is not supported on the hosted service, you can run your own [graph-node](https://github.com/graphprotocol/graph-node) to index it. +> Hosted service endpoints will be deprecated on June 12th 2024. [Learn more](/sunrise). This page explains how to deploy a subgraph to the hosted service. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-cli). If you have not created a subgraph already, see [creating a subgraph](/developing/creating-a-subgraph). diff --git a/website/pages/en/deploying/deploying-a-subgraph-to-studio.mdx b/website/pages/en/deploying/deploying-a-subgraph-to-studio.mdx index d6f0f891c6cc..973f4d70fda0 100644 --- a/website/pages/en/deploying/deploying-a-subgraph-to-studio.mdx +++ b/website/pages/en/deploying/deploying-a-subgraph-to-studio.mdx @@ -13,7 +13,7 @@ These are the steps to deploy your subgraph to the Subgraph Studio: ## Installing Graph CLI -We are using the same CLI to deploy subgraphs to our [hosted service](https://thegraph.com/hosted-service/) and to the [Subgraph Studio](https://thegraph.com/studio/). Here are the commands to install graph-cli. This can be done using npm or yarn. +There is a CLI to deploy subgraphs to [Subgraph Studio](https://thegraph.com/studio/). Here are the commands to install graph-cli. This can be done using npm or yarn. **Install with yarn:** diff --git a/website/pages/en/deploying/hosted-service.mdx b/website/pages/en/deploying/hosted-service.mdx index 3b65cfbccdf0..efe8d21accda 100644 --- a/website/pages/en/deploying/hosted-service.mdx +++ b/website/pages/en/deploying/hosted-service.mdx @@ -2,7 +2,7 @@ title: What is the Hosted Service? --- -> Please note, the hosted service will begin sunsetting in 2023, but it will remain available to networks that are not supported on the decentralized network. Developers are encouraged to [upgrade their subgraphs to The Graph Network](/cookbook/upgrading-a-subgraph) as more networks are supported. Each network will have their hosted service equivalents gradually sunset to ensure developers have enough time to upgrade subgraphs to the decentralized network. Read more about the sunsetting of the hosted service [here](https://thegraph.com/blog/sunsetting-hosted-service). +> Please note, hosted service endpoints will be deprecated on June 12th 2024 as all subgraphs will need to upgrade to The Graph Network. Please read more in the [Sunrise FAQ](/sunrise) This section will walk you through deploying a subgraph to the [hosted service](https://thegraph.com/hosted-service/). @@ -59,4 +59,4 @@ graph init \ ## Supported Networks on the hosted service -You can find the list of the supported networks [Here](/developing/supported-networks). +You can find the list of the supported networks [here](/developing/supported-networks). diff --git a/website/pages/en/deploying/subgraph-studio.mdx b/website/pages/en/deploying/subgraph-studio.mdx index ca1796a3a120..5d6bcab25fd3 100644 --- a/website/pages/en/deploying/subgraph-studio.mdx +++ b/website/pages/en/deploying/subgraph-studio.mdx @@ -36,7 +36,7 @@ Querying subgraphs generates query fees, used to reward [Indexers](/network/inde ## Subgraph Compatibility with The Graph Network -The Graph Network is not yet able to support all of the data-sources & features available on the hosted service. In order to be supported by Indexers on the network, subgraphs must: +In order to be supported by Indexers on The Graph Network, subgraphs must: - Index a [supported network](/developing/supported-networks) - Must not use any of the following features: diff --git a/website/pages/en/glossary.mdx b/website/pages/en/glossary.mdx index cdd4e402240c..4181fc64dd5c 100644 --- a/website/pages/en/glossary.mdx +++ b/website/pages/en/glossary.mdx @@ -24,7 +24,7 @@ title: Glossary - **Indexer's Self Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit. -- **Upgrade Indexer**: A temporary Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. It ensures a seamless transition for subgraphs upgrading from the hosted service by readily serving their queries upon being published. The upgrade Indexer is not competitive with other Indexers. It supports numerous blockchains that were previously only available on the hosted service. +- **Upgrade Indexer**: A temporary Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. It ensures a seamless transition for subgraphs upgrading from the hosted service to The Graph Network. The upgrade Indexer is not competitive with other Indexers. It supports numerous blockchains that were previously only available on the hosted service. - **Delegators**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs. @@ -83,3 +83,5 @@ title: Glossary - **_Updating_ a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings. - **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2). + +- **Upgrade Window**: The countdown for hosted service users to upgrade their subgraph(s) to The Graph Network beginning on April 11th, and ending on June 12th 2024. diff --git a/website/pages/en/publishing/publishing-a-subgraph.mdx b/website/pages/en/publishing/publishing-a-subgraph.mdx index 239f940f5f6d..6119c2ad2e0a 100644 --- a/website/pages/en/publishing/publishing-a-subgraph.mdx +++ b/website/pages/en/publishing/publishing-a-subgraph.mdx @@ -14,20 +14,28 @@ You can find the list of the supported networks [Here](/developing/supported-net Subgraphs can be published to the decentralized network directly from the Subgraph Studio dashboard by clicking on the **Publish** button. Once a subgraph is published, it will be available to view in the [Graph Explorer](https://thegraph.com/explorer/). -- Subgraphs can be published to Goerli, Arbitrum goerli, Arbitrum One, or Ethereum mainnet. +- Subgraphs can be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/arbitrum/arbitrum-faq). - Regardless of the network the subgraph was published on, it can index data on any of the [supported networks](/developing/supported-networks). - When publishing a new version for an existing subgraph the same rules apply as above. -## Curating your subgraph +## Adding signal to your subgraph -> It is recommended that you curate your own subgraph with at least 3,000 GRT to ensure that it is indexed and available for querying as soon as possible. +Developers can add GRT signal to their subgraphs. If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled. You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md). Specifically supported networks can be checked [here](/developing/supported-networks). -Subgraph Studio enables you to be the first to curate your subgraph by adding GRT to your subgraph's curation pool in the same transaction. When publishing your subgraph, make sure to check the button that says, "Be the first to signal on this subgraph." +> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers. + +> If your subgraph is eligible for rewards, is recommended that you curate your own subgraph with at least 3,000 GRT (as of April 11th, 2024) in order to attract additional indexers to index your subgraph + +Subgraph Studio enables you to to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published. ![Curation Pool](/img/curate-own-subgraph-tx.png) +Alternatively, you can add GRT signal to a published subgraph from Graph Explorer. + +![Signal from Explorer](/img/signal-from-explorer.png) + ## Updating metadata for a published subgraph Once your subgraph has been published to the decentralized network, you can modify the metadata at any time by making the update in the Subgraph Studio dashboard of the subgraph. After saving the changes and publishing your updates to the network, they will be reflected in The Graph Explorer. This won’t create a new version, as your deployment hasn’t changed. diff --git a/website/pages/en/querying/_meta.js b/website/pages/en/querying/_meta.js index fb803c664ecd..024543bd8ea8 100644 --- a/website/pages/en/querying/_meta.js +++ b/website/pages/en/querying/_meta.js @@ -5,7 +5,6 @@ export default { 'querying-from-an-application': '', 'distributed-systems': '', 'graphql-api': '', - 'querying-the-hosted-service': '', 'querying-by-subgraph-id-vs-deployment-id': '', 'graph-client': 'Graph Client', 'querying-with-no-code': '', diff --git a/website/pages/en/querying/querying-the-graph.mdx b/website/pages/en/querying/querying-the-graph.mdx index af9dcaaf2477..69ec08adcd02 100644 --- a/website/pages/en/querying/querying-the-graph.mdx +++ b/website/pages/en/querying/querying-the-graph.mdx @@ -2,31 +2,16 @@ title: Querying The Graph --- -With the subgraph deployed, visit the [Graph Explorer](https://thegraph.com/explorer) to open up a [GraphiQL](https://github.com/graphql/graphiql) interface where you can explore the deployed GraphQL API for the subgraph by issuing queries and viewing the schema. +When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "Playground" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema. -An example is provided below, but please see the [Query API](/querying/graphql-api) for a complete reference on how to query the subgraph's entities. +> Please see the [Query API](/querying/graphql-api) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/querying/querying-best-practices) -## Example - -This query lists all the counters our mapping has created. Since we only create one, the result will only contain our one `default-counter`: - -```graphql -{ - counters { - id - value - } -} -``` - -## Using The Graph Explorer - -Each subgraph published to the decentralized Graph Explorer has a unique query URL that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner. This will open a side pane that will give you the unique query URL of the subgraph as well as some instructions about how to query it. +Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner. ![Query Subgraph Pane](/img/query-subgraph-pane.png) -As you can notice, this query URL must use a unique API key. You can create and manage your API keys in the [Subgraph Studio](https://thegraph.com/studio) in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio). +Learn more about querying from an application [here](/querying/querying-from-an-application). -Querying subgraphs using your API keys will generate query fees that will be paid in GRT. You can learn more about billing [here](/billing). +As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio). -You can also use the GraphQL playground in the "Playground" tab to query a subgraph within The Graph Explorer. +Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/billing). diff --git a/website/pages/en/querying/querying-the-hosted-service.mdx b/website/pages/en/querying/querying-the-hosted-service.mdx deleted file mode 100644 index f00ff226ce09..000000000000 --- a/website/pages/en/querying/querying-the-hosted-service.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Querying the Hosted Service ---- - -With the subgraph deployed, visit the [hosted service](https://thegraph.com/hosted-service/) to open up a [GraphiQL](https://github.com/graphql/graphiql) interface where you can explore the deployed GraphQL API for the subgraph by issuing queries and viewing the schema. - -An example is provided below, but please see the [Query API](/querying/graphql-api) for a complete reference on how to query the subgraph's entities. - -## Example - -This query lists all the counters our mapping has created. Since we only create one, the result will only contain our one `default-counter`: - -```graphql -{ - counters { - id - value - } -} -``` - -## Using the hosted service - -The Graph Explorer and its GraphQL playground is a useful way to explore and query deployed subgraphs on the hosted service. - -Some of the main features are detailed below: - -![Explorer Playground](/img/explorer-playground.png) diff --git a/website/pages/en/quick-start.mdx b/website/pages/en/quick-start.mdx index 8ab11b27ba5d..de5fa0718501 100644 --- a/website/pages/en/quick-start.mdx +++ b/website/pages/en/quick-start.mdx @@ -2,7 +2,7 @@ title: Quick Start --- -This guide will quickly take you through how to initialize, create, and deploy your subgraph to the Subgraph Studio or the hosted service. +This guide will quickly take you through how to initialize, create, and deploy your subgraph to the Subgraph Studio. Ensure that your subgraph will be indexing data from a [supported network](/developing/supported-networks). diff --git a/website/pages/en/sunrise.mdx b/website/pages/en/sunrise.mdx index 006297b6747d..cb9a86f7be90 100644 --- a/website/pages/en/sunrise.mdx +++ b/website/pages/en/sunrise.mdx @@ -10,11 +10,21 @@ The Sunrise of Decentralized Data is an initiative spearheaded by Edge & Node. T This plan draws on many previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs, and the ability to integrate new blockchain networks to The Graph. -### What are the phases of the Sunrise of Decentralized Data? +### What are the phases of the Sunrise? **Sunray**: Enable support for hosted service chains, introduce a seamless upgrade flow, offer a free plan on The Graph Network as well as simple payment options. -**Sunbeam**: The upgrade window that subgraph developers will have to upgrade their subgraphs to The Graph Network. The start and length of this will be announced soon. -**Sunrise**: Hosted service endpoints will expire as traffic moves to The Graph Network. +**Sunbeam**: The upgrade window that subgraph developers will have to upgrade their hosted service subgraphs to The Graph Network. This window will end on June 12th 2024. +**Sunrise**: Hosted service endpoints will be deprecated on June 12th 2024. + +## Upgrading subgraphs to The Graph Network + +### When will hosted service subgraphs no longer be available? + +Hosted service subgraph endpoints will be deprecated on June 12th, 2024 (the cutoff date). + +### Will my hosted service subgraph be supported on The Graph Network? + +Yes, the upgrade Indexer will automatically support all hosted service subgraphs published to The Graph Network for a seamless upgrade experience. ### How do I upgrade my hosted service subgraph? @@ -28,63 +38,67 @@ To upgrade a hosted service subgraph, you can visit the subgraph dashboard on th 2. Select the receiving wallet (the wallet that will become the owner of the subgraph). 3. Click the "Upgrade" button. -Once your subgraph is published, the [upgrade Indexer](#what-is-an-upgrade-indexer) will begin serving queries on it, so you can begin making queries immediately! +Once your subgraph is published, the [upgrade Indexer](#what-is-an-upgrade-indexer) will begin serving queries on it, so you can begin making queries immediately, once you have generated an API key ([learn more](/cookbook/upgrading-a-subgraph/#what-next)). -### What happens if I don't upgrade my subgraph? +### How can I get support with the upgrade process? -Hosted service endpoints will expire at the end of the upgrade window. +The Graph community is here to support developers as they move to The Graph Network. Join The Graph's [Discord server](https://discord.gg/vtvv7FP) and request help in the #upgrade-decentralized-network channel. -### Do I need to run my own infrastructure? +### How can I ensure high quality of service and redundancy for subgraphs on The Graph Network? -No, all infrastructure is operated by independent Indexers on The Graph Network, including the upgrade Indexer ([read more below](#what-is-an-upgrade-indexer)). +All subgraphs will be supported by the upgrade indexer. Developers can add GRT signal to Subgraphs eligible for indexing rewards in order to attract additional Indexers, for redundancy and improved quality of service ([learn more about adding signal to your subgraph](/publishing/publishing-a-subgraph/#curating-your-subgraph)) -You can use the [Subgraph Studio](https://thegraph.com/studio/) to create, test, and publish your subgraph. All hosted service users are encouraged to upgrade their subgraphs to The Graph Network. The upgrade Indexer ensures you can query your subgraph even without curation signal. +Subgraphs which are not eligible for indexing rewards may have difficulty attracting further Indexers. For example, indexing rewards may not be available for subgraphs on certain chains (check support [here](/developing/supported-networks)). -Once your subgraph has reached adequate curation signal and other Indexers begin supporting it, the upgrade Indexer will gradually taper off, allowing other Indexers to collect indexing rewards and query fees. - -### Should I host my own indexing infrastructure? +Members from these blockchain communities are encouraged to integrate their chain through the [Chain Integration Process](/chain-integration-overview/). -Running infrastructure for your own project is [significantly more resource intensive](/network/benefits/) when compared to using The Graph Network. +### How do I publish new versions to the network? -Additionally, The Graph Network is significantly more robust, reliable, and cost-efficient than anything provided by a single organization or team. Hundreds of independent Indexers around the world power The Graph Network, ensuring safety, security and redundancy. - -That being said, if you’re still interested in running a [Graph Node](https://github.com/graphprotocol/graph-node), consider joining The Graph Network [as an Indexer](https://thegraph.com/blog/how-to-become-indexer/) to earn indexing rewards and query fees by serving data on your subgraph and others. +You can deploy new versions of your subgraph directly to Subgraph Studio, which provides a testing environment, before publishing to the network for production usage. Subgraph Studio has a different deployment command to the , and requires a `version-label` for each new deployment. -### Should I use a centralized indexing provider? +1. Upgrade to the latest version of [graph-cli](https://www.npmjs.com/package/@graphprotocol/graph-cli) +2. Update your deploy command -If you are building in web3, the moment you use a centralized indexing provider, you are giving them control of your dapp and data. The Graph’s decentralized network offers [superior quality of service](https://thegraph.com/blog/qos-the-graph-network/), reliability with unbeatable uptime thanks to node redundancy, as well as significantly [lower costs](/network/benefits/), and you won’t be held hostage at the data layer. +```sh +# Authorize with Subgraph Studio, available on your subgraph page +## Alternativel pass this into the deploy command as --access-token (see below) +graph auth --studio -With The Graph Network, your subgraph is public and anyone can query it openly, which increases the usage and network effects of your dapp. With a centralized indexing solution, the subgraph is private to the centralized provider. +# Deploy to Subgraph studio +## Unlike the hosted service, the name is just the subgraph name (no github id) +## If using `--node` directly, you can pass in https://api.studio.thegraph.com/deploy/ +graph deploy --studio --version --access-token +``` -Here's a detailed breakdown of the benefits of The Graph over centralized hosting: +This new version will then sync on the subgraph studio, a testing and sandbox environment. When you are ready to move a new version to production, you can [publish the subgraph version](/publishing/publishing-a-subgraph). -- **Resilience and Redundancy**: Decentralized systems are inherently more robust and resilient due to their distributed nature. Data isn't stored on a single server or location. Instead, it's served by hundreds of independent Indexers around the globe. This reduces the risk of data loss or service interruptions if one node fails, leading to exceptional uptime (99.99%). +> Publishing requires Arbitrum ETH - upgrading your subgraph also airdrops a small amount to facilitate your first protocol interactions 🧑‍🚀 -- **Quality of Service**: In addition to the impressive uptime, The Graph Network features a ~106ms median query speed (latency), and higher query success rates compared to hosted alternatives. Read more in [this blog](https://thegraph.com/blog/qos-the-graph-network/). +### What happens if I don't upgrade my subgraph? -- **Censorship Resistance**: Centralized systems can become targets for censorship, either through regulatory pressures or network attacks. In contrast, decentralized systems, due to their dispersed architecture, are much harder to censor, ensuring continuous data availability. +Subgraphs will be queryable on the hosted service until the cutoff date, after which they will be rate limited. Owners will still be able to simply upgrade their subgraphs at any time, even after the cutoff date. -- **Transparency and Trust**: Decentralized systems operate openly, enabling anyone to independently verify the data. This transparency builds trust among network participants, as they can verify the system's integrity without relying on a central authority. +### I use a subgraph developed by someone else, how can I make sure that my service isn't interrupted? -Just as you've chosen your blockchain network for its decentralized nature, security, and transparency, opting for The Graph Network is an extension of those same principles. By aligning your data infrastructure with these values, you ensure a cohesive, resilient, and trust-driven development environment. +When the owner has upgraded their subgraph, you will be able to easily go from the subgraph's Hosted Service page to the corresponding subgraph on The Graph Network, and update your application to use the new subgraph's query URL ([learn more](querying/querying-the-graph)). -### Will my hosted service subgraph be supported by the upgrade Indexer? +Around the start of June, Edge & Node will automatically upgrade actively queried subgraphs. This will give any third party data consumers an opportunity to move to the new Network subgraph endpoints before the cutoff date. The subgraph owners will still be able to “claim” these subgraphs on the network using the Hosted Service upgrade flow. -Yes, the upgrade Indexer will support all hosted service subgraphs published to The Graph Network. +### How can I get started querying subgraphs on The Graph Network? -However, some subgraphs may not be eligible for indexing rewards, and as a result, may have difficulty attracting further Indexers. For example, indexing rewards may not be available for subgraphs on certain chains. Members from these blockchain communities are encouraged to integrate their chain through the [Chain Integration Process](/chain-integration-overview/). +You can explore available subgraphs on [Graph Explorer](https://thegraph.com/explorer). [Learn more about querying subgraphs on The Graph](/querying/querying-the-graph). -## What is an upgrade Indexer? +## About the Upgrade Indexer -### What does "upgrade Indexer" mean? +### What is the upgrade Indexer? -It is designed to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and supporting new versions of existing subgraphs that have not yet been indexed. +The upgrade Indexer is designed to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and supporting new versions of existing subgraphs that have not yet been indexed. The upgrade Indexer is aimed at bootstrapping chains that do not yet have indexing rewards on the network, as well as a fallback for new subgraph versions. The goal is to ensure that an Indexer is available to serve queries as quickly as possible after a subgraph is published. -### What chains will the upgrade Indexer support? +### What chains does the upgrade Indexer support? -The upgrade Indexer will support chains that are currently only available on the hosted service. This will include many hosted service subgraphs that have already been synced. +The upgrade Indexer supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/developing/supported-networks/). @@ -94,9 +108,9 @@ Edge and Node has historically maintained the hosted service and, as a result, h Any and all Indexers are encouraged to become upgrade Indexers as well. However, note that operating an upgrade Indexer is largely provided as a public service to support new subgraphs and additional chains due to the lack of indexing rewards before they are approved by The Graph Council. -### What does this mean for existing Indexers? +### What does the upgrade indexer mean for existing Indexers? -Chains that are currently exclusively supported on the hosted service will be made available to developers on The Graph without indexing rewards at first, though this does unlock query fees for any Indexer that is interested. This is expected to lead to an increase in the number of subgraphs being published on the network, providing more opportunities for Indexers to index and serve these subgraphs in return for query fees, even before indexing rewards are enabled for a chain. +Chains that were previously exclusively supported on the hosted service are available to developers on The Graph without indexing rewards at first, though this does unlock query fees for any Indexer that is interested. This is expected to lead to an increase in the number of subgraphs being published on the network, providing more opportunities for Indexers to index and serve these subgraphs in return for query fees, even before indexing rewards are enabled for a chain. The upgrade Indexer also provides the Indexer community with information about potential demand for subgraphs and new chains on The Graph Network. @@ -116,7 +130,7 @@ Subgraph developers will be able to query their subgraphs on the network almost ### How does this benefit data consumers? -The upgrade Indexer enables chains on the network that are currently only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network. +The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network. ### How will the upgrade Indexer price queries? @@ -129,3 +143,43 @@ The upgrade Indexer will serve a subgraph until it is sufficiently and successfu Furthermore, the upgrade Indexer will stop supporting a subgraph if it has not been queried in the last 30 days. Other Indexers are incentivized to support subgraphs with ongoing query volume, so the query volume to the upgrade Indexer should trend towards zero because the Indexer will have a small allocation size and other Indexers will be chosen for queries ahead of the upgrade Indexer. + +## About The Graph Network + +### Do I need to run my own infrastructure? + +No, all infrastructure is operated by independent Indexers on The Graph Network, including the upgrade Indexer ([read more below](#what-is-an-upgrade-indexer)). + +You can use the [Subgraph Studio](https://thegraph.com/studio/) to create, test, and publish your subgraph. All hosted service users must upgrade their subgraph to The Graph Network before the end of the upgrade window ending on June 12th 2024. + +The upgrade Indexer ensures you can query your subgraph even without curation signal. + +Once your subgraph has reached adequate curation signal and other Indexers begin supporting it, the upgrade Indexer will gradually taper off, allowing other Indexers to collect indexing rewards and query fees. + +### Should I host my own indexing infrastructure? + +Running infrastructure for your own project is [significantly more resource intensive](/network/benefits/) when compared to using The Graph Network. + +Additionally, The Graph Network is significantly more robust, reliable, and cost-efficient than anything provided by a single organization or team. Hundreds of independent Indexers around the world power The Graph Network, ensuring safety, security and redundancy. + +That being said, if you’re still interested in running a [Graph Node](https://github.com/graphprotocol/graph-node), consider joining The Graph Network [as an Indexer](https://thegraph.com/blog/how-to-become-indexer/) to earn indexing rewards and query fees by serving data on your subgraph and others. + +### Should I use a centralized indexing provider? + +If you are building in web3, the moment you use a centralized indexing provider, you are giving them control of your dapp and data. The Graph’s decentralized network offers [superior quality of service](https://thegraph.com/blog/qos-the-graph-network/), reliability with unbeatable uptime thanks to node redundancy, as well as significantly [lower costs](/network/benefits/), and you won’t be held hostage at the data layer. + +With The Graph Network, your subgraph is public and anyone can query it openly, which increases the usage and network effects of your dapp. With a centralized indexing solution, the subgraph is private to the centralized provider. + +Additionally, the upgrade Indexer enables 100,000 free monthly queries for your subgraph before needing to pay for queries. + +Here's a detailed breakdown of the benefits of The Graph over centralized hosting: + +- **Resilience and Redundancy**: Decentralized systems are inherently more robust and resilient due to their distributed nature. Data isn't stored on a single server or location. Instead, it's served by hundreds of independent Indexers around the globe. This reduces the risk of data loss or service interruptions if one node fails, leading to exceptional uptime (99.99%). + +- **Quality of Service**: In addition to the impressive uptime, The Graph Network features a ~106ms median query speed (latency), and higher query success rates compared to hosted alternatives. Read more in [this blog](https://thegraph.com/blog/qos-the-graph-network/). + +- **Censorship Resistance**: Centralized systems are targets for censorship, either through regulatory pressures or network attacks. In contrast, decentralized systems, due to their dispersed architecture, are much harder to censor, ensuring continuous data availability. + +- **Transparency and Trust**: Decentralized systems operate openly, enabling anyone to independently verify the data. This transparency builds trust among network participants, as they can verify the system's integrity without relying on a central authority. + +Just as you've chosen your blockchain network for its decentralized nature, security, and transparency, opting for The Graph Network is an extension of those same principles. By aligning your data infrastructure with these values, you ensure a cohesive, resilient, and trust-driven development environment. diff --git a/website/pages/en/tokenomics.mdx b/website/pages/en/tokenomics.mdx index 91e54effa97e..79aef6a5d325 100644 --- a/website/pages/en/tokenomics.mdx +++ b/website/pages/en/tokenomics.mdx @@ -47,7 +47,7 @@ If you're reading this, you're capable of becoming a Delegator right now by head Curators identify high-quality subgraphs, and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed. -As of December 2022, subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation. +As of April 11th, 2024, subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation. Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT. diff --git a/website/public/img/signal-from-explorer.png b/website/public/img/signal-from-explorer.png new file mode 100644 index 000000000000..cdc133cb5854 Binary files /dev/null and b/website/public/img/signal-from-explorer.png differ