onflow · briandoyle81 · Oct 17, 2025 · Oct 17, 2025
diff --git a/docs/blockchain-development-tutorials/cadence/getting-started/index.md b/docs/blockchain-development-tutorials/cadence/getting-started/index.md
@@ -21,6 +21,18 @@ keywords:
 
 The Cadence is designed for the next generation of apps, games, and digital assets. This comprehensive tutorial series will guide you from setting up your development environment to deploying production-ready applications on Flow's mainnet while a complete Counter application that demonstrates all essential Flow development patterns.
 
+<div style={{ position: 'relative', paddingBottom: '56.25%', height: 0, overflow: 'hidden', maxWidth: '100%' }}>
+  <iframe 
+    style={{ position: 'absolute', top: 0, left: 0, width: '100%', height: '100%' }}
+    src="https://www.youtube.com/embed/Bagn8kGllCU?si=5FUZit9bSrBCVGPk" 
+    title="YouTube video player" 
+    frameborder="0" 
+    allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" 
+    referrerpolicy="strict-origin-when-cross-origin" 
+    allowfullscreen
+  ></iframe>
+</div>
+
 ## What You'll Learn
 
 In this tutorial series, you'll discover how to:
@@ -73,7 +85,7 @@ Tutorial: [Production Deployment]
 After completing these tutorials, you'll be equipped with the fundamental skills needed for Flow development. Consider exploring our other tutorial series to expand your blockchain development expertise:
 
 - [Cross-VM Apps] - Build applications that integrate Flow EVM and Cadence
-- [Native VRF] - Implement verifiable random functions in your applications  
+- [Native VRF] - Implement verifiable random functions in your applications
 - [Token Launch] - Create and launch tokens on Flow
 
 <!-- Relative links -->
@@ -84,4 +96,4 @@ After completing these tutorials, you'll be equipped with the fundamental skills
 [Production Deployment]: ./production-deployment.md
 [Cross-VM Apps]: ../../cross-vm-apps/introduction.md
 [Native VRF]: ../../native-vrf/index.md
-[Token Launch]: ../../tokens/index.md
+[Token Launch]: ../../tokens/index.md
diff --git a/docs/build/cadence/basics/mev-resistance.md b/docs/build/cadence/basics/mev-resistance.md
@@ -11,65 +11,83 @@ keywords:
   - Blockchain Security
 ---
 
-# How Flow Suppresses MEV to Ensure Equitable Access  
+# How Flow Suppresses MEV to Ensure Equitable Access
 
-## The Hidden Cost of MEV in Decentralized Systems  
+<div style={{ position: 'relative', paddingBottom: '56.25%', height: 0, overflow: 'hidden', maxWidth: '100%' }}>
+  <iframe 
+    style={{ position: 'absolute', top: 0, left: 0, width: '100%', height: '100%' }}
+    src="https://www.youtube.com/embed/9hyPqORY1vI?si=sNn0Y4ECmjaBXPGN" 
+    title="YouTube video player" 
+    frameborder="0" 
+    allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" 
+    referrerpolicy="strict-origin-when-cross-origin" 
+    allowfullscreen
+  ></iframe>
+</div>
 
-One of the most under-discussed benefits of decentralization is **equitable access**. Ideally, the value and quality-of-service you receive from a decentralized platform should not depend on your identity, computing power, or personal connections. However, **Maximal Extractable Value (MEV)** poses a significant threat to this principle.  
+## The Hidden Cost of MEV in Decentralized Systems
 
-MEV allows block producers to manipulate transaction ordering for profit—often at the direct expense of users. The ability to front-run, back-run, or sandwich transactions can extract value from ordinary users, reinforcing inequalities rather than eliminating them. In most blockchain networks, MEV is not just an unfortunate side effect; it is structurally embedded in how transactions are processed.  
+One of the most under-discussed benefits of decentralization is **equitable access**. Ideally, the value and quality-of-service you receive from a decentralized platform should not depend on your identity, computing power, or personal connections. However, **Maximal Extractable Value (MEV)** poses a significant threat to this principle.
 
-## Why MEV Persists on Most Blockchains  
+MEV allows block producers to manipulate transaction ordering for profit—often at the direct expense of users. The ability to front-run, back-run, or sandwich transactions can extract value from ordinary users, reinforcing inequalities rather than eliminating them. In most blockchain networks, MEV is not just an unfortunate side effect; it is structurally embedded in how transactions are processed.
 
-MEV is difficult to prevent on most blockchains because **each block has a single builder**. This builder must have:  
+## Why MEV Persists on Most Blockchains
 
