chore: Fix typos in documentation for multiple files

how-to-guides/arabica-devnet.md

@@ -24,7 +24,7 @@ it is a useful way to keep testing the latest changes in the software.
 
 Developers can still deploy on Mocha testnet their sovereign rollups if they
 chose to do so, it just will always lag behind Arabica devnet until Mocha
-undergoes network upgrades upgrades in coordination with validators.
+undergoes network upgrades in coordination with validators.
 
 ## Network details
 

how-to-guides/arbitrum-integration.md

@@ -57,14 +57,14 @@ The following represents a non-exhaustive list of considerations when running a
 
 ### Preimage Oracle Implementation
 
-In order to support fraud proofs, this integration has the necessary code for a Nitro validator to populate its preimage mapping with Celestia hashes that then get "unpealed" in order to reveal the full data for a Blob. You can
+In order to support fraud proofs, this integration has the necessary code for a Nitro validator to populate its preimage mapping with Celestia hashes that then get "unpeeled" in order to reveal the full data for a Blob. You can
 [read more about the "Hash Oracle Trick"](https://docs.arbitrum.io/inside-arbitrum-nitro/#readpreimage-and-the-hash-oracle-trick).
 
 The data structures and hashing functions for this can be found in the [`nitro/das/celestia/tree` folder](https://github.com/celestiaorg/nitro/tree/v2.3.1-rc.1/das/celestia/tree)
 
 You can see where the preimage oracle gets used in the fraud proof replay binary [here](https://github.com/celestiaorg/nitro/blob/966e631f1a03b49d49f25bea67a92b275d3bacb9/cmd/replay/main.go#L153-L294)
 
-Something important to note is that the preimage oracle only keeps track of hashes for the rows in the Celestia data square in which a blob resides in, this way each Orbit chain with Celestia underneath does not need validators to recompute an entire Celestia Data Square, but instead, only have to compute the row roots for the rows in which it's data lives in, and the header data root, which is the binary merkle tree hash built using the row roots and column roots fetched from a Celestia node. Because only data roots that can be confirmed on Blobstream get accepted into the sequencer inbox, one can have a high degree of certainty that the canonical data root being unpealed as well as the row roots are in fact correct.
+Something important to note is that the preimage oracle only keeps track of hashes for the rows in the Celestia data square in which a blob resides in, this way each Orbit chain with Celestia underneath does not need validators to recompute an entire Celestia Data Square, but instead, only have to compute the row roots for the rows in which it's data lives in, and the header data root, which is the binary merkle tree hash built using the row roots and column roots fetched from a Celestia node. Because only data roots that can be confirmed on Blobstream get accepted into the sequencer inbox, one can have a high degree of certainty that the canonical data root being unpeeled as well as the row roots are in fact correct.
 
 ### Blobstream X implementation
 

how-to-guides/blobstream-offchain.md

@@ -208,7 +208,7 @@ func (s *Sequencer) ProduceBlock(txs []json.RawMessage) (Block, error) {
     header := Header{
         Height:       uint64(len(s.Blocks) + 1),
         PreviousHash: lastBlock.Header.Hash(),
-        Namespce:     s.Namespace,
+        Namespace:     s.Namespace,
         Span: span,
     }
 

how-to-guides/blobstream-x-deploy.md

@@ -54,7 +54,7 @@ Assume we're deploying to a chain which chainID is 12345. The `.env` should look
 CREATE2_SALT=
 # The 'owner' of the contracts, recommended to be an EOA
 GUARDIAN=
-# The default prover to fullfill requests for Functions that have not opted for a different prover
+# The default prover to fulfill requests for Functions that have not opted for a different prover
 PROVER=
 # RPC URLs for each chain you want to deploy to
 RPC_12345=
@@ -162,7 +162,7 @@ which will return the address of the function verifier that was deployed in the
 
 Now that the function verifier's contract is deployed and registered in the succinct gateway, we can define whitelisting rules for the proof submission. 
 
-by default, the whitelist status is set to `Default`. This means that only the default verifier, which was setup when [deploying the SuccinctGateway](#deploy-a-new-succinctgateway). And if you want to restrict the list of provers that can submit proofs to your registered function verifier, you can set the whitelisting status of the function verifier and then add a custom prover. Or even allow for permissionlss submission.
+by default, the whitelist status is set to `Default`. This means that only the default verifier, which was setup when [deploying the SuccinctGateway](#deploy-a-new-succinctgateway). And if you want to restrict the list of provers that can submit proofs to your registered function verifier, you can set the whitelisting status of the function verifier and then add a custom prover. Or even allow for permissionless submission.
 
 #### Set Whitelist Status
 

how-to-guides/celestia-app-vesting.md

@@ -45,7 +45,7 @@ Home directory: /var/folders/_8/ljj6hspn0kn09qf9fy8kdyh40000gn/T/celestia_app_XX
 --> Updating go.mod
 ```
 
-And set the location as the `CElESTIA_APP_HOME` variable. We will use this
+And set the location as the `CELESTIA_APP_HOME` variable. We will use this
 for the remainder of the devnet section.
 
 ```bash