diff --git a/pages/stack/transactions/_meta.json b/pages/stack/transactions/_meta.json
index ebc6603e2..83c9732fa 100644
--- a/pages/stack/transactions/_meta.json
+++ b/pages/stack/transactions/_meta.json
@@ -2,8 +2,8 @@
     "fees": "Transaction fees",
     "transaction-flow": "Transaction flow",
     "transaction-finality" : "Transaction finality",
+    "cross-domain": "Cross domain transaction",
     "deposit-flow": "Deposit flow",
     "withdrawal-flow": "Withdrawal flow",
-    "forced-transaction": "Forced transaction",
-    "cross-domain": "Cross domain transaction"
+    "forced-transaction": "Forced transaction"
 }
diff --git a/pages/stack/transactions/cross-domain.mdx b/pages/stack/transactions/cross-domain.mdx
index a6f1b9ee3..d4a1ee4ec 100644
--- a/pages/stack/transactions/cross-domain.mdx
+++ b/pages/stack/transactions/cross-domain.mdx
@@ -1,14 +1,14 @@
 ---
 title: Cross-Domain Overview
 description: >-
-  An overview of the lifecycle of an OP Stack cross-chain transaction, detailing
+  An overview of the lifecycle of an OP Stack cross-domain transaction, detailing
   the flow of transactions between Layer 2 and Layer 1.
 lang: en-US
-content_type: guide
+content_type: reference
 topic: cross-domain-overview
 personas:
   - protocol-developer
-  - chain-operator
+  - app-operator
 categories:
   - protocol
   - cross-domain-messaging
@@ -27,9 +27,6 @@ import { Callout, Steps } from 'nextra/components'
 
 This overview provides a detailed walkthrough of the lifecycle of cross-chain transactions, covering deposits, withdrawals, and transaction flows between L1 and L2. The diagram below illustrates the main components and steps involved.
 
-![Lifecycle of an OP Stack Crosschain Transaction.](/img/op-stack/protocol/op-cross-chain-txn.jpeg)
-_Figure 1: The Lifecycle of an OP Stack Crosschain Transaction_
-
 Cross-domain communication in the OP Stack involves moving assets and messages between L1 and L2. Key components, such as bridges, messengers, and portals, ensure these transactions are executed securely and transparently. This page breaks down the lifecycle of a cross-chain transaction into three main flows: Deposit Flow, Transaction Flow (Tx Flow), and Withdrawal Flow.
 
 ## Deposit Flow
@@ -37,43 +34,46 @@ Cross-domain communication in the OP Stack involves moving assets and messages b
 Depositing assets from L1 to L2 follows a structured process that ensures funds are securely transferred and credited to the user's L2 account. The steps are as follows:
 
 1.  **User Initiation (L1 Standard Bridge):**
-  The user initiates a deposit by sending assets (e.g., ETH or tokens) to the L1 Standard Bridge contract. This contract receives the assets and prepares a message to relay to L2.
+    The user initiates a deposit by sending assets (e.g., ETH or tokens) to the L1 Standard Bridge contract. This contract receives the assets and prepares a message to relay to L2.
 
 2.  **Message Relaying (L1 CrossDomain Messenger):**
-  The L1 Standard Bridge sends a message to the L1 CrossDomain Messenger, which is responsible for handling inter-layer communication. The messenger emits a `TransactionDeposited` event to signal the start of the deposit process.
+    The L1 Standard Bridge sends a message to the L1 CrossDomain Messenger, which is responsible for handling inter-layer communication. The messenger emits a `TransactionDeposited` event to signal the start of the deposit process.
 
 3.  **Processing on L2 (OptimismPortal):**
-  The message is received by the OptimismPortal on L2. Here, the deposited assets are held securely until the transaction is finalized. The portal initiates the deposit transaction, updating the user's balance on L2.
+    The message is received by the OptimismPortal. Here, the deposited assets are held securely until the transaction is finalized. The portal initiates the deposit transaction, updating the user's balance on L2.
 
 4.  **Finalization (L2 CrossDomain Messenger):**
