Merge branch 'main' into breadcrumbs

components/WipCallout.tsx

@@ -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" />;
+}

next-env.d.ts

@@ -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.

pages/builders/app-developers/bridging/basics.mdx

@@ -1,29 +1,29 @@
 ---
-title: Bridging Basics
+title: Bridging basics
 lang: en-US
 description: Learn about the fundamentals of sending data and tokens between Ethereum and OP Mainnet.
 ---
 
-# Bridging Basics
+# Bridging basics
 
 OP Mainnet is a "Layer 2" system and is fundamentally connected to Ethereum.
 However, OP Mainnet is also a distinct blockchain with its own blocks and transactions.
 App developers commonly need to move data and tokens between OP Mainnet and Ethereum.
 This process of moving data and tokens between the two networks is called "bridging".
 
-## Sending Tokens
+## Sending tokens
 
 One of the most common use cases for bridging is the need to send ETH or ERC-20 tokens between OP Mainnet and Ethereum.
 OP Mainnet has a system called the [Standard Bridge](./standard-bridge) that makes it easy to move tokens in both directions.
 If you mostly need to bridge tokens, make sure to check out the [Standard Bridge](./standard-bridge) guide.
 
-## Sending Data
+## Sending data
 
 Under the hood, the Standard Bridge is just an application that uses the OP Mainnet [message passing system to send arbitrary data between Ethereum and OP Mainnet](./messaging).
 Applications can use this system to have a contract on Ethereum interact with a contract on OP Mainnet, and vice versa.
 All of this is easily accessible with a simple, clean API.
 
-## Next Steps
+## Next steps
 
 Ready to start bridging?
 Check out these tutorials to get up to speed fast.

pages/builders/app-developers/bridging/custom-bridge.mdx

@@ -1,12 +1,12 @@
 ---
-title: Custom Bridges
+title: Custom bridges
 lang: en-US
 description: Important considerations when building custom bridges for OP Mainnet.
 ---
 
 import { Callout } from 'nextra/components'
 
-# Custom Bridges
+# Custom bridges
 
 Custom token bridges are any bridges other than the [Standard Bridge](./standard-bridge).
 You may find yourself in a position where you need to build a custom token bridge because the Standard Bridge doesn't completely support your use case.
@@ -35,7 +35,7 @@ The [Superchain Token List](/chain/tokenlist) exists to help users and developer
 Once you've built and tested your custom bridge, make sure to register any tokens meant to flow through this bridge by [making a pull request against the Superchain Token List repository](https://github.com/ethereum-optimism/ethereum-optimism.github.io#adding-a-token-to-the-list).
 You **must** deploy your bridge to OP Sepolia before it can be added to the Superchain Token List.
 
-## Next Steps
+## Next steps
 
 You can explore several examples of custom bridges for OP Mainnet:
 

pages/builders/app-developers/bridging/messaging.mdx

@@ -1,12 +1,12 @@
 ---
-title: Sending Data Between L1 and L2
+title: Sending data between L1 and L2
 lang: en-US
 description: Learn how bridging works between L1 and L2, how to use it, and what to watch out for.
 ---
 
 import { Callout } from 'nextra/components'
 
-# Sending Data Between L1 and L2
+# Sending data between L1 and L2
 
 Smart contracts on L1 (Ethereum) can interact with smart contracts on L2 (OP Mainnet) through a process called "bridging".
 This page explains how bridging works, how to use it, and what to watch out for.
@@ -16,7 +16,7 @@ This page explains how bridging works, how to use it, and what to watch out for.
   For a step-by-step tutorial on how to send data between L1 and L2, check out the [Solidity tutorial](/builders/app-developers/tutorials/cross-dom-solidity).
 </Callout>
 
-## Understanding Contract Calls
+## Understanding contract calls
 
 It can be easier to understand bridging if you first have a basic understanding of how contracts on EVM-based blockchains like OP Mainnet and Ethereum communicate within the *same* network.
 The interface for sending messages *between* Ethereum and OP Mainnet is designed to mimic the standard contract communication interface as much as possible.
@@ -57,7 +57,7 @@ Here you're using the [low-level "call" function](https://docs.soliditylang.org/
 Although these two code snippets look a bit different, they're doing the exact same thing.
 Because of limitations of Solidity, **the OP Stack's bridging interface is designed to look like the second code snippet**.
 