-- A full copy of the blockchain state  
-- The ability to simulate transactions before they are finalized  
-- Absolute control over transaction selection and ordering  
+MEV is difficult to prevent on most blockchains because **each block has a single builder**. This builder must have:
 
-In practice, this means that **the entity responsible for adding your transaction to the blockchain can first simulate it to identify profit opportunities**. They can test hundreds or thousands of ways to rearrange transactions, inserting their own to extract MEV—often at **your** expense.  
+- A full copy of the blockchain state
+- The ability to simulate transactions before they are finalized
+- Absolute control over transaction selection and ordering
 
-For example, if a block builder can earn $10 by sandwiching your transaction, it means **you** likely lose $10 in value. This is functionally theft, and the worst part? If your transaction is airtight and offers no MEV opportunities, the block builder has no obligation to include it at all. Pay the toll, or get locked out.  
+In practice, this means that **the entity responsible for adding your transaction to the blockchain can first simulate it to identify profit opportunities**. They can test hundreds or thousands of ways to rearrange transactions, inserting their own to extract MEV—often at **your** expense.
+
+For example, if a block builder can earn $10 by sandwiching your transaction, it means **you** likely lose $10 in value. This is functionally theft, and the worst part? If your transaction is airtight and offers no MEV opportunities, the block builder has no obligation to include it at all. Pay the toll, or get locked out.
 
 ## How Flow Accomplishes MEV Resilience
 
-Unlike many blockchains, **Flow was designed from the ground up to minimize MEV** through a unique multi-role architecture. Flow introduces key design choices that break the typical MEV-enabling structure:  
+Unlike many blockchains, **Flow was designed from the ground up to minimize MEV** through a unique multi-role architecture. Flow introduces key design choices that break the typical MEV-enabling structure:
+
+### 1. **Separating Transaction Selection from Execution**
+
+On Flow, **Collection Nodes** select transactions, but they do not have access to the execution state or computing power to simulate them. Meanwhile, **Execution Nodes** run transactions but cannot choose or reorder them.
+
+This separation significantly reduces the ability of block builders to test transactions before execution. Even if an attacker controls both a Collection Node and an Execution Node, they cannot easily extract MEV.
 
-### 1. **Separating Transaction Selection from Execution**  
-On Flow, **Collection Nodes** select transactions, but they do not have access to the execution state or computing power to simulate them. Meanwhile, **Execution Nodes** run transactions but cannot choose or reorder them.  
+### 2. **Separating Transaction Ordering from Execution**
 
-This separation significantly reduces the ability of block builders to test transactions before execution. Even if an attacker controls both a Collection Node and an Execution Node, they cannot easily extract MEV.  
+Flow further decentralizes control by introducing **Consensus Nodes** that determine transaction order. These nodes are separate from both Collection Nodes and Execution Nodes.
 
-### 2. **Separating Transaction Ordering from Execution**  
-Flow further decentralizes control by introducing **Consensus Nodes** that determine transaction order. These nodes are separate from both Collection Nodes and Execution Nodes.  
+For an attacker to perform MEV, they would need to:
 
-For an attacker to perform MEV, they would need to:  
-- Control a **Collection Node** to insert a transaction  
-- Control a **Consensus Node** to place it in the desired order  
-- Have execution state access to predict its effects  
+- Control a **Collection Node** to insert a transaction
+- Control a **Consensus Node** to place it in the desired order
+- Have execution state access to predict its effects
 
-This makes it vastly more difficult to extract MEV compared to traditional blockchains, where a single entity often controls all three functions.  
+This makes it vastly more difficult to extract MEV compared to traditional blockchains, where a single entity often controls all three functions.
+
+### 3. **Strict Transaction Execution Rules**
 
-### 3. **Strict Transaction Execution Rules**  
 Execution Nodes on Flow have a **simple, enforceable rule**:  
-They **must** execute transactions exactly as ordered by Consensus Nodes—or they get slashed.  
+They **must** execute transactions exactly as ordered by Consensus Nodes—or they get slashed.
+
+Unlike traditional blockchains, where the same party both orders and executes transactions, Flow ensures that Execution Nodes cannot manipulate transaction order for profit.
+
+### 4. **Parallel Processing for Extra MEV Resistance**
 
-Unlike traditional blockchains, where the same party both orders and executes transactions, Flow ensures that Execution Nodes cannot manipulate transaction order for profit.  
+Flow’s unique **pipelined execution model** adds another layer of complexity for potential attackers.
 
