
Overview of Deploying on Subgraph Studio and Decentralized Network
Subgraph Studio, built by The Graph, is a user-friendly platform for crafting, testing, and launching subgraphs—tools that index blockchain data for apps. To deploy a subgraph, you start by setting it up, then push it to Subgraph Studio to test it out. From there, you can choose to publish it to The Graph’s decentralized network for real-world use. Here’s a quick overview of the steps:
Table of Contents
1. Preparing Your Subgraph
- Define the Subgraph: Ensure your subgraph is properly configured with a subgraph.yaml file (specifying data sources, entities, and mappings), schema (schema.graphql), and mapping files (e.g., in AssemblyScript).
- Test Locally: Use the Graph CLI to test your subgraph locally with a command like: bash
graph codegen && graph build
Then deploy to a local Graph node for testing: bash
graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001
Authenticate with Subgraph Studio:
- Log in to Subgraph Studio (https://thegraph.com/studio/).
- Generate an API key for authentication.
- Authenticate your local environment with: bash
graph auth --studio <YOUR_API_KEY>
2. Deploying to Subgraph Studio
- Deploy the Subgraph:
- Use the Graph CLI to deploy your subgraph to Subgraph Studio: bash
graph deploy --studio <SUBGRAPH_NAME>
- This uploads your subgraph to Subgraph Studio, where it’s hosted on a centralized service for testing and querying.
- Test the Subgraph:
- Access the subgraph’s endpoint in Subgraph Studio.
- Use the provided GraphiQL interface to run queries and verify data indexing.
- Ensure the subgraph syncs correctly with the blockchain data.
3. Publishing to the Decentralized Network
- Prepare for Decentralized Deployment:
- Ensure your subgraph is stable and fully tested in Subgraph Studio.
- Verify that the subgraph adheres to The Graph’s requirements for decentralized deployment (e.g., optimized mappings, supported networks like Ethereum mainnet or L2s).
- Publish to the Decentralized Network:
- In Subgraph Studio, select your subgraph and choose the option to publish it to the decentralized network.
- Specify the network (e.g., Ethereum mainnet) and confirm the deployment.
- This step transitions your subgraph from Subgraph Studio’s hosted environment to The Graph’s decentralized protocol, where it’s indexed by independent indexers.
- Signal the Subgraph (Optional):
- To incentivize indexers to serve your subgraph, you may need to allocate GRT (The Graph’s token) as a curation signal.
- This can be done via Subgraph Studio or directly on the decentralized network.
- Query on the Decentralized Network:
- Once published, your subgraph is accessible via The Graph’s decentralized network.
- Update your dApp or application to query the subgraph using the decentralized endpoint provided.
4. Monitoring and Maintenance
- Monitor Subgraph Health:
- Use Subgraph Studio or The Graph’s network dashboard to track indexing status, query performance, and errors.
- Update the Subgraph:
- If changes are needed (e.g., new data sources or schema updates), modify your subgraph files, test locally, and redeploy to Subgraph Studio. Then, republish to the decentralized network if necessary.
- Manage Costs:
- On the decentralized network, queries may incur costs in GRT, depending on indexer pricing. Monitor query usage and optimize your subgraph for efficiency.
Key Tools and Concepts
- Graph CLI: Used for building, testing, and deploying subgraphs (npm install -g @graphprotocol/graph-cli).
- Subgraph Studio: A centralized platform for managing and testing subgraphs before decentralized deployment.
- Decentralized Network: The Graph’s peer-to-peer network where subgraphs are indexed and queried by independent nodes.
- GRT (Graph Token): Used for signaling, curator incentives, and query payments on the decentralized network.
Common Issues and Tips
- Syncing Delays: Ensure your subgraph’s mappings are optimized to avoid slow indexing. Check for errors in the Subgraph Studio logs.
- Network Support: Verify that the blockchain network you’re indexing (e.g., Ethereum, Polygon) is supported by The Graph.
- API Key Security: Keep your Subgraph Studio API key secure and avoid sharing it publicly.
- Decentralized Costs: Be aware that querying on the decentralized network may require GRT payments, unlike Subgraph Studio’s free testing environment.
Hosted Service vs. Subgraph Studio
When it comes to The Graph protocol, the Hosted Service and Subgraph Studio serve different purposes for building and deploying subgraphs, each with its own strengths and limitations. Here’s a straightforward comparison of their roles, features, and use cases.
Hosted Service vs. Subgraph Studio
Aspect | Hosted Service | Subgraph Studio |
---|---|---|
Definition | A legacy centralized hosting platform for subgraphs, managed by The Graph team. | A modern platform for creating, testing, and deploying subgraphs, with a focus on transitioning to the decentralized network. |
Purpose | Provides a free, centralized environment to host and query subgraphs. | Facilitates subgraph development, testing, and publishing to The Graph’s decentralized network. |
Status (2025) | Deprecated as of 2023; no new subgraphs can be created, but existing ones may still be accessible for legacy users. | Actively supported; the primary tool for subgraph development and management. |
Deployment | Subgraphs are deployed directly to the Hosted Service using the Graph CLI. | Subgraphs are deployed to Subgraph Studio for testing, then optionally published to the decentralized network. |
Decentralized Network | No direct integration; subgraphs remain centralized and cannot be migrated easily to the decentralized network. | Designed to bridge to the decentralized network, allowing subgraphs to be published for decentralized indexing and querying. |
Cost | Free to use, but limited by quotas and lack of scalability. | Free for testing in Subgraph Studio; decentralized network queries may incur GRT costs based on indexer pricing. |
Scalability | Limited scalability; not suitable for production-grade dApps due to centralized infrastructure. | Highly scalable when published to the decentralized network, leveraging independent indexers. |
Authentication | Requires an access token for deployment (simpler but less secure). | Uses API keys for secure authentication, tied to a user’s Subgraph Studio account. |
Querying | Queries are made via a centralized endpoint provided by the Hosted Service. | Queries are made via Subgraph Studio (centralized) or decentralized network endpoints after publishing. |
Supported Networks | Supports multiple chains (e.g., Ethereum, Polygon), but limited compared to the decentralized network. | Supports a broader range of EVM and non-EVM chains, especially when published to the decentralized network. |
Use Case | Best for prototyping, learning, or small-scale projects (pre-2023). | Ideal for modern subgraph development, testing, and production deployment on the decentralized network. |
Maintenance | Minimal maintenance options; no updates or new features. | Full control over subgraph updates, monitoring, and optimization via Subgraph Studio’s UI and CLI. |
Future-Proofing | Not future-proof; The Graph encourages migration to Subgraph Studio and the decentralized network. | Future-proof; aligns with The Graph’s vision for a decentralized data protocol. |
Key Differences
- Centralized vs. Decentralized Focus:
- Hosted Service: Fully centralized, managed by The Graph team. It’s a legacy system designed for simplicity but lacks flexibility and scalability.
- Subgraph Studio: Acts as a centralized development hub with a clear path to the decentralized network, supporting The Graph’s decentralized protocol.
- Development Workflow:
- Hosted Service: Simplified deployment but no testing environment or direct decentralized integration.
- Subgraph Studio: Offers a robust workflow—local testing, centralized deployment for validation, and publishing to the decentralized network for production.
- Longevity:
- Hosted Service: Deprecated since 2023. Users are encouraged to migrate subgraphs to Subgraph Studio or the decentralized network.
- Subgraph Studio: The current standard, actively maintained and integrated with The Graph’s evolving ecosystem.
- Cost and Incentives:
- Hosted Service: Free but limited by quotas and no GRT-based incentives.
- Subgraph Studio: Free for development; decentralized deployment involves GRT for signaling and query costs, enabling indexer incentives.
When to Use Each
- Hosted Service:
- Suitable for legacy subgraphs created before 2023.
- Useful for quick prototyping or learning The Graph’s basics (if still accessible).
- Not recommended for new projects due to deprecation.
- Subgraph Studio:
- Best for all new subgraph development.
- Ideal for developers building production-grade dApps that require decentralized data indexing.
- Necessary for leveraging The Graph’s decentralized network and broader chain support.
Migration from Hosted Service to Subgraph Studio
If you’re using the Hosted Service, The Graph recommends migrating to Subgraph Studio:
- Export Existing Subgraph:
- Retrieve your subgraph.yaml, schema.graphql, and mapping files from the Hosted Service.
- Set Up in Subgraph Studio:
- Create a new subgraph in Subgraph Studio.
- Authenticate using the Graph CLI (graph auth –studio <API_KEY>).
- Deploy to Subgraph Studio:
- Use graph deploy –studio <SUBGRAPH_NAME> to deploy the subgraph.
- Test and Publish:
- Test the subgraph in Subgraph Studio, then publish it to the decentralized network if needed.
- Update dApp Endpoints:
- Replace Hosted Service query endpoints with Subgraph Studio or decentralized network endpoints in your application.
For detailed migration steps, refer to The Graph’s migration guide: https://thegraph.com/docs/en/hosted-service/migrating/.
Deploying to Studio
Getting your subgraph onto Subgraph Studio is a crucial step in building and testing it within The Graph ecosystem, setting the stage for an optional move to the decentralized network. Here’s a clear, step-by-step guide to deploying your subgraph to Subgraph Studio
Steps to Deploy a Subgraph to Subgraph Studio
1. Set Up Your Environment
- Install Graph CLI: Ensure you have the Graph CLI installed globally: bash
npm install -g @graphprotocol/graph-cli
- Prepare Your Subgraph:
- Create or navigate to your subgraph directory containing:
- subgraph.yaml (defines data sources, networks, and mappings).
- schema.graphql (defines the GraphQL schema).
- Mapping files (e.g., in AssemblyScript, located in the mappings/ folder).
- Ensure the subgraph is configured for a supported network (e.g., Ethereum, Polygon).
- Create or navigate to your subgraph directory containing:
2. Authenticate with Subgraph Studio
- Log in to Subgraph Studio:
- Visit https://thegraph.com/studio/ and sign in with your account (e.g., via wallet or GitHub).
- Generate an API Key:
- In Subgraph Studio, navigate to your account settings and create an API key.
- Copy the key securely (do not share it publicly).
- Authenticate Locally: Run the following command to link your local environment to Subgraph Studio: bash
graph auth --studio <YOUR_API_KEY>
- Replace <YOUR_API_KEY> with the key from Subgraph Studio.
3. Build and Test Locally
- Generate Code: Run the codegen command to generate types based on your schema:
bash
graph codegen
- Build the Subgraph: Compile your subgraph to ensure there are no errors: bash
graph build
- Optional: Test Locally: If you have a local Graph node and IPFS setup, test the subgraph locally: bash
graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001
- This step ensures your subgraph works before deploying to Subgraph Studio.
4. Deploy to Subgraph Studio
- Create a Subgraph in Studio:
- In the Subgraph Studio UI, click “Create Subgraph” and give it a name (e.g., my-subgraph).
- Note the subgraph’s slug (e.g., your-username/my-subgraph), which you’ll use in the deploy command.
- Deploy the Subgraph: Use the Graph CLI to deploy your subgraph to Subgraph Studio: bash
graph deploy --studio <SUBGRAPH_SLUG>
- Replace <SUBGRAPH_SLUG> with the slug from Subgraph Studio (e.g., your-username/my-subgraph).
- You may be prompted to select a version label (e.g., v0.0.1). Enter a label or accept the default.
- Verify Deployment:
- The CLI will output a deployment confirmation and a query URL.
- In Subgraph Studio, check the subgraph’s status. It will show as “Syncing” until indexing is complete.
5. Test the Subgraph in Subgraph Studio
- Access the Query URL:
- In Subgraph Studio, find the subgraph’s query endpoint (e.g., https://api.studio.thegraph.com/query/…).
- Run Queries:
- Use the GraphiQL interface in Subgraph Studio to test queries against your schema.
- Example query: graphql
query {
myEntities(first: 5) {
id
name
}
}
- Verify that the data returned matches your expectations.
- Check Logs:
- Monitor indexing progress and check for errors in Subgraph Studio’s logs section.
6. Troubleshoot Common Issues
- Authentication Errors:
- Ensure the API key is correct and not expired. Re-run graph auth –studio <API_KEY> if needed.
- Schema or Mapping Errors:
- Check the CLI output for errors in schema.graphql or mappings. Fix and rebuild (graph build).
- Syncing Delays:
- If the subgraph takes long to sync, optimize your mappings (e.g., reduce event handler complexity).
- Network Mismatch:
- Ensure the network in subgraph.yaml (e.g., mainnet, polygon) matches a supported chain.
Key Notes
- Subgraph Studio’s Role: It’s a centralized environment for testing and managing subgraphs. It’s free to use but not intended for production-grade querying (use the decentralized network for that).
- Versioning: Each deployment to Subgraph Studio requires a version label. Use semantic versioning (e.g., v0.0.1, v0.0.2) for clarity.
- Next Steps: After testing in Subgraph Studio, you can publish the subgraph to The Graph’s decentralized network (covered in the “Decentralized Network” part of Chapter 8). This involves selecting the subgraph in Studio and publishing it with a supported network configuration.
- Documentation: Refer to The Graph’s official Subgraph Studio guide for detailed CLI commands and UI instructions (https://thegraph.com/docs/en/studio/).
Example Workflow
Assuming you have a subgraph for an Ethereum smart contract:
- Configure subgraph.yaml: yaml
specVersion: 0.0.5
schema:
file: ./schema.graphql
dataSources:
- kind: ethereum
name: MyContract
network: mainnet
source:
address: "0x1234..."
abi: MyContract
mapping:
kind: ethereum/events
apiVersion: 0.0.7
language: wasm/assemblyscript
entities:
- MyEntity
abis:
- name: MyContract
file: ./abis/MyContract.json
eventHandlers:
- event: MyEvent(address,uint256)
handler: handleMyEvent
file: ./mappings/handlers.ts
- Run: bash
graph codegen
graph build
graph auth --studio <YOUR_API_KEY>
graph deploy --studio your-username/my-subgraph
- Test queries in Subgraph Studio’s GraphiQL interface.
Signaling and curation
In the context of The Graph protocol and deploying subgraphs, signaling and curation are key mechanisms for incentivizing indexers to serve your subgraph on the decentralized network and ensuring its discoverability and reliability.
What Are Signaling and Curation?
- Signaling:
- Signaling involves allocating GRT (Graph Token) to a subgraph on The Graph’s decentralized network to indicate its importance or value.
- This incentivizes indexers (nodes that index and serve subgraph data) to allocate resources to your subgraph, ensuring it’s indexed and queryable.
- The more GRT signaled, the more likely indexers will prioritize your subgraph, improving its availability and performance.
- Curation:
- Curation is the process by which curators (users or developers) signal GRT to a subgraph to vouch for its quality and usefulness.
- Curators earn rewards (a share of query fees) if the subgraph becomes popular and generates query revenue.
- Curation also helps users discover high-quality subgraphs through curation markets, as signaled subgraphs are more visible.
How Signaling and Curation Work in Subgraph Studio and Decentralized Network
When you deploy a subgraph to Subgraph Studio and publish it to the decentralized network, signaling and curation come into play to ensure the subgraph is indexed and accessible. Here’s the process:
1. Publishing to the Decentralized Network
- After testing your subgraph in Subgraph Studio, you publish it to The Graph’s decentralized network via the Subgraph Studio UI:
- Select your subgraph.
- Choose the target network (e.g., Ethereum mainnet).
- Confirm publication.
- This makes the subgraph available for indexing by independent indexers on the decentralized network.
2. Signaling Your Subgraph
- As a Developer:
- To encourage indexers to index your subgraph, you (or other stakeholders) can signal GRT to it.
- In Subgraph Studio or The Graph’s network interface, allocate GRT to your subgraph using a wallet (e.g., MetaMask).
- Example: Signal 1,000 GRT to your subgraph to attract indexer attention.
- Impact:
- Indexers prioritize subgraphs with higher GRT signals because they earn a portion of query fees proportional to the signal.
- Signaling ensures your subgraph is indexed quickly and remains available for queries.
3. Curation by the Community
- Role of Curators:
- Curators (e.g., developers, data consumers, or community members) can signal GRT to your subgraph if they believe it’s valuable.
- They do this through The Graph’s curation market, purchasing curation shares (representing ownership in the subgraph’s signaling pool).
- Curation Shares:
- When curators signal GRT, they receive shares proportional to their contribution.
- Shares entitle curators to a portion of future query fees generated by the subgraph.
- The share price increases as more GRT is signaled, creating a bonding curve (a dynamic pricing mechanism).
- Benefits:
- Curation makes your subgraph more discoverable, as signaled subgraphs appear prominently in The Graph’s ecosystem.
- It aligns incentives: curators are rewarded for identifying high-quality subgraphs early.
4. Querying and Rewards
- Once indexed, your subgraph is queried by dApps or users via decentralized network endpoints.
- Query fees (paid in GRT) are distributed among:
- Indexers: For serving the subgraph.
- Curators: Proportional to their curation shares.
- Protocol: A small percentage for network maintenance.
- The more queries your subgraph receives, the higher the rewards for curators and indexers, reinforcing the signaling and curation cycle.
Key Steps for Signaling in Subgraph Studio
- Access Subgraph Studio:
- Log in to https://thegraph.com/studio/ and select your published subgraph.
- Signal GRT:
- Navigate to the subgraph’s details page.
- Use the “Signal” or “Curate” option to allocate GRT from your connected wallet.
- Specify the amount of GRT to signal (e.g., 1,000 GRT).
- Monitor Signaling:
- Check the subgraph’s dashboard in Subgraph Studio or The Graph’s network explorer to see total GRT signaled and indexer activity.
- Encourage Community Curation:
- Promote your subgraph to potential curators (e.g., via The Graph’s Discord, X posts, or your dApp’s community) to attract additional signaling.
Important Considerations
- GRT Requirements:
- Signaling requires holding GRT in a compatible wallet (e.g., MetaMask). Acquire GRT via exchanges if needed.
- Signaling Risks:
- Signaled GRT is locked in the curation market and subject to the bonding curve. If you withdraw (burn shares), you may receive less GRT if the subgraph’s signal decreases.
- Curation Rewards:
- Curators earn rewards only if the subgraph generates query fees. A poorly designed or unused subgraph may yield no returns.
- Indexer Dependency:
- Even with signaling, indexing depends on indexer availability. High GRT signals increase the likelihood of indexing but don’t guarantee it.
- Costs:
- Signaling is free (beyond GRT allocation), but querying the decentralized network incurs GRT fees based on indexer pricing.
Example Scenario
- You deploy a subgraph for an Ethereum DeFi protocol to Subgraph Studio and publish it to the decentralized network.
- You signal 2,000 GRT to attract indexers.
- Community curators signal an additional 3,000 GRT, receiving curation shares.
- Indexers pick up the subgraph, and it syncs within hours.
- Your dApp queries the subgraph, generating 100 GRT in query fees monthly.
- Fees are split: indexers get the majority, curators share a portion based on their shares, and you benefit from reliable data access.
Common Issues and Tips
- Low Indexer Uptake:
- If indexers aren’t picking up your subgraph, increase your GRT signal or promote it to attract community curators.
- Bonding Curve Complexity:
- Understand the bonding curve before signaling. Early curators benefit more, but late signaling may be costlier.
- Monitoring:
- Use Subgraph Studio or The Graph’s network explorer to track signaled GRT, curation shares, and query activity.
- Community Engagement:
- Share your subgraph’s details (e.g., on X or The Graph’s forum) to encourage curation by others.
GRT indexing rewards
In The Graph protocol, GRT indexing rewards are payments in GRT (Graph Token) given to indexers for processing and serving subgraphs on the decentralized network. These rewards are a big deal, motivating indexers to dedicate computing power to keep your subgraph’s data ready for queries. Since you mentioned “Chapter 8: Deploying on Subgraph Studio and Decentralized Network” and asked about signaling and curation earlier, I’ll explain how indexing rewards tie into deploying a subgraph, especially after publishing it from Subgraph Studio to the decentralized network.
What Are GRT Indexing Rewards?
- Definition:
- Indexing rewards are GRT tokens distributed to indexers for indexing subgraphs on The Graph’s decentralized network.
- They are separate from query fees (paid by users for querying subgraph data) and are funded by the protocol’s inflation mechanism, which mints new GRT to incentivize indexing.
- Purpose:
- Encourage indexers to allocate resources (e.g., CPU, storage) to index subgraphs, ensuring they are synced with blockchain data and available for queries.
- Reward indexers for maintaining high-quality, reliable indexing services.
- Relation to Subgraphs:
- When you publish a subgraph from Subgraph Studio to the decentralized network, indexers choose to index it based on signaling (GRT allocated to the subgraph by curators or developers). Indexing rewards are tied to this signaling.
How GRT Indexing Rewards Work
1. Subgraph Publication and Signaling
- After testing your subgraph in Subgraph Studio, you publish it to The Graph’s decentralized network via the Studio UI.
- Signaling:
- You or community curators signal GRT to the subgraph to indicate its value (as discussed in your previous question).
- The total GRT signaled determines the subgraph’s share of the network’s indexing rewards.
- Higher signaling attracts more indexers, as it increases their potential rewards.
2. Indexer Allocation
- Indexers:
- Indexers are node operators who run Graph Nodes to index blockchain data for subgraphs.
- They allocate their stake (GRT they’ve locked in the protocol) to subgraphs they choose to index.
- Decision Factors:
- Indexers prioritize subgraphs with high GRT signaling, as rewards are proportional to the signal.
- They also consider query demand (potential query fees) and indexing complexity (resource costs).
3. Indexing Reward Distribution
- Reward Pool:
- The Graph protocol mints new GRT (via controlled inflation, typically ~3% annually, subject to governance) to create a reward pool.
- This pool is distributed across all subgraphs based on their relative GRT signaling.
- Reward Calculation:
- A subgraph’s indexing rewards are proportional to its share of the total GRT signaled across all subgraphs.
- Example: If your subgraph has 1% of the network’s total signaled GRT, it receives 1% of the daily indexing reward pool.
- Indexer Share:
- Indexers who index your subgraph split its rewards based on their stake allocation.
- For example, if two indexers allocate equal stake to your subgraph, they split its rewards 50/50.
- Frequency:
- Rewards are distributed periodically (e.g., daily or weekly), depending on protocol settings, and credited to indexers’ wallets.
4. Impact on Subgraph Developers
- As a subgraph developer, you don’t directly receive indexing rewards (those go to indexers).
- However, indexing rewards indirectly benefit you by:
- Incentivizing indexers to index your subgraph, ensuring it’s available and synced.
- Improving query performance and reliability for your dApp or users.
- To maximize indexer participation, signal sufficient GRT to your subgraph or encourage community curation (as covered in your previous question).
Key Factors Affecting Indexing Rewards
- Signaling Amount:
- Subgraphs with more GRT signaled receive a larger share of the reward pool, attracting more indexers.
- Network Competition:
- If many subgraphs have high signaling, your subgraph’s reward share may be smaller unless it has significant GRT signaled.
- Indexer Efficiency:
- Indexers must optimize their infrastructure to index efficiently, as rewards are only earned for active, synced subgraphs.
- Protocol Parameters:
- Reward distribution is governed by parameters like inflation rate and reward cuts, set by The Graph’s governance (e.g., via GRT holders or council).
Steps to Ensure Indexing for Your Subgraph
To leverage indexing rewards for your subgraph after publishing from Subgraph Studio:
- Signal GRT:
- In Subgraph Studio or The Graph’s network interface, allocate GRT to your subgraph to attract indexers.
- Example: Signal 2,000 GRT to make your subgraph competitive.
- Promote Curation:
- Encourage community curators to signal GRT, increasing the total signal and reward share.
- Share your subgraph on The Graph’s Discord, X, or forums.
- Monitor Indexing:
- Check Subgraph Studio or The Graph’s network explorer to see which indexers are indexing your subgraph and its sync status.
- Optimize Subgraph:
- Ensure your subgraph is efficient (e.g., optimized mappings, minimal event handlers) to reduce indexing costs for indexers, making it more attractive.
Example Scenario
- You publish a subgraph for a DeFi protocol to the decentralized network.
- You signal 5,000 GRT, and curators add 10,000 GRT, totaling 15,000 GRT signaled.
- The network has 1,500,000 GRT signaled across all subgraphs, so your subgraph has 1% of the total signal.
- The daily indexing reward pool is 10,000 GRT (hypothetical).
- Your subgraph receives 1% of the pool = 100 GRT daily.
- Three indexers allocate stake to your subgraph, splitting the 100 GRT based on their stake proportions.
- Your dApp benefits from reliable indexing, and indexers are incentivized to maintain service.
Common Issues and Tips
- Low Indexer Uptake:
- If no indexers pick up your subgraph, increase GRT signaling or promote it to attract curators.
- Check if your subgraph is on a supported network (e.g., Ethereum, Polygon).
- Reward Dilution:
- In a competitive network, your subgraph’s reward share may be small. Focus on building a high-quality subgraph to justify signaling.
- Indexer Reliability:
- Not all indexers are equally reliable. Monitor sync status in Subgraph Studio to ensure your subgraph is indexed correctly.
- GRT Volatility:
- Indexing rewards are paid in GRT, whose value may fluctuate. Indexers bear this risk, but it may affect their willingness to index low-signal subgraphs.
Example: Publish a subgraph to the decentralized network
Below is a step-by-step example of how to publish a subgraph from Subgraph Studio to The Graph’s decentralized network, including signaling to attract indexers, as referenced in the context of “Chapter 8: Deploying on Subgraph Studio and Decentralized Network.” This example assumes you have a working subgraph (e.g., for an Ethereum smart contract) and are ready to move from Subgraph Studio’s centralized testing environment to the decentralized network. I’ll provide a practical, concise workflow with sample configurations, commands, and signaling steps, based on standard practices as of April 18, 2025. If you have specific details (e.g., your subgraph’s configuration, network, or issues from Chapter 8), please share them, and I can tailor the response further.
Example: Publishing a Subgraph to the Decentralized Network
Scenario
You’ve developed a subgraph to index events from an Ethereum DeFi smart contract (e.g., a lending protocol) that emits a Deposit(address, uint256) event. You’ve tested it in Subgraph Studio, and now you want to publish it to The Graph’s decentralized network, signal GRT to attract indexers, and make it queryable for your dApp.
Step 1: Prepare Your Subgraph
Ensure your subgraph is ready for deployment. Here’s a sample configuration:
- Directory Structure :
my-subgraph/
├── subgraph.yaml
├── schema.graphql
├── abis/
│ └── LendingProtocol.json
├── mappings/
│ └── handlers.ts
- subgraph.yaml (Configuration): yaml
specVersion: 0.0.5
schema:
file: ./schema.graphql
dataSources:
- kind: ethereum
name: LendingProtocol
network: mainnet
source:
address: "0x1234567890abcdef1234567890abcdef12345678"
abi: LendingProtocol
startBlock: 12345678
mapping:
kind: ethereum/events
apiVersion: 0.0.7
language: wasm/assemblyscript
entities:
- Deposit
abis:
- name: LendingProtocol
file: ./abis/LendingProtocol.json
eventHandlers:
- event: Deposit(address,uint256)
handler: handleDeposit
file: ./mappings/handlers.ts
- schema.graphql (Schema): graphql
type Deposit @entity {
id: ID!
user: Bytes!
amount: BigInt!
timestamp: BigInt!
}
- mappings/handlers.ts (Mapping Logic): typescript
import { Deposit as DepositEvent } from "../generated/LendingProtocol/LendingProtocol";
import { Deposit } from "../generated/schema";
import { BigInt } from "@graphprotocol/graph-ts";
export function handleDeposit(event: DepositEvent): void {
let id = event.transaction.hash.toHex() + "-" + event.logIndex.toString();
let deposit = new Deposit(id);
deposit.user = event.params.user;
deposit.amount = event.params.amount;
deposit.timestamp = event.block.timestamp;
deposit.save();
}
- Build the Subgraph: In your subgraph directory, run: bash
graph codegen
graph build
- This generates types and compiles the subgraph, ensuring no errors.
Step 2: Deploy to Subgraph Studio
Before publishing to the decentralized network, deploy and test the subgraph in Subgraph Studio.
- Authenticate with Subgraph Studio:
- Log in to https://thegraph.com/studio/.
- Create an API key in your account settings.
- Authenticate locally: bash
graph auth --studio <YOUR_API_KEY>
- Create a Subgraph in Studio:
- In Subgraph Studio, click “Create Subgraph” and name it (e.g., “lending-deposits”).
- Note the subgraph slug (e.g., your-username/lending-deposits).
- Deploy to Subgraph Studio
: Bash
graph deploy --studio your-username/lending-deposits
- Specify a version label (e.g., v0.0.1) when prompted.
- The CLI outputs a query URL (e.g., https://api.studio.thegraph.com/query/…).
- Test in Subgraph Studio:
- In Subgraph Studio, check the subgraph’s status (it should say “Syncing” until complete).
- Use the GraphiQL interface to test a query: graphql
query {
deposits(first: 5, orderBy: timestamp, orderDirection: desc) {
id
user
amount
timestamp
}
}
- Verify the data matches expected blockchain events.
- Check logs for errors and ensure syncing completes.
Step 3: Publish to the Decentralized Network
Once the subgraph is stable in Subgraph Studio, publish it to the decentralized network.
- Access Subgraph Studio:
- Log in to https://thegraph.com/studio/ and select your subgraph (lending-deposits).
- Publish to Decentralized Network:
- In the subgraph’s dashboard, click the “Publish” button.
- Select the target network (e.g., mainnet for Ethereum).
- Confirm the publication.
- The subgraph is now registered on The Graph’s decentralized network, but it needs indexing to be queryable.
- Verify Publication:
- Check the subgraph’s status in Subgraph Studio or The Graph’s network explorer (https://thegraph.com/explorer).
- It will appear as “Pending” until indexers pick it up.
Step 4: Signal GRT to Attract Indexers
To incentivize indexers to index your subgraph, signal GRT:
- Acquire GRT:
- Ensure you have GRT in a compatible wallet (e.g., MetaMask). Purchase GRT via an exchange if needed.
- Signal GRT in Subgraph Studio:
- In Subgraph Studio, navigate to your subgraph’s details.
- Click the “Signal” or “Curate” option.
- Connect your wallet and allocate GRT (e.g., 2,000 GRT).
- Confirm the transaction (this locks GRT in the curation market and issues you curation shares).
- Encourage Community Curation:
- Share your subgraph’s details (e.g., on The Graph’s Discord, X, or your dApp’s community) to attract additional curators.
- Example X post: “Just published our DeFi lending subgraph to @thegraph’s decentralized network! Signal GRT to support reliable indexing: [link to subgraph].”
- More GRT signaled increases the subgraph’s share of indexing rewards, attracting more indexers.
- Monitor Indexing:
- Check Subgraph Studio or the network explorer to see which indexers pick up your subgraph.
- Once indexed, the status changes to “Synced,” and the subgraph is queryable via a decentralized endpoint (e.g., https://gateway.thegraph.com/…).
Step 5: Query the Subgraph
Update your dApp to query the subgraph on the decentralized network.
- Get the Decentralized Endpoint:
- Find the query URL in Subgraph Studio or the network explorer after indexing completes.
- Example Query in Your dApp (using Apollo Client): javascript
import { ApolloClient, InMemoryCache, gql } from "@apollo/client";
const client = new ApolloClient({
uri: "https://gateway.thegraph.com/api/[your-subgraph-id]/subgraphs/id/[id]",
cache: new InMemoryCache(),
});
const DEPOSITS_QUERY = gql`
query {
deposits(first: 5, orderBy: timestamp, orderDirection: desc) {
id
user
amount
timestamp
}
}
`;
client.query({ query: DEPOSITS_QUERY }).then((result) => {
console.log(result.data.deposits);
});
- Note: Queries may incur GRT fees based on indexer pricing. Monitor usage in Subgraph Studio.
Step 6: Monitor and Maintain
- Track Indexing and Queries:
- Use Subgraph Studio to monitor sync status, indexer activity, and query performance.
- Check total GRT signaled and curation shares in the network explorer.
- Update the Subgraph:
- If you need to modify the schema or mappings, update the files, redeploy to Subgraph Studio (graph deploy –studio), and republish to the decentralized network.
- Optimize Signaling:
- If indexing is slow or limited, increase your GRT signal or promote curation to attract more indexers.
Example Outcomes
- Signaling: You signal 2,000 GRT, and curators add 3,000 GRT, totaling 5,000 GRT.
- Indexing: Two indexers allocate stake to your subgraph, syncing it within 24 hours.
- Rewards: Your subgraph receives 0.5% of the network’s daily indexing reward pool (e.g., 50 GRT/day if the pool is 10,000 GRT), split among the indexers.
- Queries: Your dApp queries the subgraph, paying small GRT fees to indexers, while curators earn a share of fees based on their curation shares.
- Result: Your DeFi protocol has reliable, decentralized data access for users.
Common Issues and Tips
- No Indexers Pick Up the Subgraph:
- Increase GRT signaling (e.g., to 5,000 GRT) or promote to curators.
- Ensure the network (e.g., mainnet) is supported and the subgraph is error-free.
- Syncing Delays:
- Optimize mappings (e.g., reduce complex logic in handlers.ts) to lower indexing costs for indexers.
- Check logs in Subgraph Studio for errors.
- Query Fees:
- Monitor query costs in Subgraph Studio. Optimize queries (e.g., limit fields or pagination) to reduce GRT expenditure.
- Curation Risks:
- Signaled GRT is subject to the bonding curve. If you withdraw, you may receive less GRT if the subgraph’s signal decreases.
Additional Resources
- The Graph Documentation: https://thegraph.com/docs/en/developing/publishing-a-subgraph/ for publishing and signaling guides.
- Subgraph Studio: https://thegraph.com/studio/ for managing and publishing your subgraph.
- Network Explorer: https://thegraph.com/explorer to track indexing and signaling.
- Community: Join The Graph’s Discord or check X for curation and indexing tips.