fix: typos (#5030)

* fix typos

* fix: typo

* fix: typos

* fix: typos

* Update overview.md

docs/src/account-compression/concepts.md

@@ -8,7 +8,7 @@ To understand concurrent merkle trees we must first briefly understand merkle tr
 ### Merkle Trees
 
 A merkle tree is a hash based data structure that encodes data into a tree.
-The tree has nodes that are hashes of it's children and each leaf node is a hash of the data.
+The tree has nodes that are hashes of its children and each leaf node is a hash of the data.
 
 Each node has a 256 bit (32 byte) string represented by X<sub>i</sub> ∈ {0,1}^256 which is hashed using `H: {0, 1}^256 × {0, 1}^256 → {0, 1}^256`, meaning two child nodes with their 256 bit strings are hashed into one parent node with a 256 bit string. You can use any hash function that satisfies this property but we use SHA256.
 
@@ -33,7 +33,7 @@ If you change X5 to X5' then you will have to recompute the root hash in the fol
 - X1' = H(X2',X3)
 
 ### Concurrent leaf replacement
-We know that there can be multiple concurrent requests to write to the same state, however when the root changes while the first write is happening the second write will generate an invalid root, in other words everytime a root is modified all modifications in progress will be invalid.
+We know that there can be multiple concurrent requests to write to the same state, however when the root changes while the first write is happening the second write will generate an invalid root, in other words every time a root is modified all modifications in progress will be invalid.
 ```txt
           X1'              X1''
         /    \           /    \
@@ -43,7 +43,7 @@ We know that there can be multiple concurrent requests to write to the same stat
 ```
 In the above example let's say we try to modify `X5 -> X5'` and make another request to modify X6 -> X6''. For the first change we get root `X1'` computed using `X1' = H(H(X4,X5'),X3)`. For the second change we get root X1'' computed using `X1'' = H(H(X6'',X7),X2`). However `X1''` is not valid as `X1' != H(H(X6, X7), X2)` because the new root is actually `X1'`.
 
-The reason this happens is because the change in the first trees path actualy changes the proofs required by the second trees change. To circumvent this problem we maintain a changelog of updates that have been made to the tree, so when `X5 -> X5'` the second mutation can actually use X2' instead of X2 which would compute to the correct root.
+The reason this happens is because the change in the first trees path actually changes the proofs required by the second trees change. To circumvent this problem we maintain a changelog of updates that have been made to the tree, so when `X5 -> X5'` the second mutation can actually use X2' instead of X2 which would compute to the correct root.
 
 To swap the nodes when adding a new leaf in the second tree we do the following:
 - Take XOR of the leaf indices of the change log path and the new leaf in base 2

docs/src/account-compression/usage.md

@@ -83,7 +83,7 @@ await sendAndConfirmTransaction(connection, tx, [payer]);
 
 4. Replace a leaf in the tree, using a 3rd party indexer
 
-This example assumes that some 3rd party service is indexing the the tree at `cmtKeypair.publicKey` for you, and providing MerkleProofs via some REST endpoint.
+This example assumes that some 3rd party service is indexing the tree at `cmtKeypair.publicKey` for you, and providing MerkleProofs via some REST endpoint.
 The `getProofFromAnIndexer` function is a **placeholder** to exemplify this relationship.
 
 ```typescript
@@ -109,4 +109,4 @@ Here are some examples using account compression in the wild:
 
 * Solana Program Library [tests](https://github.com/solana-labs/solana-program-library/tree/master/account-compression/sdk/tests)
 
-* Metaplex Program Library Compressed NFT [tests](https://github.com/metaplex-foundation/metaplex-program-library/tree/master/bubblegum/js/tests)
+* Metaplex Program Library Compressed NFT [tests](https://github.com/metaplex-foundation/metaplex-program-library/tree/master/bubblegum/js/tests)

docs/src/confidential-token/deep-dive/overview.md

@@ -4,16 +4,16 @@ title: Protocol Overview
 
 In this section, we provide an overview of the underlying cryptographic protocol
 for the confidential Token extension. An understanding of the details that are
-discussed in the following subsections are not needed to actually use the
+discussed in the following subsections is not needed to actually use the
 confidential extension. We refer to the previous section for a quick start
 guide.
 
 We note that this overview exists mainly to provide the design intuition behind
-the underlying cryptography that is used in the confidential extension. Some of
+the underlying cryptography that is used in the confidential extension. Some parts of
 the description of the protocol in the overview could differ from the actual
 implementation. We refer to the subsequent subsections, the [source
 code](https://github.com/solana-labs/solana-program-library), and the
-documentations within for the precise details of the underlying cryptography.
+documentation within for the precise details of the underlying cryptography.
 
 ## Tokens with Encryption and Proofs
 
@@ -188,7 +188,7 @@ token program itself, preventing it from verifying the validity of a
 transaction.
 
 To fix this, we require that transfer instructions include zero-knowledge proofs
-that validate their correctness. Put simply, zero-knolwedge proofs consist of
+that validate their correctness. Put simply, zero-knowledge proofs consist of
 two pair of algorithms `prove` and `verify` that work over public and private
 data. The `prove` algorithm generates a "proof" that certifies that some
 property of the public and private data is true. The `verify` algorithm checks
@@ -238,7 +238,7 @@ zero-knowledge proofs.
   `lower_bound <= x < upper_bound`.
 
   In the confidential extension, we require that a transfer instruction includes
-  a range proof that certify the following:
+  a range proof that certifies the following:
 
   - The proof should certify that there are enough funds in the source account.
     Specifically, let `ct_source` be the encrypted balance of a source account
@@ -299,7 +299,7 @@ decrypting transaction amounts allow for a more flexible interface.
 In a potential application, the decryption key for specific accounts can be
 shared among multiple users (e.g. regulators) that should have access to an
 account balance. Although these users can decrypt account balances, only the
-owner of the account that have access to the owner signing key can sign a
+owner of the account that has access to the owner signing key can sign a
 transaction that initiates a transfer of tokens. The owner of an account can
 update the account with a new encryption key using the `ConfigureAccount`.
 
@@ -343,13 +343,13 @@ One way an attacker can disrupt the use of a confidential extension account is
 by using _front-running_. Zero-knowledge proofs are verified with respect to the
 encrypted balance of an account. Suppose that a user Alice generates a proof
 with respect to her current encrypted account balance. If another user Bob
-transfers some tokesn to Alice, and Bob's transaction is processed first, then
+transfers some tokens to Alice, and Bob's transaction is processed first, then
 Alice's transaction will be rejected by the Token program as the proof will not
 verify with respect to the newly updated account state.
 
 Under normal conditions, upon a rejection by the program, Alice can simply look
 up the newly updated ciphertext and submit a new transaction. However, if a
-malicious attacker continuously flods the network with a transfer to Alice's
+malicious attacker continuously floods the network with a transfer to Alice's
 account, then the account may theoretically become unusable. To prevent this
 type of attack, we modify the account data structure such that the encrypted
 balance of an account is divided into two separate components: the _pending_

docs/src/confidential-token/deep-dive/zkps.md

@@ -177,7 +177,7 @@ components associated with fees.
 
 If a mint is extended for fees, then transfers of tokens that pertains to the
 mint requires a transfer fee that is calculated as a percentage of the transfer
-amount. Specifically, a transaction fee is determined by two paramters:
+amount. Specifically, a transaction fee is determined by two parameters:
 
 - `bp`: The base point representing the fee rate. It is a positive integer that
   represents a percentage rate that is two points to the right of the decimal
@@ -284,7 +284,7 @@ the following notes.
 
 [[Notes]](./validity_proof.pdf)
 
-Validity proofs is required for the `Withdraw`, `Transfer`, and
+Validity proofs are required for the `Withdraw`, `Transfer`, and
 `TransferWithFee` instructions. These instructions require the client to include
 twisted ElGamal ciphertexts as part of the instruction data. Validity proofs
 that are attached with these instructions certify that these ElGamal ciphertexts
@@ -318,7 +318,7 @@ specified in the following notes.
 [[Notes]](./equality_proof.pdf).
 
 Ciphertext-commitment equality proofs are required for the `Transfer` and
-`TransferWithFee` instructions. Ciphertext-ciphertext equaltiy proofs are
+`TransferWithFee` instructions. Ciphertext-ciphertext equality proofs are
 required for the `WithdrawWithheldTokensFromMint` and
 `WithdrawWithheldTokensFromAccounts` instructions.