Fix typos

docs/indexer/build/dynamicdatasources.md

@@ -88,7 +88,7 @@ async function handleNewTradingPair(event: MoonbeamEvent): Promise<void> {
 }
 
 async function handleLiquidityAdded(event: MoonbeamEvent): Promise<void> {
-  /* mapping fuction implementation here */
+  /* mapping function implementation here */
 }
 ```
 

docs/indexer/build/graph-migration.md

@@ -31,7 +31,7 @@ Reach out to our team at [professionalservices@subquery.network](mailto:professi
 
 ### Recommended Migration Steps
 
-This is the recommended proccess that we use at SubQuery whenever we migrate projects from a SubGraph to SubQuery:
+This is the recommended process that we use at SubQuery whenever we migrate projects from a SubGraph to SubQuery:
 
 1. [Initialise a new SubQuery project](./introduction.md) for the same network using the `subql init` command. When migrating an existing SubGraph, it's not necessary to perform code scaffolding. It also ensures that you are using TS `strict` mode, which will help you identify any potential bugs.
 2. Copy over your `schema.graphql` and replace any `Bytes` and `BigDecimals`. [More info](#graphql-schema).
@@ -41,7 +41,7 @@ This is the recommended proccess that we use at SubQuery whenever we migrate pro
 6. Copy over the `mappings` directory, and then go through one by one to migrate them across. The key differences:
    - Imports will need to be updated
    - Store operations are asynchronous, e.g. `<entityName>.load(id)` should be replaced by `await <entityName>.get(id)` and `<entityName>.save()` to `await <entityName>.save()` (note the `await`).
-   - With strict mode, you must construct new entites with all the required properties. You may want to replace `new <entityName>(id)` with `<entityName>.create({ ... })`
+   - With strict mode, you must construct new entities with all the required properties. You may want to replace `new <entityName>(id)` with `<entityName>.create({ ... })`
    - [More info](#mapping).
 7. Test and update your clients to follow the GraphQL api differences and take advantage of additional features. [More info](#graphql-query-differences)
 
@@ -231,7 +231,7 @@ dataSources:
 
 The `codegen` command is also intentionally similar between SubQuery and SubGraphs
 
-All GraphQL entities will have generated entity classes that provide type-safe entity loading, read and write access to entity fields - see more about this process in [the GraphQL Schema](../build/graphql.md). All entites can be imported from the following directory:
+All GraphQL entities will have generated entity classes that provide type-safe entity loading, read and write access to entity fields - see more about this process in [the GraphQL Schema](../build/graphql.md). All entities can be imported from the following directory:
 
 ```ts
 import { Gravatar } from "../types";

docs/indexer/build/graphql.md

