Update docs for higher accuracy and quality of information

docs/advanced/actions.md

@@ -510,7 +510,7 @@ export interface ActionParameter {
 
 The `pattern` should be a string equivalent of a valid regular expression. This
 regular expression pattern should by used by blink-clients to validate user
-input before before making the POST request. If the `pattern` is not a valid
+input before making the POST request. If the `pattern` is not a valid
 regular expression, it should be ignored by clients.
 
 The `patternDescription` is a human readable description of the expected input
@@ -592,7 +592,7 @@ user input elements are also supported:
 
 - `textarea` - equivalent of HTML
   [textarea element](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea).
-  Allowing the user provide multi-line input.
+  Allowing the user to provide multi-line input.
 - `select` - equivalent of HTML
   [select element](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select),
   allowing the user to experience a “dropdown” style field. The Action API
@@ -971,7 +971,7 @@ clients in one of the following ways:
   UI with the included Action metadata, but will not allow the user to execute
   further actions.
 
-If no `links.next` is not provided, blink clients should assume the current
+If `links.next` is not provided, blink clients should assume the current
 action is final action in the chain, presenting their "completed" UI state after
 the transaction is confirmed.
 
@@ -1070,7 +1070,7 @@ The following table outlines the syntax for path matching patterns:
 
 ### Rules Examples
 
-The following example demonstrates an exact match rule to map requests requests
+The following example demonstrates an exact match rule to map requests
 to `/buy` from your site's root to the exact path `/api/buy` relative to your
 site's root:
 
@@ -1210,7 +1210,7 @@ associated with the Action Provider in a multi-step process:
 3. Verify the specific transaction is the first on-chain occurrence of the
    `reference` on-chain:
    - If this transaction is the first occurrence, the transaction is considered
-     verified and can a safely attributed to the Action Provider.
+     verified and can be safely attributed to the Action Provider.
    - If this transaction is NOT the first occurrence, it is considered invalid
      and therefore not attributed to the Action Provider.
 

docs/advanced/confirmation.md

@@ -153,7 +153,7 @@ processed transactions.
 
 ### Other blockchains
 
-Solana's approach of prevent double processing is quite different from other
+Solana's approach to prevent double processing is quite different from other
 blockchains. For example, Ethereum tracks a counter (nonce) for each transaction
 sender and will only process transactions that use the next valid nonce.
 

docs/advanced/lookup-tables.md

@@ -147,7 +147,7 @@ utilize the onchain lookup capabilities.
 Just like older `legacy` transactions, you can create all the
 [instructions](/docs/terminology.md#instruction) your transaction will execute
 onchain. You can then provide an array of these instructions to the
-[Message](/docs/terminology.md#message) used in the `v0 transaction.
+[Message](/docs/terminology.md#message) used in the `v0` transaction.
 
 > NOTE: The instructions used inside a `v0` transaction can be constructed using
 > the same methods and functions used to create the instructions in the past.

docs/advanced/retry.md

@@ -142,7 +142,7 @@ transaction submission if developers enable
 
 ![Transaction dropped via an RPC Pool](/assets/docs/rt-dropped-via-rpc-pool.png)
 
-Temporarily network forks can also result in dropped transactions. If a
+Temporary network forks can also result in dropped transactions. If a
 validator is slow to replay its blocks within the Banking Stage, it may end up
 creating a minority fork. When a client builds a transaction, it's possible for
 the transaction to reference a `recentBlockhash` that only exists on the

docs/advanced/state-compression.md

@@ -32,9 +32,9 @@ These _trees_ are created in this "_deterministic_" process by:
 
 - taking any piece of data
 - creating a hash of this data
-- storing this hash as a `leaf` the bottom of the tree
-- each `leaf` pair is then hash together, creating a `branch`
-- each `branch` is then hash together
+- storing this hash as a `leaf` at the bottom of the tree
+- each `leaf` pair is then hashed together, creating a `branch`
+- each `branch` is then hashed together
 - continually climbing the tree and hashing adjacent branches together
 - once at the top of the tree, a final `root hash` is produced
 
@@ -94,7 +94,7 @@ In high throughput applications, like within the
 [Solana runtime](/docs/core/fees.md), requests to change an on-chain
 _traditional merkle tree_ could be received by validators in relatively rapid
 succession (e.g. within the same slot). Each leaf data change would still be
-required to performed in series. Resulting in each subsequent request for change
+required to be performed in series. Resulting in each subsequent request for change
 to fail, due to the root hash and proof being invalidated by the previous change
 request in the slot.
 
@@ -175,7 +175,7 @@ We must use a `maxDepth` of `14` to ensure we can store all of our data.
 
 The `maxDepth` value will be one of the primary drivers of cost when creating a
 tree since you will pay this cost upfront at tree creation. The higher the max
-tree depth depth, the more data fingerprints (aka hashes) you can store, the
+tree depth, the more data fingerprints (aka hashes) you can store, the
 higher the cost.
 
 ### Max buffer size