Fix: several typos in the documentation

components/Starknet/modules/architecture_and_concepts/pages/Cryptography/hash-functions.adoc

@@ -52,7 +52,7 @@ For more information, see xref:Cryptography/stark-curve.adoc[STARK curve].
 [id="poseidon_hash"]
 == Poseidon hash
 
-_Poseidon_ is a family of hash functions designed to be very efficient as algebraic circuits. As such, they may be very useful in ZK-proving systems such as STARKs.
+_Poseidon_ is a family of hash functions designed to be very efficient as algebraic circuits. As such, they can be very useful in ZK-proving systems such as STARKs.
 
 Poseidon is a sponge construction based on the Hades permutation. Starknet's version of Poseidon is based on a three-element state permutation.
 

components/Starknet/modules/architecture_and_concepts/pages/Network_Architecture/starknet-state.adoc

@@ -112,7 +112,7 @@ stem:[$path$] is an integer in stem:[$[0, 2^{length}-1\]$], and the binary expan
 The reason that length is specified and cannot be deduced from stem:[$path$] is that we're
 dealing with field elements of fixed size (251 bits each).
 
-For a node with stem:[$length>0$], following stem:[$path$] leads the highest node whose both right and left child are none empty.
+For a node with stem:[$length>0$], the following stem:[$path$] leads the highest node whose both right and left child are none empty.
 ====
 
 The following rules specify how the tree is constructed from a given set of leaves:

components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/cairo-and-sierra.adoc

@@ -31,7 +31,7 @@ we need to consider more components in the system, and the limitations of Cairo.
 
 === Reverted transactions, unsatisfiable AIRs, and DOS attacks
 
-A crucial property of every decentralized L2 is that the sequencers are guaranteed to be compensated for work they do.
+A crucial property of every decentralized L2 is that the sequencers are guaranteed to be compensated for the work they do.
 The notion of reverted transactions is a good example: even if the user's transaction failed mid execution, the sequencer should be able to include it in a block and charge execution fees up to the point of failure.
 
 If the sequencer cannot charge for such transactions, then sending transactions that will eventually fail (after a lot of computation steps) is an obvious DOS attack on the sequencer.

components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-abi.adoc

@@ -373,7 +373,7 @@ For example:
 
 * It is no longer enforced that the `Event` enum variants are structs of the same name as the variant, they can now be a struct or an enum of any name.
 * Enum variants inside event ABI entries (entries in the abi with `"type": "event"` and `"kind": "enum"`) now have two possible kinds. Before `v2.3.0` it was always `"kind": "nested"`, now `"kind: "flat"` is also possible.
-* `v2.3.0` is backwards compatible with version ≥ `2.0.0` ABI, so the same structure of the ABI is kept, while allowing flexibility.
+* `v2.3.0` is backward compatible with version ≥ `2.0.0` ABI, so the same structure of the ABI is kept, while allowing flexibility.
 
 [NOTE]
 ====