-  The L2 CrossDomain Messenger processes the deposit by updating the user's account balance, and making the assets available for use on L2.
+    The L2 CrossDomain Messenger processes the deposit deriving the message from L1 into the L2. If this is a deposit of ETH or a token the user's account balance will be reflected in their account making the assets available for use on L2.
+
+For a more detailed breakdown of the deposit process, refer to the [deposit](https://specs.optimism.io/protocol/deposits.html) specs.
 
 ## Transaction (Tx) Flow
 
 The transaction flow covers the steps involved in cross-domain message passing and state updates between L1 and L2:
 
 1.  **Message Queuing (L2ToL1MessagePasser):**
-During cross-layer communication, certain messages are queued for processing. The `L2ToL1MessagePasser` prepares these messages for state updates or withdrawals, ensuring they are available for proving and relaying.
+    During cross-layer communication, certain messages are queued for processing. The `L2ToL1MessagePasser` prepares these messages for state updates or withdrawals, ensuring they are available for proving and relaying.
 
-2.  **State Reading and Proving (L2OutputOracle):**
-The `L2OutputOracle` plays a critical role in validating state changes between L1 and L2. It reads the current state and submits a proposal using `proposeL2Output()`. This proposal includes information about queued messages or state changes that need to be relayed to L1.
+2.  **State Reading and Proving (DisputeGameFactory and OptimismPortal):**
+    The `DisputeGameFactory` and `OptimismPortal` play a critical role in validating L2 state changes on L1. New state proposals are created when someone creates a new dispute game through the `DisputeGameFactory`. This proposal includes information about queued messages or state changes that need to be relayed to L1. Users can prove their withdrawals through the `OptimismPortal` and then finalize on the `OptimismPortal` once the challenge period has passed.
 
 3.  **Message Relay (CrossDomain Messengers):**
-Messages are relayed between the L1 and L2 CrossDomain Messengers as part of transaction execution. This includes updating state or finalizing transactions on the target layer.
-
+    Messages are relayed between the L1 and L2 CrossDomain Messengers as part of transaction execution. This includes updating state or finalizing transactions on the target layer.
 
 ## Withdrawal Flow
 
 Withdrawing assets from L2 back to L1 involves a multi-step process to ensure the transaction is validated and executed correctly:
 
-1.  **User Initiation (L2 Standard Bridge):**
-The withdrawal process starts when the user calls the `withdraw()` function on the L2 Standard Bridge, specifying the amount and asset to be withdrawn.
+1.  **User Initiation:**
+    The withdrawal process starts when the user calls the `withdraw()` function on the L2 Standard Bridge, specifying the amount and asset to be withdrawn.
 
-2.  **Message Relay (L2 CrossDomain Messenger):**
-The L2 CrossDomain Messenger receives the withdrawal request and relays the message for processing. It may involve queuing the message in the `L2ToL1MessagePasser` for further steps.
+2.  **Message Relay:**
+    The L2 CrossDomain Messenger receives the withdrawal request and relays the message for processing. It may involve queuing the message in the `L2ToL1MessagePasser` for further steps.
 
-3.  **Proving and Finalization (L2OutputOracle):**
-The withdrawal message is proven using the `L2OutputOracle`, which submits a state output proving that the withdrawal is legitimate. This step involves reading the state and generating the required proofs during the proving time.
+3.  **Proving:**
+    The withdrawal message is proven using the `DisputeGameFactory` and `OptimismPortal`. New state outputs are created as dispute games through the `DisputeGameFactory`. The `OptimismPortal` references those dispute games. The user proves the withdrawal on the `OptimismPortal`. This step involves reading the state and generating the required proofs during the proving time.
 
 4.  **Finalization (L1 CrossDomain Messenger and L1 Standard Bridge):**
-Once the withdrawal is proven, the message is finalized by the L1 CrossDomain Messenger. The L1 Standard Bridge completes the process by releasing the withdrawn assets to the user's L1 account.
+    Once the withdrawal is proven, the user waits for the challenge period to pass. Then they finalize it on the `OptimismPortal` and the message is finalized by the L1 CrossDomain Messenger. The L1 Standard Bridge completes the process by releasing the withdrawn assets to the user's L1 account.
+
+For a more detailed breakdown of the withdrawal process, refer to the [withdrawal](https://specs.optimism.io/protocol/withdrawals.html) specs.
diff --git a/pages/stack/transactions/deposit-flow.mdx b/pages/stack/transactions/deposit-flow.mdx
index c71c92870..4ab4d1109 100644
--- a/pages/stack/transactions/deposit-flow.mdx
+++ b/pages/stack/transactions/deposit-flow.mdx
@@ -31,6 +31,10 @@ This guide explains the deposit flow process for L2 deposit transactions, trigge
 The process is somewhat similar to the way [most networking stacks work](https://en.wikipedia.org/wiki/Encapsulation_\(networking\)).
 Information is encapsulated in lower layer packets on the sending side and then retrieved and used by those layers on the receiving side while going up the stack to the receiving application.
 
+<Callout type="info">
+    If the sequencer is down, deposits will still be processed through [forced inclusion](/stack/transactions/forced-transaction).
+</Callout>
+
 ![Deposit Flow Diagram.](/img/op-stack/protocol/deposit-flow-dark-mode.svg)
 
 ## L1 processing
diff --git a/pages/stack/transactions/withdrawal-flow.mdx b/pages/stack/transactions/withdrawal-flow.mdx
index 162f1cb52..9ee9eab17 100644
--- a/pages/stack/transactions/withdrawal-flow.mdx
+++ b/pages/stack/transactions/withdrawal-flow.mdx
@@ -38,7 +38,7 @@ Withdrawals require the user to submit three transactions:
 
 ## Withdrawal initiating transaction
 
-1.  On L2, a user, either an externally owned account (EOA) directly or a contract acting on behalf of an EOA, calls the [`sendMessage`](https://github.com/ethereum-optimism/optimism/blob/1a8fe18c4989bfd0852a8873f30422542ad4f44d/packages/contracts-bedrock/src/universal/CrossDomainMessenger.sol#L191) function of the [`L2CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/1a8fe18c4989bfd0852a8873f30422542ad4f44d/packages/contracts-bedrock/src/L2/L2CrossDomainMessenger.sol#L21) contract.
+1.  On L2, a user, either an externally owned account (EOA) directly or a contract acting on behalf of an EOA, calls the [`sendMessage`](https://github.com/ethereum-optimism/optimism/blob/ef7a933ca7f3d27ac40406f87fea25e0c3ba2016/packages/contracts-bedrock/src/universal/CrossDomainMessenger.sol#L191) function of the [`L2CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/ef7a933ca7f3d27ac40406f87fea25e0c3ba2016/packages/contracts-bedrock/src/L2/L2CrossDomainMessenger.sol#L21) contract.
 
     This function accepts three parameters:
 
@@ -64,7 +64,7 @@ Withdrawals require the user to submit three transactions:
 
 ## Withdrawal proving transaction
 
-Once an output root that includes the `MessagePassed` event is published to L1, the next step is to prove that the message hash really is in L2. Typically this is done by viem.
+Once an output root that includes the `MessagePassed` event is published to L1, the next step is to prove that the message hash really is in L2. Typically this is abstracted away using tools like viem.
 
 ### Offchain processing
 
diff --git a/public/img/op-stack/protocol/op-cross-chain-txn.jpeg b/public/img/op-stack/protocol/op-cross-chain-txn.jpeg
deleted file mode 100644
index 396668654..000000000
Binary files a/public/img/op-stack/protocol/op-cross-chain-txn.jpeg and /dev/null differ
diff --git a/words.txt b/words.txt
index fb23b2231..4d347dc57 100644
--- a/words.txt
+++ b/words.txt
@@ -1,7 +1,7 @@
-ACCOUNTQUEUE
 accountqueue
-ACCOUNTSLOTS
+ACCOUNTQUEUE
 accountslots
+ACCOUNTSLOTS
 ACDC
 ADDI
 ADDIU
@@ -9,58 +9,58 @@ ADDU
 airgap
 Allnodes
 allocs
-Alphanet
 alphanet
-Alphanets
+Alphanet
 alphanets
+Alphanets
 altda
 ANDI
 Ankr
 Apeworx
 Arweave
 authrpc
-Autorelay
 autorelay
+Autorelay
 autorelayer
 basefee
 bcde
-Betanet
 betanet
-Betanets
+Betanet
 betanets
+Betanets
 BGEZ
 BGTZ
 Biconomy
 BLEZ
-BLOBPOOL
 blobpool
+BLOBPOOL
 blobspace
 Blockdaemon
 blockhash
 blocklists
-BLOCKLOGS
 blocklogs
-BLOCKPROFILERATE
+BLOCKLOGS
 blockprofilerate
+BLOCKPROFILERATE
 Blockscout
-Blockspace
 blockspace
+Blockspace
 blocktime
-Blocktimes
 blocktimes
-BLOOMFILTER
+Blocktimes
 bloomfilter
+BLOOMFILTER
 BLTZ
 Bootcamp
 bootnode
-BOOTNODES
-Bootnodes
 bootnodes
+Bootnodes
+BOOTNODES
 bottlenecked
-Brotli
 brotli
-Callouts
+Brotli
 callouts
+Callouts
 CCIP
 cdef
 Celestia
@@ -73,65 +73,65 @@ chaosnet
 Chugsplash
 Clabby
 codebases
-Collateralized
 collateralized
+Collateralized
 compr
 Comprensive
-COMPUTEPENDINGBLOCK
 computependingblock
+COMPUTEPENDINGBLOCK
 confs
 corsdomain
 counterfactually
-Crosschain
 crosschain
+Crosschain
 Crossmint
 daserver
-DATACAP
 datacap
-DATADIR
+DATACAP
 datadir
+DATADIR
 Defi
 Defillama's
-Devnet
 devnet
-Devnets
+Devnet
 devnets
+Devnets
 devs
 direnv
-DISABLETXPOOLGOSSIP
 disabletxpoolgossip
-Discv
+DISABLETXPOOLGOSSIP
 discv
+Discv
 DIVU
 Drand
 dripcheck
 Drippie
 Eigen
 EIPs
-ENABLEDEPRECATEDPERSONAL
 enabledeprecatedpersonal
+ENABLEDEPRECATEDPERSONAL
 enginekind
-Erigon
 erigon
-ETHERBASE
+Erigon
 etherbase
+ETHERBASE
 Ethernity
 Ethernow
-ETHSTATS
 ethstats
-EVMTIMEOUT
+ETHSTATS
 evmtimeout
+EVMTIMEOUT
 executability
 exfiltrate
-EXITWHENSYNCED
 exitwhensynced
+EXITWHENSYNCED
 extensibly
-EXTRADATA
 extradata
+EXTRADATA
 Farcaster
 Faultproof
-FDLIMIT
 fdlimit
+FDLIMIT
 Flashblocks
 Flashbots
 forkable
@@ -140,51 +140,51 @@ FPVM
 FPVMs
 Fraxtal
 Funct
-GASCAP
 gascap
+GASCAP
 gaslessly
-GCMODE
 gcmode
+GCMODE
 Gelato
 gifs
-GLOBALQUEUE
 globalqueue
-GLOBALSLOTS
+GLOBALQUEUE
 globalslots
+GLOBALSLOTS
 gokzg
 growthepie
 hardfork
 hardforks
-HEALTHCHECK
 healthcheck
+HEALTHCHECK
 healthchecks
-HISTORICALRPC
 historicalrpc
-HISTORICALRPCTIMEOUT
+HISTORICALRPC
 historicalrpctimeout
-HOLESKY
-Holesky
+HISTORICALRPCTIMEOUT
 holesky
+Holesky
+HOLESKY
 IERC
-IGNOREPRICE
 ignoreprice
+IGNOREPRICE
 Immunefi
-Inator
 inator
-INFLUXDBV
+Inator
 influxdbv
+INFLUXDBV
 initcode
-IPCDISABLE
 ipcdisable
+IPCDISABLE
 ipcfile
-IPCPATH
 ipcpath
+IPCPATH
 IPFS
 JALR
-JOURNALREMOTES
 journalremotes
-JSPATH
+JOURNALREMOTES
 jspath
+JSPATH
 jwtsecret
 Keccak
 leveldb
@@ -193,34 +193,34 @@ Lisk
 logfile
 logfmt
 Mainnets
-MAXAGE
 maxage
-MAXBACKUPS
+MAXAGE
 maxbackups
-MAXPEERS
+MAXBACKUPS
 maxpeers
-MAXPENDPEERS
+MAXPEERS
 maxpendpeers
-MAXPRICE
+MAXPENDPEERS
 maxprice
-MEMPROFILERATE
+MAXPRICE
 memprofilerate
-Merkle
+MEMPROFILERATE
 merkle
+Merkle
 MFHI
 MFLO
 Mgas
 Minato
-MINFREEDISK
 minfreedisk
-MINSUGGESTEDPRIORITYFEE
+MINFREEDISK
 minsuggestedpriorityfee
+MINSUGGESTEDPRIORITYFEE
 Mintable
 Mintplex
 MIPSEVM
 Mitigations
-Monitorism
 monitorism
+Monitorism
 Moralis
 Mordor
 mountpoint
@@ -230,144 +230,144 @@ MTHI
 MTLO
 MULT
 multiaddr
-Multichain
 multichain
+Multichain
 multiclient
 multisigs
 MULTU
 nethermind
-NETRESTRICT
 netrestrict
-NETWORKID
+NETRESTRICT
 networkid
-NEWPAYLOAD
+NETWORKID
 newpayload
+NEWPAYLOAD
 nextra
-NOCOMPACTION
 nocompaction
-NODEKEY
+NOCOMPACTION
 nodekey
-NODEKEYHEX
+NODEKEY
 nodekeyhex
+NODEKEYHEX
 nodename
 Nodies
-NODISCOVER
 nodiscover
-NOLOCALS
+NODISCOVER
 nolocals
-NOPREFETCH
+NOLOCALS
 noprefetch
-NOPRUNING
+NOPREFETCH
 nopruning
-NOSYNCSERVE
+NOPRUNING
 nosyncserve
+NOSYNCSERVE
 Numba
 NVME
-Offchain
 offchain
+Offchain
 opchaina
 opchainb
-OPCM
 opcm
+OPCM
 Openfort
 oplabs
 opnode's
 outfile
 outperformance
 pcscdpath
-Pectra
 pectra
+Pectra
 Pectra's
-Peerstore
 peerstore
+Peerstore
 peerstores
-Permissioned
 permissioned
+Permissioned
 permissioning
-Permissionless
 permissionless
+Permissionless
 permissionlessly
 Perps
 Peta
 Pimlico
 POAP
 POAPs
-PPROF
 pprof
-Precommitments
+PPROF
 precommitments
+Precommitments
 preconfigured
 predeploy
-Predeployed
 predeployed
-Predeploys
+Predeployed
 predeploys
+Predeploys
 prefunded
-Preimage
 preimage
-PREIMAGES
+Preimage
 preimages
+PREIMAGES
 preinstall
-Preinstalls
 preinstalls
-Prestate
+Preinstalls
 prestate
+Prestate
 prestates
 PREVRANDAO
-PRICEBUMP
 pricebump
-PRICELIMIT
+PRICEBUMP
 pricelimit
+PRICELIMIT
 productionize
 productionized
 Protip
 Proxied
-Proxyd
 proxyd
+Proxyd
 Pyth
 Pyth's
 QRNG
-Quicknode
 quicknode
+Quicknode
 quickstarts
 rebalancing
 reemit
 Reemitting
-Regenesis
 regenesis
+Regenesis
 Reimagine
-REJOURNAL
 rejournal
-REMOTEDB
+REJOURNAL
 remotedb
+REMOTEDB
 Reown
 Reown's
 replayability
 replayor
 reposts
 reproven
-REQUIREDBLOCKS
 requiredblocks
+REQUIREDBLOCKS
 rollouts
-Rollups
 rollups
+Rollups
 Routescan
 rpckind
-RPCPREFIX
 rpcprefix
+RPCPREFIX
 rpcs
 RPGF
-Runbooks
 runbooks
+Runbooks
 RWAs
 safedb
 Schnorr
-SEPOLIA
-Sepolia
 sepolia
+Sepolia
+SEPOLIA
 seqnr
-SEQUENCERHTTP
 sequencerhttp
+SEQUENCERHTTP
 serv
 signup
 SLLV
@@ -376,16 +376,16 @@ SLTIU
 SLTU
 smartcard
 snapshotlog
-Snapsync
 snapsync
+Snapsync
 Solana
 Soneium
 soyboy
 Spearbit
 SRAV
 SRLV
-Stablecoins
 stablecoins
+Stablecoins
 statefulset
 structs
 subcomponents
@@ -394,21 +394,21 @@ subheaders
 subsecond
 SUBU
 Sunnyside
-SUPERCHAIN
-Superchain
 superchain
+Superchain
+SUPERCHAIN
 Superchain's
 superchainerc
 Superlend
 Superloans
 Superscan
 Superseed
-Supersim
 supersim
-SYNCMODE
+Supersim
 syncmode
-SYNCTARGET
+SYNCMODE
 synctarget
+SYNCTARGET
 syscalls
 SYSCON
 thirdweb
@@ -422,8 +422,8 @@ Twei
 txfeecap
 txmgr
 txns
-TXPOOL
 txpool
+TXPOOL
 txproxy
 txproxyd
 uncensorable
@@ -434,21 +434,21 @@ Unprotect
 unsubmitted
 UPNP
 upstreaming
-VERKLE
 verkle
-VHOSTS
+VERKLE
 vhosts
-Viem
+VHOSTS
 viem
-Viem's
+Viem
 viem's
-VMDEBUG
+Viem's
 vmdebug
-VMODULE
+VMDEBUG
 vmodule
+VMODULE
 xlarge
 XORI
 ZKPs
 ZKVM
-Zora
 zora
+Zora