graphprotocol · 0xa3k5 · Jul 10, 2025 · Jul 9, 2025 · Jul 9, 2025 · Jul 9, 2025
@@ -4,7 +4,7 @@ title: Advanced Subgraph Features
 
 ## Overview
 
-Add and implement advanced Subgraph features to enhanced your Subgraph's built.
+Add and implement advanced Subgraph features to enhance your Subgraph's build.
 
 Starting from `specVersion` `0.0.4`, Subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
 

@@ -270,7 +270,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 > Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
 
-#### Looking up entities created withing a block
+#### Looking up entities created within a block
 
 As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
 
@@ -496,7 +496,7 @@ export function handleTransfer(event: TransferEvent) {
 }
 ```
 
-`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type
+`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type.
 
 As long as the `ERC20Contract` on Ethereum has a public read-only function called `symbol`, it can be called with `.symbol()`. For public state variables a method with the same name is created automatically.
 

@@ -68,7 +68,7 @@ graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
 
 `dataSources` are key components of Subgraphs. They define the sources of data that the Subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
 
-Recent versions of the Graph CLI supports adding new `dataSources` to an existing Subgraph through the `graph add` command:
+Recent versions of the Graph CLI support adding new `dataSources` to an existing Subgraph through the `graph add` command:
 
 ```sh
 graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
@@ -83,7 +83,7 @@ Options:
 
 #### Specifics
 
-The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and create a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
 
 - The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
   - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.

@@ -62,7 +62,7 @@ Entity fields can be defined as required or optional. Required fields are indica
 Null value resolved for non-null field 'name'
 ```
 
-Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query than those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
 
 For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
 

@@ -93,7 +93,7 @@ The important entries to update for the manifest are:
 
 - `indexerHints.prune`: Defines the retention of historical block data for a Subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
 
-- `dataSources.source`: the address of the smart contract the Subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+- `dataSources.source`: the address of the smart contract the Subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows you to index matching events from all contracts.
 
 - `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
 
@@ -109,7 +109,7 @@ The important entries to update for the manifest are:
 
 - `dataSources.mapping.callHandlers`: lists the smart contract functions this Subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
 
-- `dataSources.mapping.blockHandlers`: lists the blocks this Subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+- `dataSources.mapping.blockHandlers`: lists the blocks this Subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run on every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
 
 A single Subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
 
@@ -153,7 +153,7 @@ While events provide an effective way to collect relevant changes to the state o
 
 Call handlers will only trigger in one of two cases: when the function specified is called by an account other than the contract itself or when it is marked as external in Solidity and called as part of another function in the same contract.
 
-> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a Subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, do not support this API. If a Subgraph indexing one of these networks contains one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
 
 ### Defining a Call Handler
 
@@ -218,7 +218,7 @@ filter:
 
 _The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
 
-> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a Subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+> **Note:** The `call` filter currently depends on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, do not support this API. If a Subgraph indexing one of these networks contains one or more block handlers with a `call` filter, it will not start syncing.
 
 The absence of a filter for a block handler will ensure that the handler is called every block. A data source can only contain one block handler for each filter type.
 

@@ -5,7 +5,7 @@ To address the need to support a distributed network, we plan to take several ac
 1. Compose multiple Subgraphs (on the client-side)
 2. Fallback to multiple indexers/sources/hosted services
 3. Automatic/Manual source picking strategy
-4. Agnostic core, with the ability to run integrate with any GraphQL client
+4. Agnostic core, with the ability to integrate with any GraphQL client
 
 ## Standalone mode
 
@@ -44,7 +44,7 @@ graph LR;
 
 ## Subgraph Execution Strategies
 
-Within every Subgraph defined as source, there will be a way to define it's source(s) indexer and the querying strategy, here are a few options:
+Within every Subgraph defined as source, there will be a way to define its source(s) indexer and the querying strategy, here are a few options:
 
 ```mermaid
 graph LR;
@@ -85,7 +85,7 @@ graph LR;
     end
 ```
 
-> We can ship a several built-in strategies, along with a simple interfaces to allow developers to write their own.
+> We can ship several built-in strategies, along with a simple interface to allow developers to write their own.
 
 To take the concept of strategies to the extreme, we can even build a magical layer that does subscription-as-query, with any hook, and provide a smooth DX for dapps:
 

@@ -38,6 +38,6 @@ query ExampleQuery @live(interval: 5000) {
 
 ## Integrations
 
-Since the entire network layer (along with the `@live` mechanism) is implemented inside `graph-client` core, you can use Live queries with every GraphQL client (such as Urql or Apollo-Client), as long as it supports streame responses (`AsyncIterable`).
+Since the entire network layer (along with the `@live` mechanism) is implemented inside `graph-client` core, you can use Live queries with every GraphQL client (such as Urql or Apollo-Client), as long as it supports streamed responses (`AsyncIterable`).
 
 No additional setup is required for GraphQL clients cache updates.