ethereum-optimism · sbvegan · Oct 20, 2024 · Oct 18, 2024 · Oct 18, 2024 · Oct 19, 2024
@@ -73,17 +73,21 @@ export function InfoCallout({ context }: Props): ReactElement {
   );
 }
 
-export function AltCallout({ context }: Props): ReactElement {
+interface BetaCalloutProps extends Props {
+  featureName: string;
+}
+
+function BetaCallout({ context, featureName }: BetaCalloutProps): ReactElement {
   return (
     <div className="custom-callouts nx-w-full nx-mt-6 nx-flex nx-justify-center nx-items-center nx-bg-white dark:nx-bg-black">
-      <div className="nx-w-full  nx-px-4 nx-text-center nx-font-medium nx-text-sm nx-text-left">
+      <div className="nx-w-full nx-px-4 nx-text-center nx-font-medium nx-text-sm nx-text-left">
         {context ? (
           context
         ) : (
-          <div className="nx-text-left">
-            The Alt-DA Mode feature is currently in <strong>Beta</strong> within
+          <div className="nx-text-left" role="alert" aria-live="polite">
+            The {featureName} feature is currently in <strong>Beta</strong> within
             the MIT-licensed OP Stack. Beta features are built and reviewed by
-            the Optimism Collective’s core contributors, and provide developers
+            the Optimism Collective's core contributors, and provide developers
             with early access to highly requested configurations. These features
             may experience stability issues, and we encourage feedback from our
             early users.
@@ -93,3 +97,11 @@ export function AltCallout({ context }: Props): ReactElement {
     </div>
   );
 }
+
+export function AltCallout(props: Props): ReactElement {
+  return <BetaCallout {...props} featureName="Alt-DA Mode" />;
+}
+
+export function CGTCallout(props: Props): ReactElement {
+  return <BetaCallout {...props} featureName="Custom Gas Token" />;
+}
@@ -2,4 +2,4 @@
 /// <reference types="next/image-types/global" />
 
 // NOTE: This file should not be edited
-// see https://nextjs.org/docs/pages/building-your-application/configuring/typescript for more information.
+// see https://nextjs.org/docs/basic-features/typescript for more information.
@@ -215,7 +215,7 @@ The L1 proof and finalization transactions are typically significantly more expe
 
 One of the most important things to understand about L1 ⇔ L2 interaction is that **mainnet messages sent from Layer 2 to Layer 1 cannot be relayed for at least 7 days**.
 This means that any messages you send from Layer 2 will only be received on Layer 1 after this one week period has elapsed.
-We call this period of time the "challenge period" because it is the time during which a transaction can be challenged with a [fault proof](/stack/protocol/rollup/overview#fault-proofs).
+We call this period of time the "challenge period" because it is the time during which a transaction can be challenged with a [fault proof](/stack/rollup/overview#fault-proofs).
 
 Optimistic Rollups are "optimistic" because they're based around the idea of publishing the *result* of a transaction to Ethereum without actually executing the transaction on Ethereum.
 In the "optimistic" case, this transaction result is correct and one can completely avoid the need to perform complicated (and expensive) logic on Ethereum.

@@ -1,6 +1,6 @@
 ---
 ---
 
-import SuperchainERC20 from '@/pages/stack/protocol/interop/superchain-erc20.mdx'
+import SuperchainERC20 from '@/pages/stack/interop/superchain-erc20.mdx'
 
 <SuperchainERC20 />
@@ -1,6 +1,6 @@
 ---
 ---
 
-import Supersim from '@/pages/stack/protocol/interop/supersim.mdx'
+import Supersim from '@/pages/stack/interop/supersim.mdx'
 
 <Supersim />
@@ -973,7 +973,7 @@ instead of the older output oracle mechanism.
 
 The Custom Gas Token configuration lets OP Stack chain operators deploy their 
 chain allowing a specific ERC-20 token to be deposited in as the native token 
-to pay for gas fees. Learn more [here](/stack/protocol/features/custom-gas-token).
+to pay for gas fees. Learn more [here](/stack/beta-features/custom-gas-token).
 
 ***
 
@@ -1005,7 +1005,7 @@ gas on L2.
 Alt-DA Mode enables seamless integration of various Data Availability (DA) 
 Layers, regardless of their commitment type, into the OP Stack. This allows 
 any chain operator to launch an OP Stack chain using their favorite DA Layer 
-for sustainably low costs. Lean more [here](/stack/protocol/features/alt-da-mode).
+for sustainably low costs. Lean more [here](/stack/beta-features/alt-da-mode).
 
 ***
 

@@ -13,7 +13,7 @@ import { Callout, Steps } from 'nextra/components'
   These features may experience stability issues, and we encourage feedback from our early users.
 </Callout>
 
-This guide provides a walkthrough for chain operators who want to run an Alt-DA Mode chain. See the [Alt-DA Mode Explainer](/stack/protocol/features/alt-da-mode) for a general overview of this OP Stack configuration.
+This guide provides a walkthrough for chain operators who want to run an Alt-DA Mode chain. See the [Alt-DA Mode Explainer](/stack/beta-features/alt-da-mode) for a general overview of this OP Stack configuration.
 An Alt-DA Mode OP Stack chain enables a chain operator to post and read data to any alternative data availability layer that has built a functioning OP Stack DA Server.
 
 <Callout>
@@ -44,7 +44,7 @@ You should use at least the following compatible op\* versions when running your
   *   Celestia's docs on how to run the [Celestia DA server](https://github.com/celestiaorg/op-plasma-celestia/blob/main/README.md)
   *   EigenDA's docs on how to run the [EigenDA DA server](https://github.com/Layr-Labs/op-plasma-eigenda/blob/main/README.md)
   *   Avail's docs on how to run the [AvailDA DA Server](https://docs.availproject.org/docs/build-with-avail/Optimium/op-stack/op-stack#setup-avail-da-server)
-  *   0gDA's docs on how to run the [0gDA DA Server](https://github.com/0glabs/0g-da-op-plasma/blob/op0g/README.md)
+  *   0gDA's docs on how to run the [0gDA DA Server](https://github.com/0glabs/0g-da-op-plasma)
   *   Near DA's docs on how to run the [Near DA Server](https://github.com/Nuffle-Labs/data-availability/blob/84b484de98f58a91bf12c8abe8df27f5e753f63a/docs/OP-Alt-DA.md)
 
   ### Configure Your `op-node`
@@ -224,6 +224,6 @@ After making these changes, your system should be properly configured to use the
 
 ## Next Steps
 
-*   Additional questions? See the FAQ section in the [Alt-DA Mode Explainer](/stack/protocol/features/alt-da-mode#faqs).
+*   Additional questions? See the FAQ section in the [Alt-DA Mode Explainer](/stack/beta-features/alt-da-mode#faqs).
 *   For more detailed info on Alt-DA Mode, see the [specs](https://specs.optimism.io/experimental/alt-da.html).
 *   If you experience any problems, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions).
@@ -12,7 +12,7 @@ import { Callout, Steps } from 'nextra/components'
 The Custom Gas Token feature is a Beta feature of the MIT licensed OP Stack. While it has received initial review from core contributors, it is still undergoing testing, and may have bugs or other issues.
 </Callout>
 
-This guide provides a walkthrough for chain operators who want to run a custom gas token chain. See the [Custom Gas Token Explainer](/stack/protocol/features/custom-gas-token) for a general overview of this OP Stack feature.
+This guide provides a walkthrough for chain operators who want to run a custom gas token chain. See the [Custom Gas Token Explainer](/stack/beta-features/custom-gas-token) for a general overview of this OP Stack feature.
 An OP Stack chain that uses the custom gas token feature enables an end user to deposit an L1 native ERC20 token into L2 where that asset is minted as the native L2 asset and can be used to pay for gas on L2.
 
 <Steps>
@@ -156,6 +156,6 @@ section of the docs.
 
 ## Next Steps
 
-*   Additional questions? See the FAQ section in the [Custom Gas Token Explainer](/stack/protocol/features/custom-gas-token#faqs).
+*   Additional questions? See the FAQ section in the [Custom Gas Token Explainer](/stack/beta-features/custom-gas-token#faqs).
 *   For more detailed info on custom gas tokens, see the [specs](https://specs.optimism.io/experimental/custom-gas-token.html).
 *   If you experience any problems, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions).
@@ -1,7 +1,9 @@
 {
   "chain-monitoring": "Chain Monitoring",
-  "op-challenger": "Configure Challenger For Your Chain",
-  "op-conductor": "Conductor",
-  "op-deployer": "Deployer",
-  "explorer": "Block Explorer"
+  "explorer": "Block Explorer",
+  "op-challenger": "op-challenger",
+  "op-conductor": "op-conductor",
+  "op-deployer": "op-deployer",
+  "op-txproxy": "op-txproxy",
+  "proxyd": "proxyd"
 }
@@ -71,7 +71,7 @@ Additional flags:
 
 You can find more info on `op-dispute-mon` on [the repo](https://github.com/ethereum-optimism/optimism/tree/develop/op-dispute-mon).
 
-Chain operators can easily create their grafana dashboard for Dispute Monitor using the following json file: [Download the Dispute Monitor JSON](/grafana/dispute-monitor-1718214549035.json).
+Chain operators can easily create their grafana dashboard for Dispute Monitor using the following json file: [Download the Dispute Monitor JSON](/resources/grafana/dispute-monitor-1718214549035.json).
 
 ## Offchain Component Monitoring
 
@@ -108,7 +108,7 @@ You can find more information about these flags in our [Batcher configuration do
 ### `op-challenger`
 
 The `op-challenger` operates as the *honest actor* in the fault dispute system and defends the chain by securing the `OptimismPortal` and ensuring the game always resolves to the correct state of the chain.
-For verifying the legitimacy of claims, `op-challenger` relies on a synced, trusted rollup node as well as a trace provider (e.g., [Cannon](/stack/protocol/fault-proofs/cannon)). See the [OP-Challenger Explainer](/stack/protocol/fault-proofs/challenger) for more information on this service.
+For verifying the legitimacy of claims, `op-challenger` relies on a synced, trusted rollup node as well as a trace provider (e.g., [Cannon](/stack/fault-proofs/cannon)). See the [OP-Challenger Explainer](/stack/fault-proofs/challenger) for more information on this service.
 
 To enable metrics, pass the `--metrics.enabled` flag to `op-challenger` and follow the steps above for customization options.
 

@@ -8,7 +8,7 @@ import { Callout, Steps } from 'nextra/components'
 
 # How to Configure Challenger For Your Chain
 
-This guide provides a walkthrough of setting up the configuration and monitoring options for `op-challenger`. See the [OP-Challenger Explainer](/stack/protocol/fault-proofs/challenger) for a general overview of this fault proofs feature.&#x20;
+This guide provides a walkthrough of setting up the configuration and monitoring options for `op-challenger`. See the [OP-Challenger Explainer](/stack/fault-proofs/challenger) for a general overview of this fault proofs feature.&#x20;
 
 <Steps>
   ### Build the Executable
@@ -218,6 +218,6 @@ This guide provides a walkthrough of setting up the configuration and monitoring
 
 ## Next Steps
 
-*   Additional questions? See the FAQ section in the [OP Challenger Explainer](/stack/protocol/fault-proofs/challenger).
+*   Additional questions? See the FAQ section in the [OP Challenger Explainer](/stack/fault-proofs/challenger).
 *   For more detailed info on `op-challenger`, see the [specs](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html).
 *   If you experience any problems, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions).
@@ -123,5 +123,5 @@ else. You can run another member of the `inspect` family, `rollup`, to get the `
 
 ## Next Steps
 
-*   For more details, check out the tool and documentation in the [op-deployer repository](https://github.com/ethereum-optimism/optimism/tree/develop/op-chain-ops/cmd/op-deployer).
+*   For more details, check out the tool and documentation in the [op-deployer repository](https://github.com/ethereum-optimism/optimism/tree/develop/op-deployer/cmd/op-deployer).
 *   For more information on OP Contracts Manager, refer to the [OPCM documentation](/stack/opcm).
@@ -61,7 +61,7 @@ When the request passes validation, it is passed through to the configured backe
 
 
 <Callout type="warning">
-  Per the [specification](/stack/protocol/features/send-raw-transaction-conditional), conditional transactions are not gossiped between peers. Thus, if you use replicas in an active/passive sequencer setup, this request must be broadcasted to all replicas.
+  Per the [specification](/stack/features/send-raw-transaction-conditional), conditional transactions are not gossiped between peers. Thus, if you use replicas in an active/passive sequencer setup, this request must be broadcasted to all replicas.
 
   [proxyd](./proxyd) as an egress router for this method supports this broadcasting functionality.
 </Callout>

@@ -13,7 +13,7 @@ import { Callout, Steps } from 'nextra/components'
   These features may experience stability issues, and we encourage feedback from our early users.
 </Callout>
 
-[Alt-DA Mode](/stack/protocol/features/alt-da-mode) enables seamless integration of any DA Layer, regardless of their commitment type, into the OP Stack. After a DA Server is built for a DA Layer, any chain operator can launch an OP Stack chain using that DA Layer for sustainably low costs.
+[Alt-DA Mode](/stack/beta-features/alt-da-mode) enables seamless integration of any DA Layer, regardless of their commitment type, into the OP Stack. After a DA Server is built for a DA Layer, any chain operator can launch an OP Stack chain using that DA Layer for sustainably low costs.
 
 ## Build Your DA Server
 

@@ -17,7 +17,7 @@ If you experience difficulty at any stage of this process, please reach out to [
 
 **ALL** withdrawals that are not finalized before the Fault Proofs upgrade executes will need to be reproven after the upgrade is complete.
 
-  *   Reproving simply requires that you execute the [withdrawal proving flow](https://docs.optimism.io/stack/protocol/rollup/withdrawal-flow) again.
+  *   Reproving simply requires that you execute the [withdrawal proving flow](/stack/transactions/withdrawal-flow) again.
   *   Withdrawals prior to the Fault Proofs upgrade must wait a 7-day challenge period before finalization. As a result, any withdrawal initiated less than 7 days before the upgrade cannot be finalized before the upgrade is executed. You may want to consider waiting until after the upgrade is complete to begin a withdrawal during this 7-day window.
 </Callout>
 
@@ -96,5 +96,5 @@ The proposed Fault Proof upgrade requires developers to enable Fault Proof chang
 
 ## Next Steps
 
-*   See the [Fault Proofs Explainer](/stack/protocol/fault-proofs/explainer) to learn more about the three main components of the Fault Proof System.
-*   You can also read more about [Cannon FPVM](/stack/protocol/fault-proofs/cannon) and [Mips.sol](/stack/protocol/fault-proofs/mips), the onchain smart contract implementation of Cannon.
+*   See the [Fault Proofs Explainer](/stack/fault-proofs/explainer) to learn more about the three main components of the Fault Proof System.
+*   You can also read more about [Cannon FPVM](/stack/fault-proofs/cannon) and [Mips.sol](/stack/fault-proofs/mips), the onchain smart contract implementation of Cannon.
@@ -17,7 +17,7 @@ If you experience difficulty at any stage of this process, please reach out to [
 
 ## What's Included in Granite
 
-This upgrade is proposed in response to security vulnerabilities identified during a series of third-party security audits by Spearbit, Cantina, and Code4rena. None of the vulnerabilities have been exploited, and user assets are not and were never at risk. However, out of an abundance of caution, the permissioned fallback mechanism has been activated in order to avoid any potential instability while the vulnerabilities are patched. For more information on the permissioned fallback mechanism and the OP Stack's defense-in-depth approach to Fault Proof security, see the [fault proof documentation](https://docs.optimism.io/stack/protocol/fault-proofs/fp-security).
+This upgrade is proposed in response to security vulnerabilities identified during a series of third-party security audits by Spearbit, Cantina, and Code4rena. None of the vulnerabilities have been exploited, and user assets are not and were never at risk. However, out of an abundance of caution, the permissioned fallback mechanism has been activated in order to avoid any potential instability while the vulnerabilities are patched. For more information on the permissioned fallback mechanism and the OP Stack's defense-in-depth approach to Fault Proof security, see the [fault proof documentation](/stack/fault-proofs/fp-security).
 
 The upgrade includes both a set of smart contract upgrades to fix the vulnerabilities identified in the audit as well as an L2 hardfork to improve the stability and performance of the fault proof system. In addition, we propose extending the capabilities of the Guardian and DeputyGuardian to set the anchor state for the fault proof system in order to prevent referencing invalid anchor states. Aside from implementing these fixes, the primary impact of this upgrade would be to reset user withdrawals at the planned time, similar to the initial Fault Proof upgrade. 
 

@@ -23,35 +23,6 @@ Developers and users are strongly encouraged to transition to `viem` before the
 
 We are updating our tutorials to use the `viem` library.
 
- {/* Below, you'll find links to the updated versions of popular tutorials:
-
-*   [Estimating Transaction Costs on OP Mainnet](../tutorials/transaction-cost-estimation)\
-    Estimation of transaction costs now uses the `viem` gas estimation utilities.
-
-*   [Triggering OP Mainnet Transactions from Ethereum](../tutorials/trigger-op-transactions)\
-    Learn how to trigger transactions using `viem` to interact with the OP Mainnet.
-
-*   [Tracing Deposits and Withdrawals](../tutorials/tracing-deposits-withdrawals)\
-    The tracing functionalities have been adapted to use `opstack` for efficient results.
-
-*   [Viewing Deposits and Withdrawals by Address](../tutorials/view-deposits-withdrawals)\
-    This tutorial outlines updated methods in `viem` for querying deposits and withdrawals by address.
-
-*   [Bridging Your Standard ERC-20 Token Using the Standard Bridge](../tutorials/bridge-standard-erc20)\
-    The standard bridge tutorial now uses `opstack` for token transfers between Ethereum and OP Mainnet.
-
-*   [Bridging Your Custom ERC-20 Token Using the Standard Bridge](../tutorials/bridge-custom-erc20)\
-    Custom ERC-20 tokens can now be bridged via `opstack`, making the process more streamlined.
-
-*   [Bridging ERC-20 Tokens to OP Mainnet With the Optimism SDK](../tutorials/bridge-sdk-erc20)\
-    **Deprecated** – please use [Bridging Your Custom ERC-20 Token Using the Standard Bridge](../tutorials/bridge-custom-erc20).
-
-*   [Bridging ETH to OP Mainnet With the Optimism SDK](../tutorials/bridge-sdk-eth)\
-    **Deprecated** – please use [Estimating Transaction Costs on OP Mainnet](../tutorials/transaction-cost-estimation).
-
-*   [Communicating Between OP Mainnet and Ethereum in Solidity](../tutorials/cross-chain-solidity)\
-    Cross-chain communication now leverages `opstack` for all messaging. */}
-
 ### For app developers
 
 If your application currently depends on the Optimism SDK, you will need to migrate to using the `viem` library.