Sentence casing first batch

Author: bradleycamacho

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

@@ -4,26 +4,26 @@ lang: en-US
 description: Learn about the fundamentals of sending data and tokens between Ethereum and OP Mainnet.
 ---
 
-# Bridging Basics
+# Bridging basics
 
 OP Mainnet is a "Layer 2" system and is fundamentally connected to Ethereum.
 However, OP Mainnet is also a distinct blockchain with its own blocks and transactions.
 App developers commonly need to move data and tokens between OP Mainnet and Ethereum.
 This process of moving data and tokens between the two networks is called "bridging".
 
-## Sending Tokens
+## Sending tokens
 
 One of the most common use cases for bridging is the need to send ETH or ERC-20 tokens between OP Mainnet and Ethereum.
 OP Mainnet has a system called the [Standard Bridge](./standard-bridge) that makes it easy to move tokens in both directions.
 If you mostly need to bridge tokens, make sure to check out the [Standard Bridge](./standard-bridge) guide.
 
-## Sending Data
+## Sending ata
 
 Under the hood, the Standard Bridge is just an application that uses the OP Mainnet [message passing system to send arbitrary data between Ethereum and OP Mainnet](./messaging).
 Applications can use this system to have a contract on Ethereum interact with a contract on OP Mainnet, and vice versa.
 All of this is easily accessible with a simple, clean API.
 
-## Next Steps
+## Next steps
 
 Ready to start bridging?
 Check out these tutorials to get up to speed fast.

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

@@ -6,7 +6,7 @@ description: Important considerations when building custom bridges for OP Mainne
 
 import { Callout } from 'nextra/components'
 
-# Custom Bridges
+# Custom bridges
 
 Custom token bridges are any bridges other than the [Standard Bridge](./standard-bridge).
 You may find yourself in a position where you need to build a custom token bridge because the Standard Bridge doesn't completely support your use case.
@@ -35,7 +35,7 @@ The [Superchain Token List](/chain/tokenlist) exists to help users and developer
 Once you've built and tested your custom bridge, make sure to register any tokens meant to flow through this bridge by [making a pull request against the Superchain Token List repository](https://github.com/ethereum-optimism/ethereum-optimism.github.io#adding-a-token-to-the-list).
 You **must** deploy your bridge to OP Sepolia before it can be added to the Superchain Token List.
 
-## Next Steps
+## Next steps
 
 You can explore several examples of custom bridges for OP Mainnet:
 

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

@@ -6,7 +6,7 @@ description: Learn how bridging works between L1 and L2, how to use it, and what
 
 import { Callout } from 'nextra/components'
 
-# Sending Data Between L1 and L2
+# Sending data between L1 and L2
 
 Smart contracts on L1 (Ethereum) can interact with smart contracts on L2 (OP Mainnet) through a process called "bridging".
 This page explains how bridging works, how to use it, and what to watch out for.
@@ -16,7 +16,7 @@ This page explains how bridging works, how to use it, and what to watch out for.
   For a step-by-step tutorial on how to send data between L1 and L2, check out the [Solidity tutorial](/builders/app-developers/tutorials/cross-dom-solidity).
 </Callout>
 
-## Understanding Contract Calls
+## Understanding contract calls
 
 It can be easier to understand bridging if you first have a basic understanding of how contracts on EVM-based blockchains like OP Mainnet and Ethereum communicate within the *same* network.
 The interface for sending messages *between* Ethereum and OP Mainnet is designed to mimic the standard contract communication interface as much as possible.
@@ -57,7 +57,7 @@ Here you're using the [low-level "call" function](https://docs.soliditylang.org/
 Although these two code snippets look a bit different, they're doing the exact same thing.
 Because of limitations of Solidity, **the OP Stack's bridging interface is designed to look like the second code snippet**.
 
-## Basics of Communication Between Layers
+## Basics of communication between layers
 
 At a high level, the process for sending data between L1 and L2 is pretty similar to the process for sending data between two contracts on Ethereum (with a few caveats).
 Communication between L1 and L2 is made possible by a pair of special smart contracts called the "messenger" contracts.
