Merge branch 'master' into add-more-logs-noderunning

arbitrum-docs/build-decentralized-apps/token-bridging/bridge-tokens-programmatically/03-how-to-bridge-tokens-generic-custom.mdx

@@ -11,7 +11,7 @@ Familiarity with [Arbitrum’s token bridge system](/build-decentralized-apps/to
 
 We will go through all steps involved in the process. However, if you want to jump straight to the code, we have created [this script in our tutorials repository](https://github.com/OffchainLabs/arbitrum-tutorials/tree/master/packages/custom-token-bridging) that encapsulates the entire process.
 
-## Step 0: Review the prerequisites
+## Step 1: Review the prerequisites
 
 As stated in the [token bridge conceptual page](/build-decentralized-apps/token-bridging/03-token-bridge-erc20.mdx#the-arbitrum-generic-custom-gateway), there are a few prerequisites to keep in mind while using this method to make a token bridgeable.
 
@@ -36,7 +36,7 @@ import TokenCompatibilityPartial from '../partials/_token-compatibility.mdx';
 
 <TokenCompatibilityPartial />
 
-## Step 1: Create a token and deploy it on L1
+## Step 2: Create a token and deploy it on L1
 
 We‘ll begin the process by creating and deploying on L1 a sample token to bridge. If you already have a token contract on L1, you don’t need to perform this step.
 
@@ -205,7 +205,7 @@ main()
   });
 ```
 
-## Step 2: Create a token and deploy it on L2
+## Step 3: Create a token and deploy it on L2
 
 We’ll now create and deploy on L2 the counterpart of the token we created on L1.
 
@@ -294,7 +294,7 @@ main()
   });
 ```
 
-## Step 3: Register the custom token to the generic-custom gateway
+## Step 4: Register the custom token to the generic-custom gateway
 
 Once both our contracts are deployed in their respective chains, it’s time to register the token in the generic-custom gateway.
 

arbitrum-docs/how-arbitrum-works/02-transaction-lifecycle.mdx

@@ -43,17 +43,15 @@ The Sequencer Endpoint is the most direct method for users looking to minimize d
 
 The diagram below shows different ways to submit transactions to the sequencer:
 
-<div class="invert-on-dark">
-  ![submit-transaction-to-sequencer](../assets/submit-tx-to-sequencer.png)
-</div>
+![submit-transaction-to-sequencer](../assets/submit-tx-to-sequencer.svg)
 
 ## Bypassing the Sequencer
 
 This section delves into an alternative method for submitting transactions to the Arbitrum chain, bypassing the sequencer. This page focuses on how users can send their transactions directly to the delayed inbox contract on the parent chain rather than through the sequencer. This method offers two distinct paths a transaction can take, with each route interacting with the network differently to achieve transaction inclusion. This approach provides users with greater flexibility and ensures that transactions can still be processed if the sequencer is unavailable or if users choose not to depend on it. This section highlights these alternative submission mechanisms and underscores the robustness and decentralization features inherent in the Arbitrum network.
 
 In **Diagram 3**, we demonstrate how users can submit their transactions using the delayed inbox contract to bypass the sequencer. As illustrated in the diagram, there are two possible paths for transaction handling. When a transaction is submitted to the delayed inbox, the sequencer may automatically pick it up, include it as an ordered transaction, and send it to the sequencer feed. However, if the sequencer does not process the transaction within 24 hours, users have the reliable option to call the `forceInclude` function on the sequencer inbox contract. This action ensures that the sequencer to picks up the transaction and includes it in the ordered transaction list, providing users with a sense of security about their transactions.
 
-<div class="invert-on-dark">![bypassing-the-sequencer](../assets/bypassing-the-sequencer.png)</div>
+![bypassing-the-sequencer](../assets/bypassing-the-sequencer.svg)
 
 To send a transaction to the delayed inbox instead of submitting it to the sequencer, users can construct their transaction and then call the [`sendL2Message`](https://github.com/OffchainLabs/nitro-contracts/blob/fbbcef09c95f69decabaced3da683f987902f3e2/src/bridge/AbsInbox.sol#L150) function, passing the data of the serialized signed transaction as an argument. This function allows users to send a generic L2 message to the chain, suitable for any message that does not require L1 validation.
 

arbitrum-docs/how-arbitrum-works/03-sequencer.mdx

@@ -9,7 +9,7 @@ content_type: get-started
 
 The <a data-quicklook-from="sequencer">Sequencer</a> is a pivotal component of the <a data-quicklook-from="arbitrum">Arbitrum</a> network and is responsible for efficiently ordering and processing transactions. It plays a crucial role in providing users with fast <a data-quicklook-from="transaction">Transaction</a> confirmations while maintaining the security and integrity of the <a data-quicklook-from="blockchain">Blockchain</a>. In Arbitrum, the Sequencer orders incoming transactions and manages the batching, compression, and posting of transaction data to <a data-quicklook-from="parent-chain">Parent chain</a>, optimizing costs and performance.
 
-<div class="invert-on-dark">![sequencer-operations](../assets/sequencer-operations.png)</div>
+![sequencer-operations](../assets/sequencer-operations.svg)
 
 In this section, we will explore the operation of the Sequencer in detail. The topics covered include:
 
@@ -33,7 +33,7 @@ The Sequencer communicates the transaction sequence through two primary channels
 1. **Real-Time Sequencer Feed**: A live broadcast that publishes transactions instantly as they are sequenced. Nodes and clients subscribed to this feed receive immediate notifications, allowing them to process transactions without delay.
 2. **Batches Posted on the Parent Chain**: At regular intervals, the Sequencer aggregates transactions and posts them to the parent chain for finality. (Refer to the <a data-quicklook-from="batch">Batch</a>-Posting section for detailed information on this process.)
 
-<div class="invert-on-dark">![sequencer-feed](../assets/sequencer-feed.png)</div>
+![sequencer-feed](../assets/sequencer-feed.svg)
 
 ### Real-Time Sequencer Feed
 
@@ -97,7 +97,7 @@ Understanding Batch-Posting is essential for grasping how Arbitrum achieves scal
 
 The Sequencer in Arbitrum is critical in collecting and organizing child chain transactions before posting them to the parent chain. The batching process is designed to optimize for both cost efficiency and timely transaction inclusion.
 
-<div class="invert-on-dark">![batching](../assets/batching.png)</div>
+![batching](../assets/batching.svg)
 
 **Transaction Collection and Ordering:**
 
@@ -122,7 +122,7 @@ This batching mechanism allows the Sequencer to efficiently manage transactions
 
 The Sequencer employs compression when forming transaction batches to optimize the data and cost of batches posted to the parent chain. Arbitrum uses the Brotli compression algorithm due to its high compression ratio and efficiency, crucial for reducing parent chain posting costs.
 
-<div class="invert-on-dark">![compression](../assets/compression.png)</div>
+![compression](../assets/compression.svg)
 
 ### Compression level in the Brotli algorithm
 
@@ -147,9 +147,7 @@ After batching and compressing transactions, the Sequencer posts these batches t
 
 There are two primary methods the Sequencer uses to send batches to the parent chain, depending on whether the chain supports EIP-4844 (Proto-Danksharding) and the current network conditions:
 
-<div class="invert-on-dark">
-  ![submit-to-sequencer-inbox](../assets/submit-to-sequencer-inbox.png)
-</div>
+![submit-to-sequencer-inbox](../assets/submit-to-sequencer-inbox.svg)
 
 ### 1. Using Blobs with `addSequencerL2BatchFromBlobs`
 

arbitrum-docs/how-arbitrum-works/10-l1-to-l2-messaging.mdx

@@ -8,14 +8,6 @@ content_type: get-started
 ---
 
 import { AddressAliasHelper } from '@site/src/components/AddressAliasHelper';
-import {
-  MermaidWithHtml,
-  Nodes,
-  Node,
-  Connection,
-  NodeDescriptions,
-  NodeDescription,
-} from '/src/components/MermaidWithHtml/MermaidWithHtml';
 
 In the [Transaction Lifecycle](/how-arbitrum-works/02-transaction-lifecycle.mdx) section, we covered how users interact with L2 contracts. They submit transactions by putting messages into the chain’s inbox or having a full node <a data-quicklook-from="sequencer">Sequencer</a> or aggregator do so on their behalf.
 
@@ -51,43 +43,7 @@ Here we walk through the different stages of the lifecycle of a <a data-quickloo
 
 3. Ticket creation causes the [`ArbRetryableTx`](/build-decentralized-apps/precompiles/02-reference.mdx#arbretryabletx) precompile to emit a `TicketCreated` event containing the `TicketID` on L2.
 
-<MermaidWithHtml>
-  <Nodes title="Ticket Submission">
-    <Node id="1">🧍</Node>
-    <Node id="2">Initiating an L1-L2 message</Node>
-    <Node id="3">Enough deposit?</Node>
-    <Node id="4">Ticket creation fails</Node>
-    <Node id="5">Ticket is created</Node>
-    <Connection from="1" to="2" />
-    <Connection from="2" to="3" />
-    <Connection from="3" to="4" label="no" />
-    <Connection from="3" to="5" label="yes" />
-  </Nodes>
-  <NodeDescriptions>
-    <NodeDescription for="1">
-      <code>🧍</code> The user who initiates an L1-L2 message
-    </NodeDescription>
-    <NodeDescription for="2">
-      <code>Initiating an L1-L2 message</code> A call to `inbox.createRetryableTicket` function that
-      puts the message in the L2 inbox that can be re-executed for some fixed amount of time if it
-      reverts
-    </NodeDescription>
-    <NodeDescription for="3">
-      <code>Check user's deposit</code> Logic that checks if the user have enough funds to create a
-      ticket. This is done by checking if the `msg.value` provided by the user is greater than or
-      equal to <code>maxSubmissionCost + l2CallValue + gasLimit * maxFeePerGas</code>
-    </NodeDescription>
-    <NodeDescription for="4">
-      <code>Ticket creation fails</code> Ticket creation fails and no funds are deducted from the
-      user
-    </NodeDescription>
-    <NodeDescription for="5">
-      <code>Ticket is created</code> A ticket is created and added to the retryable buffer on L2
-      Funds (<code>l2CallValue + submissionCost</code>) are deducted to cover the callvalue from the
-      user and placed into escrow (on L2) for later use in redeeming the ticket
-    </NodeDescription>
-  </NodeDescriptions>
-</MermaidWithHtml>
+![500px-img](../assets/ticket-submission.svg)
 
 ### Automatic Redemption
 
@@ -97,37 +53,7 @@ Here we walk through the different stages of the lifecycle of a <a data-quickloo
 
 - If a redeem is not done at submission or the submission's initial redeem fails (for example, because the L2 gas price has increased unexpectedly), the submission fee is collected on L2 to cover the resources required to temporarily keep the ticket in memory for a fixed period (one week), and only in this case, a manual redemption of the ticket is required (see next section).
 
-<MermaidWithHtml>
-  <Nodes title="Automatic Redemption of the Ticket">
-    <Node id="1">Auto-redeem succeeds?</Node>
-    <Node id="2">Ticket is executed</Node>
-    <Node id="3">Ticket is deleted</Node>
-    <Node id="4">callValueRefundAddress gets refunded</Node>
-    <Connection from="1" to="2" label="yes" />
-    <Connection from="2" to="3" />
-    <Connection from="1" to="4" label="no" />
-  </Nodes>
-  <NodeDescriptions>
-    <NodeDescription for="1">
-      <code>Does the auto-redeem succeed?</code> Logic that determines if the user's L2 Balance is
-      greater than (or equal to) <code>maxFeePerGas * gasLimit</code> && <code>maxFeePerGas</code>{' '}
-      is greater than (or equal to) the <code>l2Basefee</code>
-    </NodeDescription>
-    <NodeDescription for="2">
-      <code>Ticket is executed</code> Ticket is executed, the actual <code>submissionFee</code> is
-      refunded to the <code>excessFeeRefundAddress</code> since the ticket was not kept in the
-      buffer on L2
-    </NodeDescription>
-    <NodeDescription for="3">
-      <code>Ticket is deleted</code> Ticket gets deleted from the L2 retryable buffer
-    </NodeDescription>
-    <NodeDescription for="4">
-      <code>callValueRefundAddress gets refunded</code> <code>callValueRefundAddress</code> gets
-      refunded with <code>(maxGas - gasUsed) * gasPrice</code>. Note that this amount is capped by{' '}
-      <code>l1CallValue</code> in the auto-redeem
-    </NodeDescription>
-  </NodeDescriptions>
-</MermaidWithHtml>
+![Automatic Redemption of the Ticket](../assets/automatic-redemption-of-the-ticket.png)
 
 ### Manual Redemption
 
@@ -140,37 +66,7 @@ Here we walk through the different stages of the lifecycle of a <a data-quickloo
 [discard_link]: https://github.com/OffchainLabs/nitro/blob/fa36a0f138b8a7e684194f9840315d80c390f324/arbos/retryables/retryable.go#L262
 [renew_link]: https://github.com/OffchainLabs/nitro-contracts/blob/a68783436b5105a64f54efe5fbd55174704a7618/src/precompiles/ArbRetryableTx.sol#L41
 
-<MermaidWithHtml>
-  <Nodes title="Manual Redemption of the Ticket">
-    <Node id="1">Ticket manually cancelled or not redeemed in 7 days?</Node>
-    <Node id="2">callValueRefundAddress gets refunded</Node>
-    <Node id="3">Ticket is deleted</Node>
-    <Node id="4">Ticket manually redeemed?</Node>
-    <Connection from="1" to="2" label="yes" />
-    <Connection from="2" to="3" />
-    <Connection from="1" to="4" label="no" />
-    <Connection from="4" to="3" label="yes" />
-    <Connection from="4" to="1" label="no" />
-  </Nodes>
-  <NodeDescriptions>
-    <NodeDescription for="1">
-      <code>Is the ticket manually cancelled or not redeemed within 7 days?</code> Logic that
-      determines if the ticket is manually cancelled or not redeemed within 7 days (i.e., is
-      expired)
-    </NodeDescription>
-    <NodeDescription for="2">
-      <code>callValueRefundAddress gets refunded</code> callValueRefundAddress is refunded with the{' '}
-      <code>l2CallValue</code>
-    </NodeDescription>
-    <NodeDescription for="3">
-      <code>Ticket is deleted</code> Ticket gets deleted from the L2 retryable buffer
-    </NodeDescription>
-    <NodeDescription for="4">
-      <code>Is the ticket manually redeemed</code> Logic that determines if the ticket is manually
-      redeemed
-    </NodeDescription>
-  </NodeDescriptions>
-</MermaidWithHtml>
+![Manual Redemption of the Ticket](../assets/manual-redemption-of-the-ticket.png)
 
 :::caution Avoid Losing Funds!
 

arbitrum-docs/launch-orbit-chain/aep-fee-router-introduction.mdx

@@ -40,3 +40,9 @@ The Arbitrum Foundation will track compliance based on fees received through the
 ## How can I set up an AEP fee router on my Orbit chain?
 
 You can learn how to set up your AEP fee router in [implementation guide](/launch-orbit-chain/how-tos/set-up-aep-fee-router.mdx).
+
+![SVG diagram](./assets/aep-scenario-1.svg)
+![SVG diagram](./assets/aep-scenario-2.svg)
+![SVG diagram](./assets/aep-scenario-3.svg)
+![SVG diagram](./assets/aep-scenario-4.svg)
+![SVG diagram](./assets/aep-scenario-5.svg)

arbitrum-docs/launch-orbit-chain/how-tos/set-up-aep-fee-router.mdx

@@ -58,6 +58,14 @@ In the absence of these, please send `ETH` through the AEP Fee Router to fulfill
 
 </aside>
 
+Here are a few flows to help visualize the deployment:
+
+2. Scenario 1: You are an L2 Orbit Chain that settles on Ethereum.
+
+3. Scenario 2: You are an L3 Orbit Chain that settles to another L2. The custom gas token you are using exists on L1.
+
+4. Scenario 3: You are an L3 Orbit Chain that settles to another L2. The custom gas token doesn't exist on L1.
+
 ## Deployment scripts
 
 The Orbit SDK provides a [configurable script](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/setup-aep-fee-router) that allows a chain operator to deploy quickly and set up the AEP fee router contracts.

website/src/css/partials/_content-body.scss

@@ -70,6 +70,9 @@ article {
     img[alt='400px-img'] {
       width: 400px;
     }
+    img[alt='500px-img'] {
+      width: 500px;
+    }
     img[alt='600px-img'] {
       width: 600px;
     }