Subgraphs
Last updated
Last updated
Shadow RPCs support the read methods required by most subgraph services.
You can run a local subgraph pointed to a Shadow RPC today, and we're actively working on integrations with hosted subgraph providers.
You can significantly reduce the time to resync your subgraph by moving pieces of indexing logic into custom shadow events. For example, if your subgraph currently:
Uses bindings to call contract view functions for state data
Uses any callHandlers
Recreates contract logic in AssemblyScript to arrive at required values
Then you'll be able to make your subgraph sync much faster with Shadow.
Instead of making slow and expensive RPC calls, relying on function tracing, or writing complex logic in AssemblyScript, you can move everything into simple eventHandlers
with custom shadow events.
Our team can pair with you to evaluate potential subgraph performance improvements. If you're interested in getting direct support from our engineering team on this, please email .
Step-by-step instructions on setting up a local graph node pointed to your Shadow RPC.
Migrate your shadow contracts to a local solidity project where you can compile the base contract as well as generate respective ABI bindings (e.g. Foundry, Hardhat)
Points to the appropriate local contract dependencies (i.e, abi.json, source path)
Contains the shadow events in the eventHandlers
mapping
Uses the correct onchain address
Create and deploy your local subgraph to your local node; e.g:
Verify that your shadow logs are being indexed by verifying your postgres db. There should be sgd* database schema with unique tables per each contract event id. (e.g, sgd0/transfer)
a local graph node instance; requirements:
URL
Local instance
access (local/remote)
Graph
subgraph project using your local shadow contract instead of pointing to an Etherscan explorer
Verify that your subgraph.yaml :
graph create --node SUBGRAPH_NAME
graph deploy SUBGRAPH_NAME --ipfs --node