-## Basics of Communication Between Layers
+## Basics of communication between layers
 
 At a high level, the process for sending data between L1 and L2 is pretty similar to the process for sending data between two contracts on Ethereum (with a few caveats).
 Communication between L1 and L2 is made possible by a pair of special smart contracts called the "messenger" contracts.
@@ -121,17 +121,17 @@ contract MyContract {
   You can find the addresses of the `L1CrossDomainMessenger` and the `L2CrossDomainMessenger` contracts on OP Mainnet and OP Sepolia on the [Contract Addresses](/chain/addresses) page.
 </Callout>
 
-## Communication Speed
+## Communication speed
 
 Unlike calls between contracts on the same blockchain, calls between Ethereum and OP Mainnet are *not* instantaneous.
 The speed of a cross-chain transaction depends on the direction in which the transaction is sent.
 
-### For L1 to L2 Transactions
+### For L1 to L2 transactions
 
 Transactions sent from L1 to L2 take **approximately 1-3 minutes** to get from Ethereum to OP Mainnet, or from Sepolia to OP Sepolia.
 This is because the Sequencer waits for a certain number of L1 blocks to be created before including L1 to L2 transactions to avoid potentially annoying [reorgs](https://www.alchemy.com/overviews/what-is-a-reorg).
 
-### For L2 to L1 Transactions
+### For L2 to L1 transactions
 
 Transactions sent from L2 to L1 take **approximately 7 days** to get from OP Mainnet to Ethereum, or from OP Sepolia to Sepolia.
 This is because the bridge contract on L1 must wait for the L2 state to be *proven* to the L1 chain before it can relay the message.
@@ -177,9 +177,9 @@ modifier onlyOwner() {
 }
 ```
 
-## Fees For Sending Data Between L1 and L2
+## Fees for sending data between L1 and L2
 
-### For L1 to L2 Transactions
+### For L1 to L2 transactions
 
 The majority of the cost of an L1 to L2 transaction comes from the smart contract execution on L1.
 When sending an L1 to L2 transaction, you send to the [`L1CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/L1CrossDomainMessenger.sol) contract, which then sends a call to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/OptimismPortal.sol) contract.
@@ -195,7 +195,7 @@ The amount of L1 gas charged increases when more people are sending L1 to L2 tra
   You should always add a buffer of at least 20% to the gas limit for your L1 to L2 transaction to avoid running out of gas.
 </Callout>
 
-### For L2 to L1 Transactions
+### For L2 to L1 transactions
 
 Each message from L2 to L1 requires three transactions:
 
@@ -211,11 +211,11 @@ Each message from L2 to L1 requires three transactions:
 The total cost of an L2 to L1 transaction is therefore the combined cost of the L2 initialization transaction and the two L1 transactions.
 The L1 proof and finalization transactions are typically significantly more expensive than the L2 initialization transaction.
 
-## Understanding the Challenge Period
+## Understanding the challenge period
 
 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.

pages/builders/app-developers/bridging/standard-bridge.mdx

