Building Subgraphs on NEAR
Last updated
Was this helpful?
Last updated
Was this helpful?
NEAR support in Graph Node and on the Hosted Service is in beta: please contact with any questions about building NEAR subgraphs!
This guide is an introduction to building subgraphs indexing smart contracts on the .
is a smart contract platform for building decentralized applications. Visit the for more information.
The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
Subgraphs are event-based, which means that they listen for and then process on-chain events. There are currently two types of handlers supported for NEAR subgraphs:
Block handlers: these are run on every new block
Receipt handlers: run every time a message is executed at a specified account
:
A Receipt is the only actionable object in the system. When we talk about "processing a transaction" on the NEAR platform, this eventually means "applying receipts" at some point.
@graphprotocol/graph-cli
is a command-line tool for building and deploying subgraphs.
@graphprotocol/graph-ts
is a library of subgraph-specific types.
NEAR subgraph development requires graph-cli
above version 0.23.0
, and graph-ts
above version 0.23.0
.
Building a NEAR subgraph is very similar to building a subgraph that indexes Ethereum.
There are three aspects of subgraph definition:
subgraph.yaml: the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new kind
of data source.
During subgraph development there are two key commands:
The subgraph manifest (subgraph.yaml
) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph::
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
NEAR data sources support two types of handlers:
blockHandlers
: run on every new NEAR block. No source.account
is required.
These types are passed to block & receipt handlers:
Block handlers will receive a Block
Receipt handlers will receive a ReceiptWithOutcome
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:
near-mainnet
near-testnet
Once your subgraph has been created, you can deploy your subgraph by using the graph deploy
CLI command:
The node configuration will depend on where the subgraph is being deployed.
Hosted Service:
Local Graph Node (based on default configuration):
Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself:
Running a Graph Node that indexes NEAR has the following operational requirements:
NEAR Indexer Framework with Firehose instrumentation
NEAR Firehose Component(s)
Graph Node with Firehose endpoint configured
We will provide more information on running the above components soon.
Here are some example subgraphs for reference:
No, a subgraph can only support data sources from one chain/network.
Currently, only Block and Receipt triggers are supported. We are investigating triggers for function calls to a specified account. We are also interested in supporting event triggers, once NEAR has native event support.
Receipt handlers will only be triggered for the exact match of the named account. More flexibility may be added in the future.
This is not supported. We are evaluating whether this functionality is required for indexing.
This is not currently supported. We are evaluating whether this functionality is required for indexing.
Pending functionality is not yet supported for NEAR subgraphs. In the interim, you can deploy a new version to a different "named" subgraph, and then when that is synced with the chain head, you can redeploy to your primary "named" subgraph, which will use the same underlying deployment ID, so the main subgraph will be instantly synced.
schema.graphql: a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by .
AssemblyScript Mappings: that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
NEAR data sources introduce an optional source.account
field, which is a human-readable ID corresponding to a . This can be an account or a sub-account.
receiptHandlers
: run on every receipt where the data source's source.account
is the recipient. Note that only exact matches are processed ( must be added as independent data sources).
Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition .
The handlers for processing events are written in .
NEAR indexing introduces NEAR-specific data types to the .
Otherwise, the rest of the is available to NEAR subgraph developers during mapping execution.
This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new json.fromString(...)
function is available as part of the to allow developers to easily process these logs.
More information on creating and deploying subgraphs on the Hosted Service can be found .
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 : "Add Subgraph".
The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the for more information.
NEAR support is in beta, which means that there may be changes to the API as we continue to work on improving the integration. Please email so that we can support you in building NEAR subgraphs, and keep you up to date on the latest developments!
If it is a general question about subgraph development, there is a lot more information in the rest of the . Otherwise please join and ask in the #near channel or email .