[Chore] Rename all on-chain/off-chain to onchain/offchain

.env.dev

@@ -16,7 +16,7 @@ GROVE_PORTAL_STAGING_ETH_MAINNET=https://eth-mainnet.rpc.grove.town
 # The "protocol" field here instructs the Grove gateway which network to use
 JSON_RPC_DATA_ETH_BLOCK_HEIGHT='{"protocol": "shannon-testnet","jsonrpc":"2.0","id":"0","method":"eth_blockNumber", "params": []}'
 
-# On-chain module account addresses. Search for `func TestModuleAddress` in the
+# Onchain module account addresses. Search for `func TestModuleAddress` in the
 # codebase to get an understanding of how we got these values.
 APPLICATION_MODULE_ADDRESS=pokt1rl3gjgzexmplmds3tq3r3yk84zlwdl6djzgsvm
 SUPPLIER_MODULE_ADDRESS=pokt1j40dzzmn6cn9kxku7a5tjnud6hv37vesr5ccaa

.github/workflows/reviewdog.yml

@@ -67,7 +67,7 @@ jobs:
   # Ensure that we are using polylog (via logger.) instead of the golang's stdlib
   # log package.
   check_stdlog_in_off_chain_package:
-    name: Check stdlog in off-chain source code
+    name: Check stdlog in offchain source code
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4

Makefile

@@ -14,7 +14,7 @@ GROVE_PORTAL_STAGING_ETH_MAINNET = https://eth-mainnet.rpc.grove.town
 # JSON RPC data for a test relay request
 JSON_RPC_DATA_ETH_BLOCK_HEIGHT = '{"jsonrpc":"2.0","id":"0","method":"eth_blockNumber", "params": []}'
 
-# On-chain module account addresses. Search for `func TestModuleAddress` in the
+# Onchain module account addresses. Search for `func TestModuleAddress` in the
 # codebase to get an understanding of how we got these values.
 APPLICATION_MODULE_ADDRESS = pokt1rl3gjgzexmplmds3tq3r3yk84zlwdl6djzgsvm
 SUPPLIER_MODULE_ADDRESS = pokt1j40dzzmn6cn9kxku7a5tjnud6hv37vesr5ccaa

app/upgrades.go

@@ -27,7 +27,7 @@ func (app *App) setUpgrades() error {
 	}
 
 	// Reads the upgrade info from disk.
