Update all instances of on-chain to onchain (#799)

components/Starknet/modules/architecture_and_concepts/pages/Accounts/introduction.adoc

@@ -1,9 +1,9 @@
 [id="what_is_an_account"]
 = What is an account?
 
-An account represents a user on-chain, and enables that user to interact with the blockchain.
+An account represents a user onchain, and enables that user to interact with the blockchain.
 
-Through an account, you may send transactions and interact with other contracts. To "own" an on-chain asset (e.g. ERC20 token or an NFT), it has to be associated with your account address.
+Through an account, you may send transactions and interact with other contracts. To "own" an onchain asset (e.g. ERC20 token or an NFT), it has to be associated with your account address.
 
 [id="ethereum_account_structure"]
 == Ethereum account structure

components/Starknet/modules/architecture_and_concepts/pages/Network_Architecture/fee-mechanism.adoc

@@ -94,9 +94,9 @@ The weights are:
 
 
 [id="_on_chain_data"]
-=== On-chain data
+=== Onchain data
 
-The on-chain data associated with a transaction is composed of three parts
+The onchain data associated with a transaction is composed of three parts
 
 * Storage updates
 * L2→L1 messages

components/Starknet/modules/architecture_and_concepts/pages/Network_Architecture/on-chain-data.adoc

@@ -4,7 +4,7 @@
 [id="introduction"]
 == Introduction
 
-In the current stage of the Alpha, Starknet operates in a ZK-Rollup mode. This means that upon the acceptance of a state update on-chain, the state diff between the previous and new state is sent as calldata to Ethereum.
+In the current stage of the Alpha, Starknet operates in a ZK-Rollup mode. This means that upon the acceptance of a state update onchain, the state diff between the previous and new state is sent as calldata to Ethereum.
 
 This data allows anyone that observes Ethereum to reconstruct the current state of Starknet.
 

components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/system-calls-cairo1.adoc

@@ -376,7 +376,7 @@ For information on accessing storage by using the storage variables, see xref:./
 ==== Arguments
 
 [horizontal,labelwidth=35]
-`_address_domain_`:: The domain of the key, used to separate between different data availability modes. This separation is used in Starknet to offer different data availability modes. Currently, only the on-chain mode (where all updates go to L1), indicated by domain `0`, is supported. Other address domains which will be introduced in the future will behave differently in terms of publication (in particular, they will not be posted on L1, creating a tradeoff between cost and security).
+`_address_domain_`:: The domain of the key, used to separate between different data availability modes. This separation is used in Starknet to offer different data availability modes. Currently, only the onchain mode (where all updates go to L1), indicated by domain `0`, is supported. Other address domains which will be introduced in the future will behave differently in terms of publication (in particular, they will not be posted on L1, creating a tradeoff between cost and security).
 `_address_`:: The requested storage address.
 
 [discrete]
@@ -428,7 +428,7 @@ For information on accessing storage by using the storage variables, see xref:./
 ==== Arguments
 
 [horizontal,labelwidth=35]
-`_address_domain_`:: The domain of the key, used to separate between different data availability modes. This separation is used in Starknet to offer different data availability modes. Currently, only the on-chain mode (where all updates go to L1), indicated by domain `0`, is supported. Other address domains which will be introduced in the future will behave differently in terms of publication (in particular, they will not be posted on L1, creating a tradeoff between cost and security).
+`_address_domain_`:: The domain of the key, used to separate between different data availability modes. This separation is used in Starknet to offer different data availability modes. Currently, only the onchain mode (where all updates go to L1), indicated by domain `0`, is supported. Other address domains which will be introduced in the future will behave differently in terms of publication (in particular, they will not be posted on L1, creating a tradeoff between cost and security).
 `_address_`:: The requested storage address.
 `_value_`:: The value to write to the key.
 

components/Starknet/modules/quick_start/pages/account_setup.adoc

@@ -87,7 +87,7 @@ Press [ENTER] once youve funded the address.
 You have now successfully deployed a new account to Starknet.
 
 == Fetching an account
-Account fetching allows you to recreate the account file from on-chain data alone.
+Account fetching allows you to recreate the account file from onchain data alone.
 
 This could be helpful when:
 

components/Starknet/modules/quick_start/pages/setting_up_a_smart_wallet.adoc

@@ -90,7 +90,7 @@ While knowing the private key of a smart wallet is necessary to sign transaction
 
 == Creating an Account Descriptor
 
-Starkli offers a command to collect all the required information from a smart wallet by providing its on-chain address. Using this data, the CLI generates a json file that can be used to sign transactions:
+Starkli offers a command to collect all the required information from a smart wallet by providing its onchain address. Using this data, the CLI generates a json file that can be used to sign transactions:
 
 [source,shell]
 ----

components/Starknet/modules/starknet_versions/pages/version_notes.adoc

@@ -105,7 +105,7 @@ The introduction of Cairo 1.0 and Sierra has several effects on the system. Belo
 
 * A new version of the `declare` transaction, which allows sending the new class structure
 * The state commitment will now include contract classes
-* Changes to the on-chain data format
+* Changes to the onchain data format
 * New system call - `replace_class`