@@ -386,7 +386,7 @@ With `v2.3.0` onwards, doing so may result in losing information.
 To illustrate this, consider the following example:
 
 ```rust
-// high level code defining the events
+//high-level code defining the events
 
 #[event]
 #[derive(Drop, starknet::Event)]
@@ -470,7 +470,7 @@ When the contract emits the `TestCounterIncreased` event, for example by writing
 
 * One key based on the variant name: `sn_keccak(TestCounterIncreased)`. This information only appears in the `<namespace>::Event` type entry in the ABI,
 as the name `TestCounterIncreased` does not appear in the `"kind": "struct"` ABI entry. This did not matter in previous versions when the variant name and type had to be equal.
-* One data element based on the struct `CounterIncreased` which is associated to `TestCounterIncreased` via one of the `Event` type variants.
+* One data element based on the struct `CounterIncreased` which is associated with `TestCounterIncreased` via one of the `Event` type variants.
 
 === Enum variants inside Event
 
@@ -531,15 +531,15 @@ If a `TestEnum` event is being emitted via `self.emit(Event::TestEnum(MyEnum::Va
 When the event is emitted, the serialization to keys and data happens as follows:
 
 * Since the `TestEnum` variant has `kind` nested, add the first key: `sn_keccak(TestEnum)`, and the rest of the serialization to keys and data is done recursively via the `starknet::event` trait implementation of `MyEnum`.
-* Next, you can handle a `"kind": "nested"` variant (previously it was `TestEnum`, now it’s `Var1`), which means you can add another key depending on the sub variant: `sn_keccak(Var1)`, and proceed to serialize according to the `starknet::event`
+* Next, you can handle a `"kind": "nested"` variant (previously it was `TestEnum`, now it’s `Var1`), which means you can add another key depending on the sub-variant: `sn_keccak(Var1)`, and proceed to serialize according to the `starknet::event`
 implementation of `MyStruct`.
 * Finally, proceed to serialize `MyStruct`, which gives us a single data member.
 
 This results in `keys = [sn_keccak(TestEnum), sn_keccak(Var1)]` and `data=[5]`
 
 [NOTE]
 ====
-Allowing variants which are themselves enums (`TestEnum` is an enum variant here) means further nesting is possible.
+Allowing variants that are themselves enums (`TestEnum` is an enum variant here) means further nesting is possible.
 ====
 
 
@@ -583,7 +583,7 @@ This will look as follows in the ABI (only the relevant parts are shown):
   "name": "<namespace>::Event",
   "kind": "enum",
   "variants": [
-    // ignoring all the other variants for berevity
+    // ignoring all the other variants for brevity
     {
       "name": "TestEnum",
       "type": "<namespace>::MyEnum",
@@ -621,7 +621,7 @@ As `TestEnum`, `Var1` and `Var2` are of kind `nested`, a selector should be adde
 
 === Flattened enum variants
 
-You may not want to nest enums when serializing the event. For example, if you write an ERC20 as a component (not a contract) which is pluggable anywhere, you may not want the contract to modify the keys of known events such as `Transfer`.
+You might not want to nest enums when serializing the event. For example, if you write an ERC-20 as a component, not a contract, that is pluggable anywhere, you might not want the contract to modify the keys of known events such as `Transfer`.
 
 To avoid nesting, write the following high level code:
 
@@ -761,7 +761,7 @@ In Cairo v2, a dedicated type for the contract's events was introduced. Currentl
 
 The `Event` enum variants appear in the ABI under `"type" = "event"` rather than regular structs.
 
-For such entries, each member has an additional `kind` field which specifies how the serialization into keys and data takes place:
+For such entries, each member has an additional `kind` field that specifies how the serialization into keys and data takes place:
 
 * If the kind is `key`, then this member or variant are serialized into the event's keys.
 * If the kind is `data`, then this member or variant are serialized into the event's data.

components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-address.adoc

@@ -28,6 +28,7 @@ A random `salt` ensures unique addresses for smart contract deployments, prevent
 It also thwarts replay attacks by influencing the transaction hash with a unique sender address.
 ====
 
+=======
 For more information on the address computation, see the https://github.com/starkware-libs/cairo/blob/2c96b181a6debe9a564b51dbeaaf48fa75808d53/corelib/src/starknet/contract_address.cairo[Cairo code repository].
 
 

components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-classes.adoc

@@ -21,7 +21,7 @@ To deploy new instances of a previously declared class, use the `deploy` system
 To use the functionality of a declared class, without deploying an instance of that class, you can use the `library_call` system call. 
 This system call is an analogue of Ethereum's low-level `delegatecall` function in the world of classes. The `library_call` system call enables you to use class code directly, instead of having a placeholder contract deployed, which is used only for its code.
 
-== Additonal resources
+== Additional resources
 
 * xref:architecture_and_concepts:Smart_Contracts/class-hash.adoc[Class hash]
 * xref:architecture_and_concepts:Network_Architecture/transactions.adoc#declare-transaction[`declare` transaction]

components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-storage.adoc

@@ -33,7 +33,7 @@ use starknet::syscalls::storage_write_syscall;
 [id="storage_variables"]
 == Storage variables
 
-The most common way for interacting with a contract's storage is through storage variables.
+The most common way to interact with a contract's storage is through storage variables.
 
 The `@storage_var` decorator declares a variable that will be kept as part of the contract storage. The variable can consist of a single felt, or it can be a mapping from multiple arguments to a tuple of felts or structs.
 

components/Starknet/modules/cli/pages/starkli.adoc

@@ -3,7 +3,7 @@
 
 [WARNING]
 ====
-The Starknet CLI is deprecated in favour of the xref:tools:devtools.adoc#starkli[StarkLi CLI].
+The Starknet CLI is deprecated in favor of the xref:tools:devtools.adoc#starkli[StarkLi CLI].
 ====
 
 [id="basic_command_line_syntax"]
@@ -210,7 +210,7 @@ $ export STARKNET_WALLET=starkware.starknet.wallets.open_zeppelin.OpenZeppelinAc
 
 [CAUTION]
 ====
-Using the builtin wallet providers that are part of the cairo-lang package (starkware.starknet.wallets...) is _not secure_ (for example, the private key may be kept not encrypted and without backup in your home directory). You should only use them if you’re not overly concerned with losing access to your accounts (for example, for testing purposes).
+Using the built-in wallet providers that are part of the cairo-lang package (starkware.starknet.wallets...) is _not secure_ (for example, the private key may be kept not encrypted and without backup in your home directory). You should only use them if you’re not overly concerned with losing access to your accounts (for example, for testing purposes).
 ====
 
 [id="starknet-estimate_fee"]
@@ -387,4 +387,4 @@ The possible statuses of a transaction are:
 * `ACCEPTED_ON_L2`
 * `ACCEPTED_ON_L1`
 
-Refer to xref:architecture_and_concepts:Network_Architecture/transaction-life-cycle.adoc[this] section for more information about the transaction lifecycle.
+For more information, see xref:architecture_and_concepts:Network_Architecture/transaction-life-cycle.adoc[Transaction lifecycle].

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

@@ -12,7 +12,7 @@ starkli --version
 scarb --version
 ----
 
-If either of the above commands fail, please visit xref:environment_setup.adoc[Setting up your environment].
+If either of the above commands fails, see xref:environment_setup.adoc[Setting up your environment].
 
 == Introduction
 

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

@@ -4,7 +4,7 @@
 
 image::juno_banner.png[width=800]
 
-Juno is a golang Starknet node implementation by https://nethermind.io/[Nethermind] with the aim of decentralising Starknet.
+Juno is a golang Starknet node implementation by https://nethermind.io/[Nethermind] with the aim of decentralizing Starknet.
 
 See the official https://github.com/NethermindEth/juno[Juno GitHub repository] for more details.
 
@@ -118,7 +118,7 @@ This release adds support for the upcoming Starknet v0.12.1 upgrade and includes
 
 === Fixed
 
-* Resolved issues causing context cancelled errors in write RPC methods
+* Resolved issues causing context canceled errors in writing RPC methods
 * Mapped gateway errors to write API RPC errors, improving error handling
 
 == https://github.com/NethermindEth/juno/releases/tag/v0.4.1[v0.4.1]
@@ -253,7 +253,7 @@ This is Juno's first release (compatible with Starknet `v0.10.3`) with the follo
 
 * Starknet state construction and storage using a path-based Merkle Patricia trie. 
 * Pedersen and `starknet_keccak` hash implementation over starknet field.
-* Feeder gateway synchronisation of Blocks, Transactions, Receipts, State Updates and Classes.
+* Feeder gateway synchronization of Blocks, Transactions, Receipts, State Updates and Classes.
 * Block and Transaction hash verification.
 * JSON-RPC Endpoints:
 ** `starknet_chainId`
@@ -265,4 +265,4 @@ This is Juno's first release (compatible with Starknet `v0.10.3`) with the follo
 ** `starknet_getTransactionReceipt`
 ** `starknet_getBlockTransactionCount`
 ** `starknet_getTransactionByBlockIdAndIndex`
-** `starknet_getStateUpdate`
+** `starknet_getStateUpdate`

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

@@ -56,7 +56,7 @@ See the official https://github.com/eqlabs/pathfinder[Pathfinder Github reposito
 - `starknet_estimateMessageFee` for JSON-RPC v0.3.1 to estimate message fee from L1 handler.
 - sync-related metrics
   - `current_block`: the currently sync'd block height of the node
-  - `highest_block`: the height of the block chain
+  - `highest_block`: the height of the blockchain
   - `block_time`: timestamp difference between the current block and its parent
   - `block_latency`: delay between current block being published and sync'd locally
   - `block_download`: time taken to download current block's data excluding classes
@@ -395,4 +395,4 @@ This release includes an update to the cairo-vm embedded in pathfinder in order
 Since these changes are not yet live on testnet nor mainnet, this means upgrading to this release will cause deviations between what pathfinder outputs and what can be expected on the network. More specifically, `starknet_estimateFee` will compute different fees until the network has upgraded to xref:documentation:starknet_versions:version_notes.adoc#version0.10.2[Starknet v0.10.2].
 
 If you don't need the RPC route changes, it may be pertinent to delay updating until closer to the xref:documentation:starknet_versions:version_notes.adoc#version0.10.2[v0.10.2] release dates on testnet and mainnet. The expected timeline for these upgrades is ~17/11 for testnets and ~24/11 for mainnet.
-====
+====

contributing_to_docs/doc_guidelines.adoc

@@ -338,7 +338,7 @@ Do not include link:https://docs.asciidoctor.org/asciidoc/latest/directives/incl
 
 You can use AsciiDoc callouts in the source code file.
 Comment out the callout in the YAML file to ensure that file can still be parsed as valid YAML.
-Asciidoctor recognises the commented callout and renders it correctly in the output.
+Asciidoctor recognizes the commented callout and renders it correctly in the output.
 For example:
 
 [source,yaml]
@@ -511,7 +511,7 @@ $ <regular_user_permission_command_line_input>
 ----
 root@17617744386d:/app# ./player.py
 ----
-* Avoid using markup in code block. If you must use any markup in code blocks, see the Asciidoctor documentation on source blocks and substitutions:
+* Avoid using markup in a code block. If you must use any markup in code blocks, see the Asciidoctor documentation on source blocks and substitutions:
 ** link:https://docs.asciidoctor.org/asciidoc/latest/verbatim/source-blocks/[Source Code Blocks]
 ** link:https://docs.asciidoctor.org/asciidoc/latest/subs/[Substitutions]
 +