-	// The previous binary is expected to have read the plan from on-chain and saved it locally.
+	// The previous binary is expected to have read the plan from onchain and saved it locally.
 	upgradePlan, err := app.Keepers.UpgradeKeeper.ReadUpgradeInfoFromDisk()
 	if err != nil {
 		return err

app/upgrades/types.go

@@ -21,10 +21,10 @@ const (
 )
 
 // Upgrade represents a protocol upgrade in code.
-// Once a `MsgSoftwareUpgrade` is submitted on-chain, and `Upgrade.PlanName` matches the `Plan.Name`,
+// Once a `MsgSoftwareUpgrade` is submitted onchain, and `Upgrade.PlanName` matches the `Plan.Name`,
 // the upgrade will be scheduled for execution at the corresponding height.
 type Upgrade struct {
-	// PlanName is a name an upgrade is matched to from the on-chain `upgradetypes.Plan`.
+	// PlanName is a name an upgrade is matched to from the onchain `upgradetypes.Plan`.
 	PlanName string
 
 	// CreateUpgradeHandler returns an upgrade handler that will be executed at the time of the upgrade.

docusaurus/docs/develop/developer_guide/adding_params.md

@@ -1,9 +1,9 @@
 ---
 sidebar_position: 5
-title: Adding On-Chain Module Parameters
+title: Adding Onchain Module Parameters
 ---
 
-# Adding On-Chain Module Parameters <!-- omit in toc -->
+# Adding Onchain Module Parameters <!-- omit in toc -->
 
 - [Step-by-Step Instructions](#step-by-step-instructions)
   - [0. If the Module Doesn't Already Support a `MsgUpdateParam` Message](#0-if-the-module-doesnt-already-support-a-msgupdateparam-message)
@@ -37,7 +37,7 @@ title: Adding On-Chain Module Parameters
     - [7.2 Create a new JSON File for the Individual Parameter Update](#72-create-a-new-json-file-for-the-individual-parameter-update)
     - [7.3 Update the JSON File for Updating All Parameters for the Module](#73-update-the-json-file-for-updating-all-parameters-for-the-module)
 
-Adding a new on-chain module parameter involves multiple steps to ensure that the
+Adding a new onchain module parameter involves multiple steps to ensure that the
 parameter is properly integrated into the system. This guide will walk you through
 the process using a generic approach, illustrated by adding a parameter to the `proof` module.
 

docusaurus/docs/develop/developer_guide/quickstart.md

@@ -105,7 +105,7 @@ This section will help you deploy a POKT LocalNet in a k8s cluster on your machi
 and inspect it so you have an idea of what's going on!
 
 We'll be manually configuring a few actors to run in your shell for the sake of
-the tutorial so you have visibility into the types of on-chain and off-chain
+the tutorial so you have visibility into the types of onchain and offchain
 actors. In practice, you should be using [localnet](../../operate/infrastructure/localnet.md)
 to dynamically scale your actors.
 
@@ -339,8 +339,8 @@ make acc_balance_query ACC=$SHANNON_APPLICATION
 
 ## 3. Manually Stake a Supplier & Deploy a RelayMiner
 
-As we mentioned earlier, if you want to understand the different on-chain actors
-and off-chain operators in POKT Network, look at the docs [here](../../protocol/actors/actors.md).
+As we mentioned earlier, if you want to understand the different onchain actors
+and offchain operators in POKT Network, look at the docs [here](../../protocol/actors/actors.md).
 
 If you just want to follow instructions to make things work and get your hands
 dirty, keep reading.
@@ -404,7 +404,7 @@ EOF
 
 ### 3.4 Stake the new Supplier
 
-Stake the `shannon_supplier` on-chain:
+Stake the `shannon_supplier` onchain:
 
 ```bash
 poktrolld \
@@ -511,7 +511,7 @@ EOF
 
 ### 4.3 Stake the new Application
 
-Stake the application on-chain:
+Stake the application onchain:
 
 ```bash
 poktrolld --home=./localnet/poktrolld \
@@ -548,7 +548,7 @@ You must run `make acc_initialize_pubkeys` before sending a relay in order for
 the public keys to be initialized correctly.
 
 See the [x/auth](https://docs.cosmos.network/main/build/modules/auth) for more
-information on how public keys are stored and accessible on-chain.
+information on how public keys are stored and accessible onchain.
 
 :::
 
@@ -578,8 +578,8 @@ The Relay Request/Response from is captured in the sequence diagram below.
 sequenceDiagram
   actor U as User <br> (curl Client)
 
-  participant PG as PATH Gateway<br> (off-chain Application Operator)
-  participant RM as RelayMiner <br> (off-chain Supplier Operator)
+  participant PG as PATH Gateway<br> (offchain Application Operator)
+  participant RM as RelayMiner <br> (offchain Supplier Operator)
   participant anvil as ETH Node <br> (Anvil)
 
   U ->> +PG: eth_blockNumber <br> (JSON-RPC Request)
@@ -600,8 +600,8 @@ provide some intuition:
 sequenceDiagram
   participant RM as RelayMiner <br> (Supplier Operator)
   participant P as Pocket Node
-  actor A as Application <br> (on-chain Record)
-  actor S as Supplier <br> (on-chain Record)
+  actor A as Application <br> (onchain Record)
+  actor S as Supplier <br> (onchain Record)
 
   RM -->> P: CreateClaim <br> (Relays Served)
   RM -->> P: SubmitProof <br> (Proof of Work)

docusaurus/docs/develop/developer_guide/testing/integration_suites.md

@@ -35,7 +35,7 @@ The `testutil/integration/suites` package contains multiple **app integration su
 
 ### Example (`ParamsSuite`)
 
-The following example shows a test suite which embeds `suites.ParamsSuite`, in order to set on-chain module params as part of its `SetupTest()` method:
+The following example shows a test suite which embeds `suites.ParamsSuite`, in order to set onchain module params as part of its `SetupTest()` method:
 
 ```go
 package suites

docusaurus/docs/develop/developer_guide/testing/testing_levels.md

@@ -123,7 +123,7 @@ This level of testing ensures that the appchain behaves as expected in a multi-v
 
 ## [End-to-End Tests](e2e)
 
-**End-to-end tests** focus on testing the behavior of a network containing both on- and off-chain actors; typically exercising "localnet".
+**End-to-end tests** focus on testing the behavior of a network containing both on- and offchain actors; typically exercising "localnet".
 
 ### E2E Test Example
 
@@ -133,9 +133,9 @@ This level of testing ensures that the appchain behaves as expected in a multi-v
 
 ### E2E Test - Good Fit
 
-- Asserts or dependent on off-chain assertions
-- Asserts or dependent on off-chain actors
-- Asserts or dependent on off-chain behavior
+- Asserts or dependent on offchain assertions
+- Asserts or dependent on offchain actors
+- Asserts or dependent on offchain behavior
 
 ### E2E Test - Bad Fit
 
@@ -147,6 +147,6 @@ This level of testing ensures that the appchain behaves as expected in a multi-v
 
 - Depends on LocalNet to be running and healthy
 - Depends on other environments (DevNet/TestNet) to be running and healthy
-- Shared mutable network state on-chain
-- Shared mutable network state off-chain
+- Shared mutable network state onchain
+- Shared mutable network state offchain
 - Intolerant of non-idempotent operations (CI re-runnability).