@@ -121,17 +121,17 @@ contract MyContract {
   You can find the addresses of the `L1CrossDomainMessenger` and the `L2CrossDomainMessenger` contracts on OP Mainnet and OP Sepolia on the [Contract Addresses](/chain/addresses) page.
 </Callout>
 
-## Communication Speed
+## Communication speed
 
 Unlike calls between contracts on the same blockchain, calls between Ethereum and OP Mainnet are *not* instantaneous.
 The speed of a cross-chain transaction depends on the direction in which the transaction is sent.
 
-### For L1 to L2 Transactions
+### For L1 to L2 transactions
 
 Transactions sent from L1 to L2 take **approximately 1-3 minutes** to get from Ethereum to OP Mainnet, or from Sepolia to OP Sepolia.
 This is because the Sequencer waits for a certain number of L1 blocks to be created before including L1 to L2 transactions to avoid potentially annoying [reorgs](https://www.alchemy.com/overviews/what-is-a-reorg).
 
-### For L2 to L1 Transactions
+### For L2 to L1 transactions
 
 Transactions sent from L2 to L1 take **approximately 7 days** to get from OP Mainnet to Ethereum, or from OP Sepolia to Sepolia.
 This is because the bridge contract on L1 must wait for the L2 state to be *proven* to the L1 chain before it can relay the message.
@@ -177,9 +177,9 @@ modifier onlyOwner() {
 }
 ```
 
-## Fees For Sending Data Between L1 and L2
+## Fees for sending data between L1 and L2
 
-### For L1 to L2 Transactions
+### For L1 to L2 transactions
 
 The majority of the cost of an L1 to L2 transaction comes from the smart contract execution on L1.
 When sending an L1 to L2 transaction, you send to the [`L1CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/L1CrossDomainMessenger.sol) contract, which then sends a call to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/OptimismPortal.sol) contract.
@@ -195,7 +195,7 @@ The amount of L1 gas charged increases when more people are sending L1 to L2 tra
   You should always add a buffer of at least 20% to the gas limit for your L1 to L2 transaction to avoid running out of gas.
 </Callout>
 
-### For L2 to L1 Transactions
+### For L2 to L1 transactions
 
 Each message from L2 to L1 requires three transactions:
 
@@ -211,7 +211,7 @@ Each message from L2 to L1 requires three transactions:
 The total cost of an L2 to L1 transaction is therefore the combined cost of the L2 initialization transaction and the two L1 transactions.
 The L1 proof and finalization transactions are typically significantly more expensive than the L2 initialization transaction.
 
-## Understanding the Challenge Period
+## 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.

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

@@ -36,7 +36,7 @@ The Standard Bridge is composed of two contracts, the [`L1StandardBridge`](https
 These two contracts interact with one another via the `CrossDomainMessenger` system for sending messages between Ethereum and OP Mainnet.
 You can read more about the `CrossDomainMessenger` in the guide on [Sending Data Between L1 and L2](./messaging).
 
-### Bridged Tokens
+### Bridged tokens
 
 The Standard Bridge utilizes bridged representations of tokens that are native to another blockchain.
 Before a token native to one chain can be bridged to the other chain, a bridged representation of that token must be created on the receiving side.
@@ -50,7 +50,7 @@ A native token may have more than one bridged representation at the same time.
 Users must always specify which bridged token they wish to use when using the bridge.
 Different bridged representations of the same native token are considered entirely independent tokens.
 
-### Bridging Native Tokens
+### Bridging native tokens
 
 The Standard Bridge uses a "lock-and-mint" mechanism to convert native tokens into their bridged representations.
 This means that **native tokens are locked** into the Standard Bridge on one side, after which **bridged tokens are minted** on the other side.
@@ -129,7 +129,7 @@ The process for bridging a native token involves a few steps.
   This process is identical in both the Ethereum to OP Mainnet and OP Mainnet to Ethereum directions.
 </Steps>
 
-### Bridging Non-Native Tokens
+### Bridging non-native tokens
 
 The Standard Bridge uses a "burn-and-unlock" mechanism to convert bridged representations of tokens back into their native tokens.
 This means that **bridged tokens are burned** on the Standard Bridge on one side, after which **native tokens are unlocked** on the other side.
@@ -237,7 +237,7 @@ The address of this entry is the address of the bridged representation of the to
 
 </Steps>
 
-## Special Considerations
+## Special considerations
 
 ### USDC