-### 4. **Parallel Processing for Extra MEV Resistance**  
-Flow’s unique **pipelined execution model** adds another layer of complexity for potential attackers.  
+While one block is being executed, the next block is undergoing consensus, and a third block is still collecting transactions. This means that **to front-run or sandwich attack on Flow, an attacker must successfully predict the outcome of at least two unexecuted blocks—one of which hasn’t even been built yet**.
 
-While one block is being executed, the next block is undergoing consensus, and a third block is still collecting transactions. This means that **to front-run or sandwich attack on Flow, an attacker must successfully predict the outcome of at least two unexecuted blocks—one of which hasn’t even been built yet**.  
+Even with significant resources, this makes profitable MEV attacks incredibly difficult.
 
-Even with significant resources, this makes profitable MEV attacks incredibly difficult.  
+## The End Result: A Fairer Blockchain
 
-## The End Result: A Fairer Blockchain  
+Flow’s architecture ensures that:
 
-Flow’s architecture ensures that:  
-- The nodes selecting transactions **don’t know** their order  
-- The nodes ordering transactions **don’t know** the blockchain state  
-- The nodes executing transactions **can’t** modify the order  
+- The nodes selecting transactions **don’t know** their order
+- The nodes ordering transactions **don’t know** the blockchain state
+- The nodes executing transactions **can’t** modify the order
 
-By **intentionally separating powers**, Flow eliminates MEV at its root rather than merely mitigating its effects.  
+By **intentionally separating powers**, Flow eliminates MEV at its root rather than merely mitigating its effects.
 
 This level of protection against MEV is not an afterthought—it has been a fundamental design goal of Flow since day one. If equitable access matters, **why settle for anything less?**
diff --git a/docs/build/evm/how-it-works.md b/docs/build/evm/how-it-works.md
@@ -16,6 +16,18 @@ Flow EVM is designed with these major goals in mind:
 - Minimizing breaking changes to the Cadence ecosystem, software and tools
 - Maximum composability across environments: Allowing atomic and smooth interaction between EVM and Cadence environments.
 
+<div style={{ position: 'relative', paddingBottom: '56.25%', height: 0, overflow: 'hidden', maxWidth: '100%' }}>
+  <iframe 
+    style={{ position: 'absolute', top: 0, left: 0, width: '100%', height: '100%' }}
+    src="https://www.youtube.com/embed/U4tR8abpclQ?si=dOGAJ1-QSDsscXKB" 
+    title="YouTube video player" 
+    frameborder="0" 
+    allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" 
+    referrerpolicy="strict-origin-when-cross-origin" 
+    allowfullscreen
+  ></iframe>
+</div>
+
 ### EVM - A Smart Contract In Cadence
 
 To satisfy the design goals and thanks to the extensibility properties of the Cadence runtime, Flow EVM is designed as a higher-level environment incorporated as a smart contract deployed to Cadence. This smart contract is not owned by anyone and has its own storage space, allows Cadence to query, and is updated through EVM transactions. EVM transactions can be wrapped inside Cadence transactions and passed to the EVM contract for execution. The artifacts of EVM transaction execution (e.g. receipts and logs) are emitted as special Cadence events (TransactionExecuted, BlockExecuted) and available to the upstream process (Flow transaction) to enable atomic operations.

diff --git a/docs/build/flow.md b/docs/build/flow.md
@@ -38,6 +38,18 @@ Dieter Shirley, Chief Architect of Flow and co-author of the [ERC-721 NFT standa
 
 > **_A computer that anyone can use, everyone can trust, and no one can shut down_**
 
+<div style={{ position: 'relative', paddingBottom: '56.25%', height: 0, overflow: 'hidden', maxWidth: '100%' }}>
+  <iframe 
+    style={{ position: 'absolute', top: 0, left: 0, width: '100%', height: '100%' }}
+    src="https://www.youtube.com/embed/u0HMmIGRrFc?si=LO3cigYf1CgENn5C" 
+    title="YouTube video player" 
+    frameborder="0" 
+    allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" 
+    referrerpolicy="strict-origin-when-cross-origin" 
+    allowfullscreen
+  ></iframe>
+</div>
+
 Much of the protocol design is based on lessons learned from building Web3 applications while working at [Dapper Labs], particularly [CryptoKitties] — the first onchain game to reach [widespread popularity]. The game went viral, then [struggled under its own success] when it caused so much traffic that the Ethereum network itself was overwhelmed by the load.
 
 The design of Flow was guided by the need to alleviate this burden while creating the best experience possible for both developers and users. The blockchain network of the future must be able to handle millions of users while upholding the key pillars of decentralization: