Merge pull request #200 from yash251/main

fix: typos

Author: alexander-sei

STYLE_GUIDE.mdx

@@ -21,7 +21,7 @@ Great documentation is simple and to the point. It should aim to convey more mea
 
 - To be clear and inclusive, avoid using jargon and obscure words where possible. 
 - Limit the number of clauses in a sentence and make sure that your points are structured.
-- Avoid qualifying language, which is ~~quite~~ often ~~completely~~ uneccessary.
+- Avoid qualifying language, which is ~~quite~~ often ~~completely~~ unnecessary.
 - Information should be simply organized and easy to find.
 
 ### Self-explanatory
@@ -34,7 +34,7 @@ Great documentation is self-explanatory. Documentation shouldn't need more docum
 The Sei Docs are structured using the [Nextra](https://nextra.site). Are a guideline, we have split the pages by target audience.
 
 ### General
-Docs in these section describe Sei and topics that are applicable to all audiences. This is general information that is not specfic to users or developers. Information here is meant to be as layman as possible and should be understandable by everyone.
+Docs in these section describe Sei and topics that are applicable to all audiences. This is general information that is not specific to users or developers. Information here is meant to be as layman as possible and should be understandable by everyone.
 
 Information here might include:
 - What is Sei?
@@ -167,7 +167,7 @@ When code blocks are used, they should always be prettified by specifying the la
 
 When writing code blocks, avoid
 1. Creating large code blocks. Break your code into smaller, more digestible pieces.
-2. Writing too much documentation in between lines. If neccessary, break the code block up and add text to explain each code block instead.
+2. Writing too much documentation in between lines. If necessary, break the code block up and add text to explain each code block instead.
 
 For tutorials, the goal should be to write code blocks that can be directly copied and used by the reader.
 

pages/dev-advanced-concepts/wallet-association.mdx

@@ -7,7 +7,7 @@ next: true
 Wallet association on the Sei network ensures the public key becomes known to the chain. Without this step, the chain cannot determine the Bech32 (`sei...`) address or the EVM-compatible (`0x...`) address from one another.
 
 
-Below are **4 distinct methods** for associating a wallet along with relevant defitnitions. Each method differs in terms of security considerations and required actions.
+Below are **4 distinct methods** for associating a wallet along with relevant definitions. Each method differs in terms of security considerations and required actions.
 
 ---
 

pages/dev-ecosystem-providers/ecosystem-map.mdx

@@ -15,7 +15,7 @@ Sei Ecosystem is the epicenter of technological advancement, bringing together c
 
 <EcosystemDynamicSection category="Consumer Apps" />
 
-## Infastructure
+## Infrastructure
 
 <EcosystemDynamicSection category="Infrastructure" />
 

pages/dev-ecosystem-providers/indexers/goldrush.mdx

@@ -45,7 +45,7 @@ on each for an address.
 
 There are 4 primary developer tools for using the APIs:
 
-1. [GoldRush APIs](https://goldrush.dev/docs/api) - enteprise-grade REST APIs to use with any programming language. Switch blockchains with one path parameter.
+1. [GoldRush APIs](https://goldrush.dev/docs/api) - enterprise-grade REST APIs to use with any programming language. Switch blockchains with one path parameter.
 
     ```sh
     curl -X GET https://api.covalenthq.com/v1/sei-mainnet/address/0x6d68A318D0632f7B9Ce9d6757Dea0e9dE19D7CCA/balances_v2/ \

pages/dev-interoperability.mdx

@@ -6,7 +6,7 @@ import interoperability from '../public/assets/interoperability.png';
 
 EVM and CosmWasm based smart contracts co-exist on Sei, but live in different execution environments.
 This creates a challenge for users, who use wallets that typically only support a single execution environment.
-Likewise for devlelopers, existing tooling and libraries can only interact with either EVM or Wasm (Think EthersJS vs CosmJS).
+Likewise for developers, existing tooling and libraries can only interact with either EVM or Wasm (Think EthersJS vs CosmJS).
 
 To bridge the gap between EVM and Wasm, Sei has introduced two interoperability features, allowing for smooth and easy interactions between both environments.
 Precompiled EVM contracts and Pointer Contracts enable all contracts to be accessible from both VM environments.

pages/dev-interoperability/precompiles/bank.mdx

@@ -37,7 +37,7 @@ This precompile enables EVM clients to interact with the bank module.
   ```
 
 ### Queries
-- `balance`: Queries the balance of the given acount for specified denom.
+- `balance`: Queries the balance of the given account for specified denom.
   ```solidity
     /// Queries the balance of the given account for the specified denom.
     /// @param acc The Sei address of the account to query.
@@ -48,7 +48,7 @@ This precompile enables EVM clients to interact with the bank module.
         string memory denom
     ) external view returns (uint256 amount);
   ```
-- `all_balances`: Queries all balances of the given acount.
+- `all_balances`: Queries all balances of the given account.
 ```solidity
     /// Queries the balance of the given account for all balances.
     /// @param acc The Sei address of the account to query.

pages/dev-interoperability/precompiles/cosmwasm.mdx

@@ -70,7 +70,7 @@ This precompile serves as an interface to the CosmWasm module, enabling EVM base
   ```solidity
   /// Queries a CosmWasm contract.
   /// @param contractAddress The Sei address of the contract to query.
-  /// @param req The query requeest object. The format is specified by the contract code.
+  /// @param req The query request object. The format is specified by the contract code.
   /// @return The response from the CosmWasm contract.
   function query(
       string memory contractAddress,

pages/dev-interoperability/precompiles/oracle.mdx

@@ -1,6 +1,6 @@
 import { Callout } from "nextra/components";
 
-# Orcale Precompile
+# Oracle Precompile
 
 **Address**: `0x0000000000000000000000000000000000001008`
 

pages/dev-node/configure-general-settings.mdx

@@ -8,7 +8,7 @@ Structure of ~/.sei/config
 │-- app.toml                            # seid configuration file
 │-- client.toml                         # configurations for the cli wallet (ex seid)
 │-- config.toml                         # Tendermint configuration file
-│-- genesis.json                        # gensesis transactions
+│-- genesis.json                        # genesis transactions
 │-- node_key.json                       # private key used for node authentication in the p2p protocol (its corresponding public key is the nodeid)
 └-- priv_validator_key.json             # key used by the validator on the node to sign blocks
 ```

pages/dev-node/quickstart.mdx

@@ -116,7 +116,7 @@ Before running the script, take a moment to understand the configurable paramete
     - The script will download the specified version, extract it, and install it using `make install`.
     - If `enable_unsafe_reset` is `True`, it will reset the Tendermint state and any existing configs + keys.
     - The script will initialize the node with the given moniker and chain ID.
-    - For non-local environments, it will fetch state sync parameters, persistent peers, and apropriate genesis file.
+    - For non-local environments, it will fetch state sync parameters, persistent peers, and appropriate genesis file.
 
 
 5. **Configuration Files**: