ethereum-optimism · sbvegan · Oct 20, 2024 · Oct 18, 2024 · Oct 18, 2024 · Oct 19, 2024
@@ -93,3 +93,24 @@ export function AltCallout({ context }: Props): ReactElement {
     </div>
   );
 }
+
+export function CGTCallout({ context }: Props): 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">
+        {context ? (
+          context
+        ) : (
+          <div className="nx-text-left">
+            The Custom Gas Token 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
+            with early access to highly requested configurations. These features
+            may experience stability issues, and we encourage feedback from our
+            early users.
+          </div>
+        )}
+      </div>
+    </div>
+  );
+}
@@ -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/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/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/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>
@@ -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/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"
 }
@@ -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).
@@ -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](https://docs.optimism.io/stack/rollup/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](https://docs.optimism.io/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. 
 

@@ -21,7 +21,7 @@ import { Callout } from 'nextra/components'
 
 ## Bundlers
 
-The OP Stack includes support for the `eth_sendRawTransactionConditional` RPC method to assist bundlers on shared 4337 mempools. See the [specification](/stack/protocol/features/send-raw-transaction-conditional) for how this method is implemented in op-geth.
+The OP Stack includes support for the `eth_sendRawTransactionConditional` RPC method to assist bundlers on shared 4337 mempools. See the [specification](/stack/features/send-raw-transaction-conditional) for how this method is implemented in op-geth.
 
 If enabled by the chain operator, also see the supplemental [op-txproxy](/stack/operators/features/op-txproxy) service, if applied, as this enforces request authentication for this method.
 

@@ -38,7 +38,7 @@ Withdrawals are proven against proposals about the state of OP Mainnet that are
 
 Proposals can be submitted to the `DisputeGameFactory` contract by any user and submissions do not require any special permissions.
 Each submitted proposal creates a [`FaultDisputeGame`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/dispute/FaultDisputeGame.sol) contract that allows any other user to challenge the validity of a proposal by participating in a "fault proof" process.
-A more detailed explanation of the fault proof game can be found in the [Fault Proofs Explainer](/stack/protocol/fault-proofs/explainer).
+A more detailed explanation of the fault proof game can be found in the [Fault Proofs Explainer](/stack/fault-proofs/explainer).
 
 Although the fault proof game is permissionless, the Optimism Security Council acting as the [Guardian](/chain/security/privileged-roles#guardian) role provides a backstop in case of a failure in the fault proof game.
 Each proposal must wait for a delay period during which the Guardian can prevent invalid proposals from being used to withdraw ETH or tokens through a number of safety hatches.

@@ -1,17 +1,20 @@
 {
   "getting-started": "Getting Started: OP Stack",
   "differences": "Differences Between Ethereum and OP Stack Chains",
-  "components": "OP Stack Components",
-  "smart-contracts": "Smart Contracts",
   "explainer": "Superchain Explainer",
   "design-principles": "Design Philosophy & Principles",
-  "protocol": "Protocol",
+  "components": "OP Stack Components",
+  "smart-contracts": "Smart Contracts",
+  "rollup": "Rollup",
+  "fault-proofs": "Fault Proofs",
   "transactions": "Transactions",
+  "features": "Features",
   "security": "Security",
-  "operators": "Operators",
   "--- Experimental": {
     "title": "Experimental",
     "type": "separator"
   },
-  "opcm": "OP Contracts Manager"
+  "opcm": "OP Contracts Manager",
+  "interop": "Interoperability",
+  "beta-features": "Beta Features"
 }
@@ -0,0 +1,4 @@
+{
+    "custom-gas-token": "Custom Gas Token",
+    "alt-da-mode": "Alt-DA Mode"
+}
@@ -5,6 +5,9 @@ description: Learn the basic process, benefits, and considerations for running a
 ---
 
 import { Callout } from 'nextra/components'
+import { CGTCallout } from '@/components/WipCallout'
+
+<CGTCallout />
 
 # Custom Gas Token Explainer
 

@@ -35,7 +35,7 @@ single L2 block state transition that they disagree on.
 
 ### OP-Challenger \<> Cannon
 
-Once an active fault dispute game reaches a depth below attacking / defending L2 block state transitions, [OP-Challenger](/stack/protocol/fault-proofs/challenger) will run
+Once an active fault dispute game reaches a depth below attacking / defending L2 block state transitions, [OP-Challenger](/stack/fault-proofs/challenger) will run
 Cannon to begin processing MIPS instructions within the FPVM. As part of processing MIPS instructions, Cannon will generate state
 witness hashes, which are the commitment to the results of the MIPS instructions' computation within the FPVM. Now, in the bisection game, OP-Challenger will provide the generated hashes
 until a single MIPS instruction is identified as the root disagreement between participants in the active dispute. Cannon will then

@@ -9,7 +9,7 @@ import Image from 'next/image'
 
 # OP-Challenger Explainer
 
-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)).
+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/fault-proofs/cannon)).
 
 Specifically, `op-challenger` performs the following actions: