Fix a few typos etc

docs/how-arbitrum-works/01-inside-arbitrum-nitro.mdx

@@ -65,17 +65,17 @@ Above this, ArbOS—the Arbitrum Operating System—adds Layer 2 features like c
 
 In the STF, transactions follow a structured workflow: ArbOS first validates format and funds, then charges gas for Layer 2 execution and Layer 1 posting. Geth executes per EVM standards, after which ArbOS updates states and cross-chain elements, generating receipts and logs to conclude the process. For technical details about ArbOS, refer to the [ArbOS deep dive documentation](/how-arbitrum-works/deep-dives/arbos.mdx).
 
-<ImageWithCaption caption="Geth sandwich" src="/img/haw-geth-sandwich.svg" />
+<ImageWithCaption caption="Integrating Geth into the Arbitrum stack" src="/img/haw-geth-sandwich.svg" />
 
 For Stylus contracts using WebAssembly (WASM), execution diverts to a WASM runtime, where contracts access state via specialized host I/O calls. This diversion yields 10-70x faster performance than EVM equivalents and full interoperability for mixed calls. The Geth base lets Ethereum apps run unchanged, while ArbOS and Stylus enable Layer 2 optimizations and high-performance innovations. Consult the [State Transition Function deep dive](/how-arbitrum-works/deep-dives/stf-inputs.mdx) for further mechanics.
 
 ### Step 4: Finality
 
 At this stage, the transaction achieves two complementary levels of finality, each tailored to Arbitrum's security needs.
 
-1. Soft finality emerges immediately upon the inclusion of the Sequencer feed, offering instant acceptance feedback, a commitment to order, and the ability to act without wait times—as noted in the submission phase. This soft finality" relies on the Sequencer's trustworthiness for usability but lacks cryptographic backing.
+1. Soft finality emerges immediately upon the inclusion of the Sequencer feed, offering instant acceptance feedback, a commitment to order, and the ability to act without wait times—as noted in the submission phase. This "soft finality" relies on the Sequencer's trustworthiness for usability but lacks cryptographic backing.
 
-2. Hard finality, conversely, solidifies when the batch posts and confirms on Ethereum, inheriting its consensus security, ensuring public data availability, and making the transaction irreversible. This process typically spans 10-20 minutes, varying with Ethereum block times and batch frequency. Hard finality depends on rollup assertions being confirmed on Ethereum; for more on how assertions work, see the [Assertions deep dive](/how-arbitrum-works/deep-dives/assertions.mdx).
+2. Hard finality, conversely, solidifies when the batch posts and confirms on Ethereum, inheriting its consensus security, ensuring public data availability, and making the transaction irreversible. This process typically spans 10-20 minutes, varying with Ethereum block frequency and batch frequency. Hard finality depends on rollup assertions being confirmed on Ethereum; for more on how assertions work, see the [Assertions deep dive](/how-arbitrum-works/deep-dives/assertions.mdx).
 
 The dual model combines rapid soft finality for seamless experiences with Ethereum-level safeguards for hard finality, along with censorship-resistant paths for assured inclusion. This balance delivers quick feedback alongside strong protections, ideal for high-stakes transactions.
 
@@ -89,15 +89,15 @@ BoLD facilitates a challenge-based defense where honest parties can protect the
 
 Many transactions involve asset or data transfers between Ethereum and Arbitrum, managed through secure bridging protocols. For Parent-to-Child messaging from Ethereum to Arbitrum, options include native token bridging for direct `ETH` deposits, `ERC-20` transfers via the canonical bridge, or support for custom gas tokens. Retryable tickets enable atomic operations with guaranteed retries if execution fails, featuring predictable gas costs and a one-week validity period redeemable by anyone. Direct messaging handles signed EOA messages with verification or unsigned contract messages using address aliasing for security. See the [Parent-to-Child messaging deep dive](/how-arbitrum-works/deep-dives/l1-to-l2-messaging.mdx) for details.
 
