Fix typos

website/pages/en/cookbook/base-testnet.mdx

@@ -63,10 +63,10 @@ Your subgraph slug is an identifier for your subgraph. The CLI tool will walk yo
 The previous command creates a scaffold subgraph that you can use as a starting point for building your subgraph. When making changes to the subgraph, you will mainly work with three files:
 
 - Manifest (subgraph.yaml) - The manifest defines what datasources your subgraphs will index. Make sure to add `base-sepolia` as the network name in manifest file to deploy your subgraph on Base Sepolia.
-- Schema (schema.graphql) - The GraphQL schema defines what data you wish to retreive from the subgraph.
+- Schema (schema.graphql) - The GraphQL schema defines what data you wish to retrieve from the subgraph.
 - AssemblyScript Mappings (mapping.ts) - This is the code that translates data from your datasources to the entities defined in the schema.
 
-If you want to index additional data, you will need extend the manifest, schema and mappings.
+If you want to index additional data, you will need to extend the manifest, schema and mappings.
 
 For more information on how to write your subgraph, see [Creating a Subgraph](/developing/creating-a-subgraph).
 

website/pages/en/cookbook/grafting.mdx

@@ -22,7 +22,7 @@ For more information, you can check:
 
 - [Grafting](/developing/creating-a-subgraph#grafting-onto-existing-subgraphs)
 
-In this tutorial, we will be covering a basic usecase. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
 
 ## Important Note on Grafting When Upgrading to the Network
 
@@ -80,7 +80,7 @@ dataSources:
 ```
 
 - The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
-- The network should correspond to a indexed network being queried. Since we're running on Goerli testnet, the network is `goerli`
+- The network should correspond to an indexed network being queried. Since we're running on Goerli testnet, the network is `goerli`
 - The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
 
 ## Grafting Manifest Definition
@@ -191,7 +191,7 @@ Congrats! You have successfully grafted a subgraph onto another subgraph.
 
 ## Additional Resources
 
-If you want more experience with grafting, here's a few examples for popular contracts:
+If you want more experience with grafting, here are a few examples of popular contracts:
 
 - [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
 - [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)

website/pages/en/mips-faqs.mdx

@@ -8,7 +8,7 @@ title: MIPs FAQs
 
 It's an exciting time to be participating in The Graph ecosystem! During [Graph Day 2022](https://thegraph.com/graph-day/2022/) Yaniv Tal announced the [sunsetting of the hosted service](https://thegraph.com/blog/sunsetting-hosted-service/), a moment The Graph ecosystem has been working towards for many years.
 
-To support the sunsetting of the hosted service and the migration of all of it's activity to the decentralized network, The Graph Foundation has announced the [Migration Infrastructure Providers (MIPs) program](https://thegraph.com/blog/mips-multi-chain-indexing-incentivized-program).
+To support the sunsetting of the hosted service and the migration of all of its activity to the decentralized network, The Graph Foundation has announced the [Migration Infrastructure Providers (MIPs) program](https://thegraph.com/blog/mips-multi-chain-indexing-incentivized-program).
 
 The MIPs program is an incentivization program for Indexers to support them with resources to index chains beyond Ethereum mainnet and help The Graph protocol expand the decentralized network into a multi-chain infrastructure layer.
 

website/pages/en/network/indexing.mdx

@@ -545,7 +545,7 @@ The **Indexer CLI** connects to the Indexer agent, typically through port-forwar
 
 - `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
 
-- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additonal argument `--status` can be used to print out all actions of a certain status.
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
 
 - `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
 

website/pages/en/querying/graphql-api.mdx

@@ -121,7 +121,7 @@ The first time, it would send the query with `lastID = ""`, and for subsequent r
 
 ### Filtering
 
-You can use the `where` parameter in your queries to filter for different properties. You can filter on mulltiple values within the `where` parameter.
+You can use the `where` parameter in your queries to filter for different properties. You can filter on multiple values within the `where` parameter.
 
 #### Example using `where`
 
@@ -280,7 +280,7 @@ You can query the state of your entities not just for the latest block, which is
 
 The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to not be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
 
-Note that the current implementation is still subject to certain limitations that might violate these gurantees. The implementation can not always tell that a given block hash is not on the main chain at all, or that the result of a query by block hash for a block that can not be considered final yet might be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+Note that the current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or that the result of a query by block hash for a block that can not be considered final yet might be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
 
 #### Example