Merge pull request #1147 from Dimitrolito/fix/typos

Corrected Hyphenation Issues in Documentation

.github/ISSUE_TEMPLATE/general_docs_request.md

@@ -9,7 +9,7 @@ labels: 'community-request,documentation'
 <!-- please fill out the following the best to your ability and properly label the issue -->
 
 ## Brief Description of the Docs Request
-Write a clear and concise description of the docs request. For example, is the request related to an existing page or are you suggesting a brand new docs page?
+Write a clear and concise description of the docs request. For example, is the request related to an existing page or are you suggesting a brand-new docs page?
 
 ## Description of the Documentation You'd Like
 Explain what the final documentation page or pages should look like. Do you need a guide, tutorial, FAQ, troubleshooting page or more than one page? Do you have any source/content information to provide for the requested page(s)?

notes/nextra.md

@@ -14,5 +14,5 @@ Remark plugins can be injected into Nextra by modifying the `mdxOptions` object
 
 #### remarkCodeImport
 
-Rule is modified via [patch](/patches/[email protected]) to require that all code imports include an md5 content hash of the imported content.
+Rule is modified via [patch](/patches/[email protected]) to require that all code imports include a md5 content hash of the imported content.
 Requiring this hash means that changes to the underlying content must also come with corresponding changes to the relevant imports and imports cannot silently break.

pages/500.mdx

@@ -1,7 +1,7 @@
 ---
 title: Internal Server Error
 lang: en-US
-description: 500 internal server error and directs users to submit an git issue.
+description: 500 internal server error and directs users to submit a git issue.
 ---
 
 # Unexpected Error

pages/builders/app-developers/bridging/messaging.mdx

@@ -214,7 +214,7 @@ The L1 proof and finalization transactions are typically significantly more expe
 ## Understanding the challenge period
 
 One of the most important things to understand about L1 ⇔ L2 interaction is that **mainnet messages sent from Layer 2 to Layer 1 cannot be relayed for at least 7 days**.
-This means that any messages you send from Layer 2 will only be received on Layer 1 after this one week period has elapsed.
+This means that any messages you send from Layer 2 will only be received on Layer 1 after this one-week period has elapsed.
 We call this period of time the "challenge period" because it is the time during which a transaction can be challenged with a [fault proof](/stack/rollup/overview#fault-proofs).
 
 Optimistic Rollups are "optimistic" because they're based around the idea of publishing the *result* of a transaction to Ethereum without actually executing the transaction on Ethereum.

pages/builders/app-developers/transactions/estimates.mdx

@@ -100,7 +100,7 @@ Selecting the right tool for your use case will depend on your specific needs.
 ### Future proofing
 
 The L1 Data Fee formula is subject to change in the future, especially as the data availability landscape evolves.
-As a result, it's important to future proof your transaction fee estimation code to ensure that it will continue to function properly as the L1 Data Fee formula changes.
+As a result, it's important to future-proof your transaction fee estimation code to ensure that it will continue to function properly as the L1 Data Fee formula changes.
 
 *   Use existing [tooling](#tooling) to estimate the L1 Data Fee for your transaction if possible. This tooling will be updated to reflect any changes to the L1 Data Fee formula. This way you won't need to modify your code to account for any changes to the formula.
 *   Use the `getL1Fee` method on the `GasPriceOracle` if you are unable to use existing tooling. The `getL1Fee` method will be updated to reflect any changes to the L1 Data Fee formula. It's strongly recommended that you do **not** implement the L1 Data Fee formula yourself.

pages/builders/app-developers/transactions/troubleshooting.mdx

@@ -9,8 +9,8 @@ description: Learn how to troubleshoot common problems with transactions.
 ## Transactions stuck in the transaction pool
 
 OP Chain uses EIP-1559, but with different parameters than L1 Ethereum.
-As a result, while the base fee on L1 can grow by up to 12.5% in a twelve second period (in the case of a single 30M gas block), the L2 base fee can grow by up to 77% (in the case of six 30M gas blocks).
-However, it still shrinks by only up to 12.5% in the same twelve second period (if all the blocks are empty).
+As a result, while the base fee on L1 can grow by up to 12.5% in a twelve-second period (in the case of a single 30M gas block), the L2 base fee can grow by up to 77% (in the case of six 30M gas blocks).
+However, it still shrinks by only up to 12.5% in the same twelve-second period (if all the blocks are empty).
 
 If the maximum fee per gas specified by the transaction is less than the block base fee, it does not get included until the base fee drops to below the value in the transaction.
 When this happens, some users may see their transaction become stuck. 

pages/stack/components.mdx

@@ -104,4 +104,4 @@ MultiSig Contracts are smart contracts that carry out actions when they receive
 
 #### Governance tokens
 
-Governance Tokens are widely used to decentralize decision making. Although the exact functionality of a Governance Token varies on a case-by-case basis, the most common mechanisms allow token holders to vote on some subset of decisions that a project must make. Voting can either be carried out directly or via delegation.
+Governance Tokens are widely used to decentralize decision-making. Although the exact functionality of a Governance Token varies on a case-by-case basis, the most common mechanisms allow token holders to vote on some subset of decisions that a project must make. Voting can either be carried out directly or via delegation.

pages/stack/fault-proofs/explainer.mdx

@@ -92,7 +92,7 @@ The capital requirements will be improved in the later stages of Fault Proofs to
 
 ### How large are the bonds expected to be needed to sustain and win a dispute?
 
-The bonds are sized based on the anticipated cost to post a counter claim as well as to deter spamming invalid claims.
+The bonds are sized based on the anticipated cost to post a counter-claim as well as to deter spamming invalid claims.
 As an example, on OP Sepolia, the game [`0xcf8f181497DAD07277781517A76cb131C54A1BEE`](https://sepolia.etherscan.io/address/0xcf8f181497DAD07277781517A76cb131C54A1BEE) shows the escalating bond sizes.
 The list-claims subcommand of op-challenger can also provide a good view of the claims in the game:
 

pages/stack/interop/explainer.mdx

@@ -33,7 +33,7 @@ This means ETH and ERC-20s can seamlessly and securely move across L2s, and inte
 Interoperability allows for horizontally scalable blockchains, a key feature of the Superchain. With Superchain interop, latency can be 1-block (~2 seconds) by optimistically accepting cross-chain messages. 
 
 ## Permissionless dependency set
-The interop protocol works via a dependency set which is configured on a per chain basis and is a unidirectional relationship that defines the set of chains that a chain will accept incoming messages from. 
+The interop protocol works via a dependency set which is configured on a per-chain basis and is a unidirectional relationship that defines the set of chains that a chain will accept incoming messages from. 
 
 This gives the OP Stack an unopinionated and flexible foundation, so chain operators can choose which chains their chains depend on, and it is not a requirement that chains are in each other's dependency set. 
 

pages/stack/security/faq.mdx

@@ -32,7 +32,7 @@ As with anything, modify the OP Stack at your own risk. There is no guarantee th
 
 ### Can I use fault proofs?
 
-**Not yet.** The OP Stack does not currently have a Fault Proof System. **Note that fault proofs do not meaningfully improve the security of a system if that system can be upgraded within the 7 day challenge window ("fast upgrade keys")**. A system with fast upgrade keys is fully dependent on the upgrade keys for security.
+**Not yet.** The OP Stack does not currently have a Fault Proof System. **Note that fault proofs do not meaningfully improve the security of a system if that system can be upgraded within the 7-day challenge window ("fast upgrade keys")**. A system with fast upgrade keys is fully dependent on the upgrade keys for security.
 
 Fault proofs are a key milestone and top priority for the OP Stack. In the meantime, the OP Stack can be shipped with several other excellent security options for systems that want to improve security before fault proofs are available in production.