-Parent-to-Child transfers from Arbitrum to Ethereum begin with message creation via [`ArbSys.sendTxToL1()`](/build-decentralized-apps/precompiles/02-reference.mdx#arbsys), followed by inclusion in a rollup assertion, a 6.4-day challenge period, and manual Layer 1 execution by any party. Messages validate through Merkle proofs, persist indefinitely until executed, and require manual triggering due to Ethereum's constraints. For details on how rollup assertions work and their role in finality, see the [Assertions deep dive](/how-arbitrum-works/deep-dives/assertions.mdx). See the [Child-to-Parent messaging deep dive](/how-arbitrum-works/deep-dives/l2-to-l1-messaging.mdx) documentation for more details on the messaging process.
+Child-to-Parent transfers from Arbitrum to Ethereum begin with message creation via [`ArbSys.sendTxToL1()`](/build-decentralized-apps/precompiles/02-reference.mdx#arbsys), followed by inclusion in a rollup assertion, a 6.4-day challenge period, and manual Layer 1 execution by any party. Messages validate through Merkle proofs, persist indefinitely until executed, and require manual triggering due to Ethereum's constraints. For details on how rollup assertions work and their role in finality, see the [Assertions deep dive](/how-arbitrum-works/deep-dives/assertions.mdx). See the [Child-to-Parent messaging deep dive](/how-arbitrum-works/deep-dives/l2-to-l1-messaging.mdx) documentation for more details on the messaging process.
 
 The canonical bridge architecture comprises asset contracts on both chains, gateway pairs for specific logic, and routers to direct flows. Its security locks tokens on one layer while minting equivalents on the other, with a seven-day challenge period guarding withdrawals. This setup fosters seamless, unified interactions while safeguarding each chain's integrity.
 
 ### Step 7: The Economics of execution: Gas and fees
 
-Fees accumulate across the transaction lifecycle to fund processing and security. Arbitrum's dual-fee model separates child chain gas fees, which cover EVM computation and storage with [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)-style dynamic pricing, adjusting for congestion, from Parent chain data fees (blobs or calldata). Parent chain data fees account for Ethereum data posting based on compressed batch contributions and apply only to Sequencer submissions. For comprehensive details on how parent chain pricing works, including the adaptive pricing algorithm and cost apportionment, see the [Parent chain pricing deep dive](/how-arbitrum-works/deep-dives/parent-chain-pricing.mdx). For a complete breakdown of how fees are calculated and collected, including both parent and child chain components, refer to the [Gas and fees deep dive](/how-arbitrum-works/deep-dives/gas-and-fees.mdx).
+Fees accumulate across the transaction lifecycle to fund processing and security. Arbitrum's dual-fee model separates child chain gas fees, which cover EVM computation and storage with [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)-style dynamic pricing, adjusting for congestion, from parent chain data fees (blobs or calldata). Parent chain data fees account for Ethereum data posting based on compressed batch contributions and apply only to Sequencer submissions. For comprehensive details on how parent chain pricing works, including the adaptive pricing algorithm and cost apportionment, see the [Parent chain pricing deep dive](/how-arbitrum-works/deep-dives/parent-chain-pricing.mdx). For a complete breakdown of how fees are calculated and collected, including both parent and child chain components, refer to the [Gas and fees deep dive](/how-arbitrum-works/deep-dives/gas-and-fees.mdx).
 
-A gas target is an optimal gas consumption rate/second. Exceeding this rate triggers [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) fee escalations to prevent node overloads and maintain liveness. This rate prioritizes high-value transactions during peaks while deterring spam, ensuring that validators and the Sequencer stay operational, even though parent contracts handle ultimate security. [You can read more about how the child chain gas fees are calculated in this explainer ](/how-arbitrum-works/deep-dives/gas-and-fees#child-chain-gas-fees)
+A gas target is an optimal gas consumption rate/second. Exceeding this rate triggers [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) fee escalations to prevent node overloads and maintain liveness. This rate prioritizes high-value transactions during peaks while deterring spam, ensuring that validators and the Sequencer stay operational, even though parent contracts handle ultimate security. [You can read more about how the child chain gas fees are calculated in this explainer.](/how-arbitrum-works/deep-dives/gas-and-fees#child-chain-gas-fees)
 
 Fee calculation during execution involves assessing child chain gas via EVM standards, estimating parent chain batch impact, applying current pricing, and collecting `ETH` totals. This model covers all costs effectively, with the gas target reinforcing security by keeping validation in sync.
 

docs/how-arbitrum-works/bold/bold-economics-of-disputes.mdx

@@ -73,7 +73,7 @@ While both of these bonds can be any `ERC-20` token and configured to any size,
 
 - Challenge-bonds, per level: 555 `WETH` at the "big-step" level; 79 `WETH` at the "small-step" level - required from validators to open challenges against an assertion observed on the parent chain (Ethereum, in the case of Arbitrum One), for each level. Note that “level” corresponds to the level of granularity over which the interactive bisection game gets played, starting at the block level, moving on to a range of <a data-quicklook-from="wasm">WASM</a> execution steps, and then finally to the level of a single execution step. For more details on the concept of "levels" in BoLD challenges, see [Challenge resolution](/how-arbitrum-works/bold/bold-technical-deep-dive.mdx#challenge-resolution) section in the Technical deep dive.
 
-We calculated these values carefully to optimize for the resource ratio (explained later) and gas costs in the event of an attack, as described in [BoLD whitepaper](https://arxiv.org/abs/2404.10491). This effectively means that an entity that has already posted a bond to propose an assertion does not need to post a separate assertion bond to challenge an invalid state assertion that they observe. To be clear, the validator would still require 555 `ETH` and 79 `ETH` for ongoing challenges. These additional challenge bond amounts are required to participate in the interactive dispute game (back and forth) and narrow down the disagreement to a single step of execution that can be proven on Ethereum. The 555 `ETH` and 79 `ETH` challenge bonds can accumulate via a trustless bonding pool, and do not all have to be provided by the validator that initiated the challenge. These bonds are refundable at the end of a challenge and can also be assembled by the community using a trustless bonding pool.
+We calculated these values carefully to optimize for the resource ratio (explained later) and gas costs in the event of an attack, as described in [BoLD whitepaper](https://arxiv.org/abs/2404.10491). This effectively means that an entity that has already posted a bond to propose an assertion does not need to post a separate assertion bond to challenge an invalid state assertion that they observe. To be clear, the validator would still require 555 `ETH` and 79 `ETH` for ongoing challenges. These additional challenge bond amounts are required to participate in the interactive dispute game (back and forth) and narrow down the disagreement to a single step of execution that can be proven on Ethereum. The 555 `ETH` and 79 `ETH` challenge bonds can accumulate via a trustless bonding pool, and do not all have to be provided by the validator that initiated the challenge. These bonds are refundable at the end of a challenge.
 
 #### Centralization concerns
 

docs/how-arbitrum-works/bold/gentle-introduction.mdx

@@ -10,7 +10,7 @@ sme: leeederek
 
 import ImageZoom from '@site/src/components/ImageZoom';
 
-This introduction is for those who want to learn about <a data-quicklook-from="bold">BoLD</a>: a new dispute protocol for optimistic Rollups that enables permissionless validation for <a data-quicklook-from="arbitrum">Arbitrum</a> chains. BoLD stands for Bounded Liquidity Delay and is active on <a data-quicklook-from="arbitrum-one">Arbitrum One</a>, <a data-quicklook-from="arbitrum-nova">Arbitrum Nova</a>, and Arbitrum Sepolia.
+This introduction is for those who want to learn about <a data-quicklook-from="bold">BoLD</a>: a new dispute protocol for optimistic rollups that enables permissionless validation for <a data-quicklook-from="arbitrum">Arbitrum</a> chains. BoLD stands for Bounded Liquidity Delay and is active on <a data-quicklook-from="arbitrum-one">Arbitrum One</a>, <a data-quicklook-from="arbitrum-nova">Arbitrum Nova</a>, and Arbitrum Sepolia.
 
 ## What exactly is BoLD?