Merge pull request #1203 from KyryloKilin/main

pages/builders/app-developers/bridging/standard-bridge.mdx

@@ -26,7 +26,7 @@ You may wish to explore some of these options to find the bridge that works best
 The Standard Bridge allows users to convert tokens that are native to one chain (like Ethereum) into a representation of those tokens on the other chain (like OP Mainnet).
 Users can then convert these bridged representations back into their original native tokens at any time.
 
-This bridging mechanism functions identically in both direction — tokens native to OP Mainnet can be bridged to Ethereum, just like tokens native to Ethereum can be bridged to OP Mainnet.
+This bridging mechanism functions identically in both directions — tokens native to OP Mainnet can be bridged to Ethereum, just like tokens native to Ethereum can be bridged to OP Mainnet.
 Here you'll get to understand how the Standard Bridge works when moving tokens from Ethereum to OP Mainnet.
 Since the bridging mechanism is mirrored on both sides, this will also explain how the bridge works in the opposite direction.
 

pages/chain/identity/individuals.mdx

@@ -27,4 +27,4 @@ When you make attestations about individuals:
 
 ### Further reading
 
-For more details on individual identity in the Optimism Collective, refer to the **[the governance docs](https://community.optimism.io/docs/identity/project-and-individual-identity-in-the-collective/#building-a-digital-identity)** on building a digital identity.
+For more details on individual identity in the Optimism Collective, refer to **[the governance docs](https://community.optimism.io/docs/identity/project-and-individual-identity-in-the-collective/#building-a-digital-identity)** on building a digital identity.

pages/chain/identity/schemas.mdx

@@ -39,7 +39,7 @@ Used to associate metadata to an organization. Re-issued each time there is a ch
 | farcasterID  | The Farcaster id of the individual who published the organization metadata                                      |
 | name         | The name of the organization                                                                                    |
 | projects     | The array of projects that belong to this organization                                                          |
-| parentOrgUID | The attestation UID of this organizations's parent, in case it has one                                          |
+| parentOrgUID | The attestation UID of this organization's parent, in case it has one                                          |
 | metadataType | How the metadata can be accessed. 1 for ipfs, 2 for http                                                        |
 | metadataUrl  | The storage location where the metadata can be retrieved                                                        |
 

pages/connect/contribute/style-guide.mdx

@@ -121,7 +121,7 @@ We aim to use consistent organization that is also user-centered and accessible.
 *   Use bulleted lists to visually separate content that does not require a specific order.
 *   Format text for optimal readability (bold vs. italics). Avoid using italics in web content as it decreases readability. For instance, **bold** is appropriate to use when referring to a specific button or page name in technical documentation.
 *   Organize technical content to cover only one major concept or task at a time.
-    *   **General rule of thumb**: documents with more than 3 levels of structured headings (H4 or ####) and/or more than than 20 minutes estimated reading time (ERT) need revisions will typically involve editing for conciseness, splitting the document into multiple pages, or both.
+    *   **General rule of thumb**: documents with more than 3 levels of structured headings (H4 or ####) and/or more than 20 minutes estimated reading time (ERT) need revisions will typically involve editing for conciseness, splitting the document into multiple pages, or both.
     *   Revisions will usually require editing for concision, breaking the document apart into multiple pages, or some combination of the two.
 *   Organize content based on the audience's varying needs and prior knowledge. If pre-requisite knowledge is necessary to complete a task or understand a concept, then share it with users (including links to learn more), so they can easily get up to speed.
 

pages/stack/transactions/fees.mdx

@@ -169,7 +169,7 @@ l1_data_fee = tx_compressed_size * weighted_gas_price
 
 Recall that base\_fee\_scalar is set to dynamic\_overhead and blob\_base\_fee\_scalar is 0 immediately
 following the upgrade. Because the old overhead parameter becomes ignored, new L1 data prices will
-be (slightly, since overhead is typically a very small) lower than before the fork.  Chain
+be (slightly, since overhead is typically very small) lower than before the fork.  Chain
 operators will likely want to retune the parameters appropriately after the fork, particularly if
 they plan on [enabling blobs](/builders/chain-operators/management/blobs).
 Chain operators can use the [Ecotone fee parameter calculator](https://docs.google.com/spreadsheets/d/12VIiXHaVECG2RUunDSVJpn67IQp9NHFJqUsma2PndpE/edit#gid=186414307) to get a better estimate of scalar values to use for your chain.