Updated docs files with syntax and spelling errors

docs/economics/index.md

@@ -18,10 +18,10 @@ The main channels of participant remittances are referred to as protocol-based
 rewards and transaction fees. Protocol-based rewards are generated from
 inflationary issuances from a protocol-defined inflation schedule. These rewards
 will constitute the total protocol-based reward delivered to validation clients,
-the remaining sourced from transaction fees. In the early days of the network,
-it is likely that protocol-based rewards, deployed based on predefined issuance
-schedule, will drive the majority of participant incentives to participate in
-the network.
+with the remaining sourced from transaction fees. In the early days of the
+network, it is likely that protocol-based rewards, deployed based on predefined
+issuance schedule, will drive the majority of participant incentives to
+participate in the network.
 
 These protocol-based rewards are calculated per epoch and distributed across the
 active delegated stake and validator set (per validator commission). As

docs/economics/staking/index.md

@@ -23,8 +23,8 @@ The more stake delegated to a validator, the more often this validator is chosen
 to write new transactions to the ledger. The more transactions the validator
 writes, the more rewards the validator and its delegators earn. Validators who
 configure their systems to be able to process more transactions earn
-proportionally more rewards and because they keep the network running as fast
-and as smoothly as possible.
+proportionally more rewards because they keep the network running as fast and as
+smoothly as possible.
 
 Validators incur costs by running and maintaining their systems, and this is
 passed on to delegators in the form of a fee collected as a percentage of
@@ -51,7 +51,7 @@ wallet provides steps to create a stake account and do the delegation.
 #### Supported Wallets
 
 Many web and mobile wallets support Solana staking operations. Please check with
-your favorite wallet's maintainers regarding status
+your favorite wallet's maintainers regarding status.
 
 #### Solana command line tools
 
@@ -72,8 +72,8 @@ information about potentially performant validators from the links below. The
 Solana Foundation does not recommend any particular validator.
 
 The site solanabeach.io is built and maintained by one of our validators,
-Staking Facilities. It provides a some high-level graphical information about
-the network as a whole, as well as a list of each validator and some recent
+Staking Facilities. It provides some high-level graphical information about the
+network as a whole, as well as a list of each validator and some recent
 performance statistics about each one.
 
 - https://solanabeach.io

docs/more/exchange.md

@@ -716,7 +716,7 @@ The following code sample assumes you're using the Maven.
       <artifactId>curve25519-elisabeth</artifactId>
       <version>0.1.0</version>
   </dependency>
-<dependencies>
+</dependencies>
 ```
 
 ```java
@@ -746,7 +746,7 @@ public class PubkeyValidator
 
 Every deposit and withdrawal of SOL must be greater or equal to the minimum
 rent-exempt balance for the account at the wallet address (a basic SOL account
-holding no data), currently: 0.000890880 SOL
+holding no data), currently: 0.00089088 SOL
 
 Similarly, every deposit account must contain at least this balance.
 

docs/programs/anchor/client-typescript.md

@@ -27,7 +27,7 @@ An `AnchorProvider` is an abstraction that combines two things:
 - `Wallet` - (optional) a default wallet used to pay and sign transactions
 
 <!-- prettier-ignore -->
-<Tabs items={['Frontend/Node', 'Test File']}>
+<Tabs items={['Frontend/Node', 'Test File']}></Tabs>
 <Tab value="Frontend/Node">
 
 When integrating with a frontend using the
@@ -118,7 +118,7 @@ to:
 The basic format looks like the following:
 
 <!-- prettier-ignore -->
-<Tabs items={['methods', 'instruction', 'accounts', `signers`]}>
+<Tabs items={['methods', 'instruction', 'accounts', 'signers']}></Tabs>
 <Tab value="methods">
 
 `program.methods` - This is the builder API for creating instruction calls from
@@ -191,7 +191,7 @@ before sending.
 Anchor provides multiple methods for building program instructions:
 
 <!-- prettier-ignore -->
-<Tabs items={['.rpc', '.transaction', '.instruction']}>
+<Tabs items={['.rpc', '.transaction', '.instruction']}></Tabs>
 <Tab value=".rpc">
 
 The
@@ -292,7 +292,7 @@ Use `program.account` followed by the name of the account type defined in the
 IDL. Anchor provides multiple methods for fetching accounts.
 
 <!-- prettier-ignore -->
-<Tabs items={['all', 'memcmp', 'fetch', 'fetchMultiple']}>
+<Tabs items={['all', 'memcmp', 'fetch', 'fetchMultiple']}></Tabs>
 <Tab value="all">
 
 Use

docs/programs/anchor/cpi.md

@@ -9,7 +9,7 @@ sidebarSortOrder: 5
 
 [Cross Program Invocations (CPI)](/docs/core/cpi.md) refer to the process of one
 program invoking instructions of another program, which enables the
-composibility of programs on Solana.
+composability of programs on Solana.
 
 This section will cover the basics of implementing CPIs in an Anchor program,
 using a simple SOL transfer instruction as a practical example. Once you
@@ -125,7 +125,7 @@ functionally equivalent. The main purpose is to illustrate the implementation
 details of the CPI.
 
 <!-- prettier-ignore -->
-<Tabs groupId="language" items={['1', '2', '3']}>
+<Tabs groupId="language" items={['1', '2', '3']}></Tabs>
 <Tab value="1">
 
 The `sol_transfer` instruction included in the example code shows a typical
@@ -440,7 +440,7 @@ functionally equivalent. The main purpose is to illustrate the implementation
 details of the CPI.
 
 <!-- prettier-ignore -->
-<Tabs groupId="language" items={['1', '2']}>
+<Tabs groupId="language" items={['1', '2']}></Tabs>
 <Tab value="1">
 
 The `sol_transfer` instruction included in the example code shows a typical