Skip to main content

The Graph

This page presents a high-level overview of how to create a subgraph for The Graph and the endpoint services provided by Neon EVM.


  • Work from The Graph CLI
yarn global add @graphprotocol/graph-cli 
# or
npm install -g @graphprotocol/graph-cli

Prerequisites for standard flow


The standard flow is where the end user deploys and collects data from their own contract. In the standard flow you:

  1. Deploy a contract to Neon EVM
  2. Collect the contract's address and block number
  3. Configure your subgraph.yaml to collect data on events emitted by contract with value and block number from previous step
  4. Deploy your subgraph

The Graph is highly customizable and supports other flows; for example, it allows you to monitor public contracts too.

  • Smart contract address on Neon EVM
  • ABI file for the deployed contract
  • Graph CLI: see The Graph docs

Neon EVM-specific deviations

On the Solana blockchain, data accounts are used to temporarily store data with a history of days. While on the Ethereum blockchain, data is stored within smart contracts. Neon EVM offers an intermediate approach by storing Solana account data for an extended period to support tracing services.

This means that The Graph may not be able to acquire all data according to the block number assigned. It is important that end users consider what data they wish to extract and store from the API service provided by their subgraph for future use.


Neon subgraph supports specVersion: 0.0.4 inside the subgraph.yaml file.


To extract, process, and store data from a dApp contract on Neon EVM using The Graph protocol, you must deploy a dedicated subgraph to a Graph node.


Subgraphs map 1:1 with a dApp to provide Graph nodes with the information and logic needed to:

  • Observe the blockchain for log events of smart contacts
  • Translate the events into entities for storage

Subgraph overview

We need to create a subgraph to source data from the contract/s of interest that will constantly observe the blockchain using your chosen Neon RPC for your events of interest. When one of these events is detected, the Graph node will extract the event log data and begin to process the information using a WebAssembly script defined in the subgraph.

The script uses a GraphQL schema file in the subgraph to produce records, called entities, that represent metadata related to your query. These entities are stored on a database, so they may be queried by API requests.

A subgraph is created using three main components:

  • Subgraph manifest
  • GraphQL schema
  • AssemblyScript mapping file

Learn more from The Graph documentation.

Subgraph manifest: important considerations

The subgraph manifest is defined by the subgraph.yaml file. The manifest defines the smart contract(s) the subgraph will index, what type of events the target smart contract(s) will emit, and how to convert event data into entities that the Graph Node processes and stores for querying.

The following subgraph manifest items deserve particular attention:

  • dataSources.source
  • dataSources.source.address


dataSources.source provides both the (optional) address of the smart contract to watch and the ABI of the smart contract to use

Omitting address allows you to index matching events from all contracts.

The ABI file is a JSON file created when a Solidity contract is compiled. It contains information on functions in the smart contract and types of events that will be emitted.

Contracts fall into two broad types: personal, i.e. a contract that you have developed and deployed, and private. Let's consider how you collect ABI files for each.

Personal contracts

If you’re developing a subgraph for your own project, you generate the ABI files when you compile your smart contract.

Public contracts

If you’re developing a subgraph for an existing public project, you will need to download the project’s smart contract(s) and compile them, e.g. with truffle, to retrieve the ABI files.


dataSources.networking is important for deploying subgraphs on Neon EVM. The property maps to the network configuration provided in your project’s truffle.js file.


If you set dataSources.networking to neonlabs., then the manifest file will pull the corresponding “neonlabs” network configurations as setup in your project’s truffle.js file.


The address of the contract deployed to the in the subgraph.yaml manifest file.

The Graph endpoints

Deploy your subgraph

When you have finished creating the subgraph manifest, the subgraph’s GraphQL schema, and the AssemblyScript Mapping file, you’re ready to deploy the subgraph.

Step 1: request access

Request access to the allowlist for The Graph endpoints at You will be added to the allowlist for the endpoint of the network/s you request.

Step 2: set up

2.1 Get The Graph's CLI with:

yarn global add @graphprotocol/graph-cli

2.2 Initiate a project:

Neon EVM provides an example of how to integrate The Graph on Neon on GitHub. This project includes example of how to fetch data for the USDC token deployed on Neon Mainnet.

Step 3: create

For example, let's create a subgraph called test-subgraph on Neon EVM. From The Graph CLI, run:

graph create neonlabs/test-subgraph --node

Step 4: instantiate

In the CLI, instantiate test-subgraph with:


graph codegen


graph build

Step 5: deploy

Deploy to the Graph node with:

graph deploy neonlabs/test-subgraph --ipfs --node --version-label="v0.0.1"

Step 6: record

Finally, record the output of the previous command: the URL at which your subgraph provides the API service feed for your data.



  • Neon subgraph supports specVersion: 0.0.4 inside the subgraph.yaml file.
  • Due to the different memory models of Solana and the EVM, there are Neon-specific deviations.

What next?

If you are new to The Graph and need further support, consider trying our full walk-through for setting up and deploying a subgraph on Neon EVM.

Was this page helpful?