@@ -36,7 +36,7 @@ The Standard Bridge is composed of two contracts, the [`L1StandardBridge`](https
 These two contracts interact with one another via the `CrossDomainMessenger` system for sending messages between Ethereum and OP Mainnet.
 You can read more about the `CrossDomainMessenger` in the guide on [Sending Data Between L1 and L2](./messaging).
 
-### Bridged Tokens
+### Bridged tokens
 
 The Standard Bridge utilizes bridged representations of tokens that are native to another blockchain.
 Before a token native to one chain can be bridged to the other chain, a bridged representation of that token must be created on the receiving side.
@@ -50,7 +50,7 @@ A native token may have more than one bridged representation at the same time.
 Users must always specify which bridged token they wish to use when using the bridge.
 Different bridged representations of the same native token are considered entirely independent tokens.
 
-### Bridging Native Tokens
+### Bridging native tokens
 
 The Standard Bridge uses a "lock-and-mint" mechanism to convert native tokens into their bridged representations.
 This means that **native tokens are locked** into the Standard Bridge on one side, after which **bridged tokens are minted** on the other side.
@@ -129,7 +129,7 @@ The process for bridging a native token involves a few steps.
   This process is identical in both the Ethereum to OP Mainnet and OP Mainnet to Ethereum directions.
 </Steps>
 
-### Bridging Non-Native Tokens
+### Bridging non-native tokens
 
 The Standard Bridge uses a "burn-and-unlock" mechanism to convert bridged representations of tokens back into their native tokens.
 This means that **bridged tokens are burned** on the Standard Bridge on one side, after which **native tokens are unlocked** on the other side.
@@ -237,7 +237,7 @@ The address of this entry is the address of the bridged representation of the to
 
 </Steps>
 
-## Special Considerations
+## Special considerations
 
 ### USDC
 

pages/builders/app-developers/contracts/_meta.json

@@ -1,5 +1,6 @@
 {
   "compatibility": "Solidity Compatibility",
   "system-contracts": "System Contracts",
-  "optimization": "Cost Optimization"
+  "optimization": "Cost Optimization",
+  "superchain-erc20": "SuperchainERC20 Token Standard"
 }

pages/builders/app-developers/contracts/compatibility.mdx

@@ -1,21 +1,21 @@
 ---
-title: Solidity Compatibility
+title: Solidity compatibility
 lang: en-US
 description: Learn about the differences between OP Mainnet and Ethereum when building Solidity contracts.
 ---
 
-# Solidity Compatibility
+# Solidity compatibility
 
 OP Mainnet is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), which means OP Mainnet looks exactly like Ethereum in every way possible.
 Almost all Ethereum tooling works out of the box on OP Mainnet, including the [Solidity](https://soliditylang.org/) smart contract language.
 However, there are a few minor differences between OP Mainnet and Ethereum that you should be aware of when building Solidity contracts.
 
-## EVM/Opcode Differences
+## EVM/Opcode differences
 
 Most smart contracts will work on OP Mainnet without any changes.
 Check out the [Differences Between Ethereum and OP Mainnet](/chain/differences#opcodes) page for a detailed list of the few differences you should know about.
 
-## Gas Differences
+## Gas differences
 
 OP Mainnet uses the same gas costs as Ethereum.
 However, OP Mainnet also charges an [L1 Data Fee](/stack/transactions/fees#l1-data-fee) for the cost of publishing an L2 transaction to L1.

pages/builders/app-developers/contracts/optimization.mdx

@@ -1,12 +1,12 @@
 ---
-title: Contract Optimization on OP Mainnet
+title: Contract optimization on OP Mainnet
 lang: en-US
 description: Learn how to optimize contracts for OP Mainnet and what to look out for when you do so.
 ---
 
 import { Callout } from 'nextra/components'
 
-# Contract Optimization on OP Mainnet
+# Contract optimization on OP Mainnet
 
 OP Mainnet is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), which means OP Mainnet looks exactly like Ethereum in every way possible.
 One large and mostly unavoidable discrepancy between OP Mainnet and Ethereum is a slight [difference in transaction fee models](/stack/transactions/fees).
@@ -36,12 +36,12 @@ This is the basic premise that makes OP Mainnet contract optimization slightly d
 
 ## Considerations
 
-### Additional Complexity
+### Additional complexity
 
 Contract optimizations can create additional complexity, which can in turn create additional risk.
 Developers should always consider whether this added complexity is worth the reduction in cost.
 
-### Changing Economics
+### Changing economics
 
 Various potential upgrades to OP Mainnet may also make optimizations to the L1 Data Fee less relevant.
 For instance, [EIP-4844](https://www.eip4844.com/), if adopted, should significantly reduce the cost of publishing data to Ethereum and would therefore also decrease the L1 Data Fee.
@@ -57,7 +57,7 @@ If you expect your contracts to be used mostly in the short term or you have the
 
 ## Techniques
 
-### Calldata Compression
+### Calldata compression
 
 Compressing user data on the client side and decompressing it on the contract side can be an effective way to decrease costs on OP Mainnet.
 This technique decreases the amount of data provided by the user in exchange for a significant increase in onchain computation.
@@ -66,7 +66,7 @@ Although several libraries exist to perform this calldata compression, none of t
 As a result, links to these libraries have been explicitly omitted here to avoid encouraging developers from using potentially buggy software.
 Most of these libraries can be found with a quick search online but, as always, be careful with code you find on the internet.
 
-### Custom Encoding
+### Custom encoding
 
 The [Solidity ABI encoding scheme](https://docs.soliditylang.org/en/v0.8.23/abi-spec.html#argument-encoding) is not particularly data efficient.
 Contracts can often reduce the amount of calldata provided by defining a custom argument encoding protocol.

pages/builders/app-developers/contracts/superchain-erc20.mdx

@@ -0,0 +1,6 @@
+---
+---
+
+import SuperchainERC20 from '@/pages/stack/interop/superchain-erc20.mdx'
+
+<SuperchainERC20 />