Onchain Language (#834)

Onchain change

website/pages/en/cookbook/cosmos.mdx

@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## What are Cosmos subgraphs?
 
-The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index on-chain events.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 There are four types of handlers supported in Cosmos subgraphs:
 

website/pages/en/cookbook/immutable-entities-bytes-as-ids.mdx

@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

website/pages/en/cookbook/near.mdx

@@ -12,7 +12,7 @@ This guide is an introduction to building subgraphs indexing smart contracts on
 
 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. [Graph Node](https://github.com/graphprotocol/graph-node) 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:
+Subgraphs are event-based, which means that they listen for and then process onchain 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

website/pages/en/cookbook/transfer-to-the-graph.mdx

@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

website/pages/en/deploying/deploy-using-subgraph-studio.mdx

@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

website/pages/en/developing/creating-a-subgraph/subgraph-manifest.mdx

@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Data Source for the Main Contract
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

website/pages/en/developing/graph-ts/api.mdx

@@ -274,7 +274,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 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.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -666,7 +666,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Smart contracts occasionally anchor IPFS files on chain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 Given an IPFS hash or path, reading a file from IPFS is done as follows:
 

website/pages/en/developing/substreams-powered-subgraphs-faq.mdx

@@ -16,9 +16,9 @@ If you are already familiar with subgraph development, then note that Substreams
 
 ## How are Substreams-powered subgraphs different from subgraphs?
 
-Subgraphs are made up of datasources which specify on-chain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen on-chain.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular on-chain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## What are the benefits of using Substreams-powered subgraphs?
 

website/pages/en/glossary.mdx

@@ -42,7 +42,7 @@ title: Glossary
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Active**: An allocation is considered active when it is created on-chain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Glossary
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
 

website/pages/en/network/curating.mdx

@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. What’s the cost of updating a subgraph?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. How often can I update my subgraph?
 

website/pages/en/network/indexing.mdx

@@ -137,7 +137,7 @@ At the center of an Indexer's infrastructure is the Graph Node which monitors th
 
 - **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
 
-- **Indexer agent** - Facilitates the Indexers interactions on chain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
 
-- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards on chain and how much is allocated towards each.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
 
-The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed on-chain. The general flow will look like:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Action added to the queue by the 3rd party optimizer tool or indexer-cli user
 - Indexer can use the `indexer-cli` to view all queued actions
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation on-chain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

website/pages/en/subgraphs.mdx

@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

website/pages/en/tap.mdx

@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.