@zainbacchus comments

Author: qbzzt

pages/stack/interop/reorg.mdx

@@ -1,7 +1,7 @@
 ---
 title: Interop reorg awareness
 lang: en-US
-description: How the OP Stack enables low-latency interop and avoids the double-spend problem.
+description: How Superchain interop enables low-latency interop and avoids the double-spend problem.
 ---
 
 import { Callout } from 'nextra/components'
@@ -54,54 +54,13 @@ When that happens, the tokens are still on the source chain, but they also on th
 
 </details>
 
-In Ethereum, incorrect state is usually a transient phenomenon.
-On L2, a sequencer can share one block through gossip and then post a different block to L1 (equivocation).
-If a sequencer equivocates, the dependent cross chain messages are reorged out once the block is posted by the sequencer to L1.
-On L1, new block can be replaced through a reorg, but after sufficient time has passed the block is finalized, and is nearly impossible to remove from the blockchain.
+Most solutions to mitigate the double-spend problem rely on [L1 finality](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#finality). However, that solution results in high latency and poor user experience.
 
-The most frequent solution to mitigate the double-spend problem is to wait for L1 finality; however, that solution results in high latency and poor user experience.
-
-## Block safety levels
-
-To mitigate the double-spend problem while delivering a low-latency cross-chain experience, OP Stack interop uses [block safety levels](./explainer#block-safety-levels).
+To mitigate the double-spend problem while delivering a low-latency cross-chain experience, Superchain interop uses [block safety levels](./explainer#block-safety-levels).
 This means users can transfer assets across chains in the Superchain with 1-block latency, and should a reorg happen, either both the source and destination transactions would remain, or both of them would revert.
 In every case, there is no window of opportunity to double spend.
 
-{/* 
-```mermaid
-
-graph LR
-    classDef finalized fill:#CCC
-    classDef safe fill:#8F8
-    classDef unsafe fill:#F89
-
-    subgraph A ["Chain A"]
-      A100["A<sub>100</sub>"]-->A101["A<sub>101</sub>"]-->A102["A<sub>102</sub>"]-->A103["A<sub>103</sub>"]
-    end
-    subgraph B ["Chain B"]
-      B300["B<sub>300</sub>"]-->B301["B<sub>301</sub>"]-->B302["B<sub>302</sub>"]-->B303["B<sub>303</sub>"]
-    end
-    subgraph C ["Chain C"]
-      C200["C<sub>200</sub>"]-->C201["C<sub>201</sub>"]-->C202["C<sub>202</sub>"]-->C203["C<sub>203</sub>"]
-    end
-    A101-.->B302
-    A101-.->B301
-    B300-.->A100
-    B302-.->C203
-    C200-.->B301
-    class C200 finalized
-    class A100,B300,C201,C202 safe
-    class A101,A102,A103,B301,B302,B303,C203 unsafe
-```
-
-In the diagram above, solid arrows are the derivation of a block from the previous block in the chain. 
-Dotted arrows go from the block with the initiating message (the source) to the block with the executing message (the destination).
-Blocks can either be finalized (grey), cross-safe (green), or unsafe (red).
-Blockchains B and C are high traffic, so they write their blocks to L1 quickly, and they are all *local-safe* (written to L1).
-However, blockchain A has only written block A<sub>100</sub> to the blockchain. 
-As a result, block A<sub>101</sub> is unsafe, and so are all the blocks that depend on it, directly (A<sub>102</sub>, B<sub>301</sub>, and B<sub>302</sub>) or indirectly (A<sub>103</sub>, B<sub>303</sub>, and C<sub>203</sub>).
-Some of these blocks may be *local-safe* because they are written to L1, but none of them are *cross-safe* because they depend on a block that isn't.
-*/}
+## Block safety levels
 
 ```mermaid
 
@@ -215,3 +174,9 @@ An L2 reorg could happen after the sequencer is decentralized.
 In that case, there is a deterministic FCU (fork choice update), just as there is on L1.
 At worst, some unsafe blocks need to be recalculated (if one fork is chosen over another).
 */}
+
+## Next steps
+
+- Build a [revolutionary app](/app-developers/get-started) that uses multiple blockchains within the Superchain.
+- Deploy a [SuperchainERC20](./tutorials/deploy-superchain-erc20) to the Superchain.
+- View more [interop tutorials](./tutorials).