Suggested Docs fixes

pages/stack/differences.mdx

@@ -16,7 +16,7 @@ However, there are some minor differences between the behavior of Ethereum and O
 
 ### Bridging - Deposit Transactions
 
-Deposit transactions don't exist on L1's, and are how transactions on an L2 can be initiated from the L1. Importantly, this is how bridge applications can get L1 ETH or tokens into an L2 OP Stack chain. You can read more on deposit transactions [here](/stack/transactions/deposit-flow).
+Deposit transactions don't exist on L1s, and are how transactions on an L2 can be initiated from the L1. Importantly, this is how bridge applications can get L1 ETH or tokens into an L2 OP Stack chain. You can read more on deposit transactions [here](/stack/transactions/deposit-flow).
 
 ### Bridging - Withdrawal Transactions and Fault Proofs
 
@@ -27,7 +27,7 @@ Withdrawal transactions are how the state of the L2 rollup can be proven to the
 | Opcode       | Solidity Equivalent | Behavior                                                                                                                                                                                                                                                |
 | ------------ | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `COINBASE`   | `block.coinbase`    | Returns the address of the current Sequencer's fee wallet. Effectively the same as Ethereum with the caveat that the value typically does not change from block to block.                                                                               |
-| `PREVRANDAO` | `block.prevrandao`  | Set **pseudorandomly** for each block by the Sequencer as opposed to the stronger guarantees provided by [RANDAO](https://eips.ethereum.org/EIPS/eip-4399) on Ethereum.                                                                                 |
+| `PREVRANDAO` | `block.prevrandao`  | Returns the PREVRENDAO (the most recent [RANDAO](https://eips.ethereum.org/EIPS/eip-4399)) value of L1 at the current L1 origin block.                                                                                                                  |
 | `ORIGIN`     | `tx.origin`         | If the transaction is an L1 ⇒ L2 transaction triggered by a smart contract on L1, then `tx.origin` is set to the [aliased address](#address-aliasing) of the address that triggered the L1 ⇒ L2 transaction. Otherwise, this opcode behaves normally.   |
 | `CALLER`     | `msg.sender`        | If the transaction is an L1 ⇒ L2 transaction triggered by a smart contract on L1, and this is the first call frame (rather than an internal transaction from one contract to another), the same [address aliasing](#address-aliasing) behavior applies. |
 

pages/stack/interop/assets.mdx

@@ -13,11 +13,11 @@ Documentation covering SuperchainERC20, Superchain WETH, Supersim, and how to tr
 <Cards>
   <Card title="SuperchainERC20" href="/stack/interop/assets/superchain-erc20" />
 
-  <Card title="SuperchainWETH (Interoperable ETH)" href="/stack/interop/assets/superchain-weth" />
-
   <Card title="How to transfer a SuperchainERC20" href="/stack/interop/assets/transfer-superchainERC20" />
 
   <Card title="How to deploy assets using SuperchainERC20" href="/stack/interop/assets/deploy-superchain-erc20" />
 
   <Card title="Best practices for SuperchainERC20" href="/stack/interop/assets/superchainerc20-best-practices" />
+
+  <Card title="SuperchainWETH (Interoperable ETH)" href="/stack/interop/assets/superchain-weth" />
 </Cards>

pages/stack/interop/op-supervisor.mdx

@@ -33,7 +33,7 @@ OP Supervisor verifies messages between different chains in the OP Stack, reduci
 
 ## Log data indexing and management
 
-OP Supervisor acts as a hub for indexing data that every `op-node` needs to cross-verify with other chains, centralizing the process of managing interoperability data. Maintains the integrity of cross-chain interactions by tracking safety changes⁠ across the Superchain, ensuring consistent application of invalid dependency resolutions. ⁠
+OP Supervisor acts as a hub for indexing data that every `op-node` needs to cross-verify with other chains, centralizing the process of managing interoperability data. It maintains the integrity of cross-chain interactions by tracking safety changes⁠ across the Superchain, ensuring consistent application of invalid dependency resolutions. ⁠
 
 `op-supervisor` indexes two types of cross-chain dependencies:
 
@@ -46,11 +46,11 @@ OP Supervisor provides an interface for `op-node` to query cross-chain safety in
 
 Key API methods include:
 
-| Method                                    | Description                                                                           |
+| Method(s)                                    | Description                                                                           |
 | ----------------------------------------- | ------------------------------------------------------------------------------------- |
-| `UnsafeView` and `SafeView`               | Returns the Local and Cross heads for their respective levels                         |
+| `UnsafeView` and `SafeView`               | Return the Local and Cross heads for their respective levels                         |
 | `DerivedFrom`                             | OP Nodes use to check the L1 source of the Supervisor (needed for Safe Head tracking) |
-| `UpdateLocalSafe` and `UpdateLocalUnsafe` | Tells the Supervisor when the Node's heads change                                     |
+| `UpdateLocalSafe` and `UpdateLocalUnsafe` | Tell the Supervisor when the Node's heads change                                     |
 | `Finalized`                               | Returns the Finalized Head                                                            |
 | `UpdateFinalizedL1`                       | Signals to the Supervisor new finality signals                                        |
 | `CheckMessage`                            | Checks logs in the DB directly in tests                                               |

pages/stack/smart-contracts.mdx

@@ -79,7 +79,7 @@ of 13 owners. This meets the 75% threshold requirement for a Stage 1 rollup
 outlined in [L2Beat's Stages framework](https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52)
 2.  Reassigning the role of Guardian from the Foundation to a new Guardian Safe 
 with the Security Council Safe as its sole owner. This moves the Superchain 
-closer to satisfying the 1 week exit window 5 requirement for Stage 1. 
+closer to satisfying the 1 week exit window requirement for Stage 1. 
     *   Additionally the Foundation is appointed to the new DeputyGuardian role 
         which is able to act as Guardian through the Guardian Safe. This 
         appointment can be revoked by the Security Council Safe at any time.
@@ -355,7 +355,7 @@ optionally halt if using the wrong version.
 
 #### SystemConfig
 
-The `SystemConfig` contract is helps manage configuration of an OP Stack 
+The `SystemConfig` contract helps manage configuration of an OP Stack 
 network. Much of the network's configuration is stored on L1 and picked up by 
 L2 as part of the derivation of the L2 chain. The contract also contains 
 references to all other contract addresses for the chain.
@@ -399,7 +399,7 @@ Architecture (ISA).
 
 #### PreimageOracle
 
-The `PreimageOracle` contract for storing permissioned pre-images.
+The `PreimageOracle` contract is used for storing permissioned pre-images.
 
 #### DEPRECATED - L2OutputOracle