@@ -9,7 +9,7 @@ The `schema.graphql` file outlines the various GraphQL schemas. The structure of
 3. [Entity Relationships](#entity-relationships): An entity often has nested relationships with other entities. Setting the field value to another entity name will define a relationship between these two entities.
 4. [Indexing](#indexing-by-non-primary-key-field): Enhance query performance by implementing the @index annotation on a non-primary-key field.
 
-Here's an example of what your GraphQL Here is an example of a schema which implements all of these recomendations, as well a relationship of many-to-many:
+Here's an example of what your GraphQL Here is an example of a schema which implements all of these recommendations, as well a relationship of many-to-many:
 
 ::: tip
 
@@ -104,7 +104,7 @@ We currently support the following scalar types:
 - `Boolean`
 - `<EntityName>` for nested relationship entities, you might use the defined entity's name as one of the fields. Please see in [Entity Relationships](graphql.md#entity-relationships).
 - `JSON` can alternatively store structured data, please see [JSON type](graphql.md#json-type)
-- `<EnumName>` types are a special kind of enumerated scalar that is restricted to a particular set of allowed values. Please see [Graphql Enum](https://graphql.org/learn/schema/#enumeration-types)
+- `<EnumName>` types are a special kind of enumerated scalar that is restricted to a particular set of allowed values. Please see [GraphQL Enum](https://graphql.org/learn/schema/#enumeration-types)
 
 ### Naming Constraints
 
@@ -205,7 +205,7 @@ Composite indexes work just like regular indexes, except they provide even faste
 
 For example, a composite index on columns `col_a` and `col_b` will significantly help when there are queries that filter across both (e.g. `WHERE col_a=x AND col_b=y`).
 
-You can create composite indexes though the `@compositeIndexes` annotation on an entity, and you can specify as many as you want.
+You can create composite indexes through the `@compositeIndexes` annotation on an entity, and you can specify as many as you want.
 
 ```graphql
 type Account @entity {
@@ -430,7 +430,7 @@ type User @entity {
 
 ### JSON field indexes
 
-By default we automatically add indexes to JSON fields to improve querying performance. This can be disabled by specifying the `indexed: false` argument on the `jsonField` directive like so. This is useful if you are using alternative databases like Cockroach DB, as there can be some perfomance issues with inserting JSON data with an index (Cockroach does not support gin index and Jsonb data).
+By default we automatically add indexes to JSON fields to improve querying performance. This can be disabled by specifying the `indexed: false` argument on the `jsonField` directive like so. This is useful if you are using alternative databases like Cockroach DB, as there can be some performance issues with inserting JSON data with an index (Cockroach does not support gin index and Jsonb data).
 
 ```graphql
 type AddressDetail @jsonField(indexed: false) {
@@ -446,7 +446,7 @@ The drawback of using JSON types is a slight impact on query efficiency when fil
 However, the impact is still acceptable in our query service. Here is an example of how to use the `contains` operator in the GraphQL query on a JSON field to find the first 5 users who own a phone number that contains '0064'.
 
 ```graphql
-#To find the the first 5 users own phone numbers contains '0064'.
+#To find the first 5 users own phone numbers contains '0064'.
 
 query {
   user(first: 5, filter: { contactCard: { contains: [{ phone: "0064" }] } }) {

docs/indexer/build/introduction.md

@@ -44,9 +44,9 @@ Scaffolding saves time during SubQuery project creation by automatically generat
 
 ### When Initialising New SubQuery Projects
 
-When you are initalising a new project using the `subql init` command, SubQuery will give you the option to set up a scaffolded SubQuery project based on your JSON ABI.
+When you are initialising a new project using the `subql init` command, SubQuery will give you the option to set up a scaffolded SubQuery project based on your JSON ABI.
 
-If you have select an compatiable network type (EVM), it will prompt
+If you have select an compatible network type (EVM), it will prompt
 
 ```shell
 ? Do you want to generate scaffolding with an existing abi contract?
@@ -66,7 +66,7 @@ You will then be prompted to select what `events` and/or `functions` that you wa
 
 ### For an Existing SubQuery Project
 
-You can also generate additional scaffolded code new new contracts and append this code to your existing `project.ts`. This is done using the `subql codegen:generate` command from within your project workspace.
+You can also generate additional scaffolded code new contracts and append this code to your existing `project.ts`. This is done using the `subql codegen:generate` command from within your project workspace.
 
 ```shell
 subql codegen:generate \
@@ -146,13 +146,13 @@ import {
 } from "../types/abi-interfaces/Gravity";
 
 export async function handleNewGravatarGravityLog(
-  log: NewGravatarLog,
+  log: NewGravatarLog
 ): Promise<void> {
   // Place your code logic here
 }
 
 export async function handleUpdatedGravatarGravityLog(
-  log: UpdatedGravatarLog,
+  log: UpdatedGravatarLog
 ): Promise<void> {
   // Place your code logic here
 }
@@ -268,7 +268,7 @@ The `schema.graphql` file outlines the various GraphQL schemas. The structure of
 3. [Entity Relationships](./graphql.md#entity-relationships): An entity often has nested relationships with other entities. Setting the field value to another entity name will define a relationship between these two entities.
 4. [Indexing](./graphql.md#indexing-by-non-primary-key-field): Enhance query performance by implementing the @index annotation on a non-primary-key field.
 
-Here's an example of what your GraphQL Here is an example of a schema which implements all of these recomendations, as well a relationship of many-to-many:
+Here's an example of what your GraphQL Here is an example of a schema which implements all of these recommendations, as well a relationship of many-to-many:
 
 ::: tip
 
@@ -332,7 +332,7 @@ npm run-script codegen
 
 :::
 
-This will create a new directory (or update the existing) `src/types` which contain generated entity classes for each type you have defined previously in `schema.graphql`. These classes provide type-safe entity loading, read and write access to entity fields - see more about this process in [the GraphQL Schema](../build/graphql.md). All entites can be imported from the following directory:
+This will create a new directory (or update the existing) `src/types` which contain generated entity classes for each type you have defined previously in `schema.graphql`. These classes provide type-safe entity loading, read and write access to entity fields - see more about this process in [the GraphQL Schema](../build/graphql.md). All entities can be imported from the following directory:
 
 ```ts
 import { GraphQLEntity1, GraphQLEntity2 } from "../types";
@@ -342,7 +342,7 @@ import { GraphQLEntity1, GraphQLEntity2 } from "../types";
 
 If you're creating a new Ethereum based project (including Ethereum EVM, Cosmos Ethermint, Avalanche, and Substrate's Frontier EVM & Acala EVM+), the `codegen` command will also generate types and save them into `src/types` using the `npx typechain --target=ethers-v5` command, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed.
 
-It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `src/typs/abi-interfaces` and `src/typs/contracts` directories.
+It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `src/types/abi-interfaces` and `src/types/contracts` directories.
 
 In the example [Gravatar SubQuery project](../quickstart/quickstart_chains/ethereum-gravatar.md), you would import these types like so.
 
@@ -354,7 +354,7 @@ import { GraphQLEntity1, GraphQLEntity2 } from "../types";
 
 Codegen will also generate wrapper types for Cosmos Protobufs, the `codegen` command will also generate types and save them into `src/types` directory, providing you with more typesafety specifically for Cosmos Message Handers.
 
-It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to the `src/typs/proto-interfaces` directory.
+It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to the `src/types/proto-interfaces` directory.
 
 **Note**: The protobuf types you wish to generate must be kept in the `proto` directory (at the root of your project) and you must also ensure the structure of the protobufs are in accordance with the provided protobuf. For example `osmosis.gamm.v1beta1` would have the file structure of `<project-root>/proto/osmosis/gamm/v1beta1/<file>.proto`
 
@@ -390,14 +390,14 @@ Once `codegen` is executed you will find the message types under `src/types/Cosm
 }
 ```
 
-If you are uncertain of the available messages, you can always check the generated proto interfaces udner `src/types/proto-interfaces/`. You import them into your message handlers like so:
+If you are uncertain of the available messages, you can always check the generated proto interfaces under `src/types/proto-interfaces/`. You import them into your message handlers like so:
 
 ```ts
 import { CosmosMessage } from "@subql/types-cosmos";
 import { MsgSwapExactAmountIn } from "../types/proto-interfaces/osmosis/gamm/v1beta1/tx";
 
 export async function handleMessage(
-  msg: CosmosMessage<MsgSwapExactAmountIn>,
+  msg: CosmosMessage<MsgSwapExactAmountIn>
 ): Promise<void> {
   // Do something with typed event
   const messagePayload: MsgSwapExactAmountIn = msg.msg.decodedMsg;
@@ -426,7 +426,7 @@ Similar to Ethereum ABI codegen, you will need to include the path and name for
 }
 ```
 
-All generated files could be found under `src/typs/cosmwasm-interfaces` and `src/typs/cosmwasm-interface-wrappers` directories.
+All generated files could be found under `src/types/cosmwasm-interfaces` and `src/types/cosmwasm-interface-wrappers` directories.
 
 **Note**: For contract ABIs you wish to generate, you must ensure that each ABI is in its own directory. For example `<project-root>/abis/baseMinter/base-minter.json` and `<project-root>/abis/cw20/cw20.json`.
 

docs/indexer/build/multi-chain.md

@@ -47,7 +47,7 @@ This feature is not compatible with [Historical State](../run_publish/historical
 This feature is only supported for Partner Plan Customers in the [SubQuery Managed Service](https://managedservice.subquery.network). All others can run this locally in their own infrastructure provider.
 :::
 
-## Intialising and creating a multi-chain project
+## Initialising and creating a multi-chain project
 
 Creating a multi-chain project involves several steps that enable you to index multiple networks into a single database. This is achieved by configuring a multi-chain manifest file, generating required entities and datasource templates, adding new projects to the manifest, and publishing the multi-chain project.
 

docs/indexer/build/optimisation.md

@@ -90,7 +90,7 @@ There is more information focussed on the DevOps and configuration of [running h
 
 ## Review Project Architecture
 
-If your project requires indexing all the blocks, transactions alongside more specific data, consider dividing it into separate SubQuery projects responsible for different data sources. If such separation is possible it can provide better development experience and efficient workflow. This decision can be compared to a design decision between microservices and monolith project architecture.
+If your project requires indexing all the blocks, transactions alongside more specific data, consider dividing it into separate SubQuery projects responsible for different data sources. If such separation is possible it can provide better development experience and efficient workflow. This decision can be compared to a design decision between micro-services and monolith project architecture.
 
 We recommend this approach, because it takes time to index all the blocks and it can slow down your project significantly. If you want to apply some changes to your filters or entities shape you may need to remove your database and reindex the whole project from the beginning.
 

docs/indexer/build/project-upgrades.md

@@ -5,7 +5,7 @@ Project upgrades allow you to safely make changes to your project at a specified
 - Perform upgrades to your project at a specific height
 - Change the GraphQL/database schema
 - Support changes or new deployments to smart contracts
-- When you find a bug, but want to maintain previous data for backwards compatiability
+- When you find a bug, but want to maintain previous data for backwards compatibility
 
 It's particularly useful when you want to maintain the data of the previous project (e.g. when the previous project takes a long time to index from scratch), and you only want to add a new feature from a specific point in time.
 
@@ -49,7 +49,7 @@ Schema migrations allow you to make updates to your GraphQL schema, and the data
 When a project upgrade is executed with valid schema migrations, it will compare your current schema with the schema provided in the latest version (the one you are upgrading too), and attempt to make non-destructive changes your database.
 
 ::: warning
-If you re-run a previous version of you project accidentally, SubQuery will attempt to downgrade changes to your schema.
+If you re-run a previous version of your project accidentally, SubQuery will attempt to downgrade changes to your schema.
 :::
 
 ### Schema Migration Requirements

docs/indexer/build/substrate-evm.md

@@ -146,7 +146,7 @@ There are a couple of improvements from basic log filters:
 
 ### Codegen
 
-If you're creating a new Substrate Frontier EVM or Acala EVM+ based project, the normal [codegen](./introduction.md#code-generation) command will also generate ABI types and save them into `src/types` using the `npx typechain --target=ethers-v5` command, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `src/typs/**.ts`. In the example [Moonriver EVM Starter SubQuery project](https://github.com/subquery/subql-starter/tree/main/Moonriver/moonriver-evm-starter), you would import these types like so.
+If you're creating a new Substrate Frontier EVM or Acala EVM+ based project, the normal [codegen](./introduction.md#code-generation) command will also generate ABI types and save them into `src/types` using the `npx typechain --target=ethers-v5` command, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `src/types/**.ts`. In the example [Moonriver EVM Starter SubQuery project](https://github.com/subquery/subql-starter/tree/main/Moonriver/moonriver-evm-starter), you would import these types like so.
 
 ```ts
 import { GraphQLEntity1, GraphQLEntity2 } from "../types";
@@ -183,7 +183,7 @@ type ApproveCallArgs = [string, BigNumber] & {
 };
 
 export async function handleFrontierEvmEvent(
-  event: FrontierEvmEvent<TransferEventArgs>,
+  event: FrontierEvmEvent<TransferEventArgs>
 ): Promise<void> {
   const transaction = new Transaction(event.transactionHash);
 
@@ -196,7 +196,7 @@ export async function handleFrontierEvmEvent(
 }
 
 export async function handleFrontierEvmCall(
-  event: FrontierEvmCall<ApproveCallArgs>,
+  event: FrontierEvmCall<ApproveCallArgs>
 ): Promise<void> {
   const approval = new Approval(event.hash);
 
@@ -228,7 +228,7 @@ type ApproveCallArgs = [string, BigNumber] & {
 };
 
 export async function handleAcalaEvmEvent(
-  event: AcalaEvmEvent<TransferEventArgs>,
+  event: AcalaEvmEvent<TransferEventArgs>
 ): Promise<void> {
   const transaction = new Transaction(event.transactionHash);
 
@@ -241,7 +241,7 @@ export async function handleAcalaEvmEvent(
 }
 
 export async function handleAcalaEvmCall(
-  event: AcalaEvmCall<ApproveCallArgs>,
+  event: AcalaEvmCall<ApproveCallArgs>
 ): Promise<void> {
   const approval = new Approval(event.hash);