fix conflict

Author: krofax

.github/ISSUE_TEMPLATE/docs_audit_results.md

@@ -9,7 +9,25 @@ labels: 'docs-audit-2024-Q4,op-labs'
 
 ## Description of the updates required
 
-> Write a description of the current state of the page.
+<!-- Write a description of the current state of the page. -->
+
+### Acceptance criteria
+
+<!-- Definition of done for the assignee -->
+
+### Resources
+
+<!-- Supporting docs, points of contact, and any additional helpful info -->
+
+### Action items
+
+<!-- The process for working through this issue for example:
+1. Read through resources and meet with SME
+2. Write the first draft
+3. Share draft with SMEs and implement feedback
+4. Peer review
+5. Final SME review
+6. Publish -->
 
 ## Github issue label criteria
 

nouns.txt

@@ -16,4 +16,5 @@ Granite
 Holocene
 Monitorism
 Kubernetes
-Fault Proof System
+Fault Proof System
+Viem

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

@@ -1,7 +1,7 @@
 {
   "first-contract": "Deploying your first contract on OP Mainnet",
   "cross-dom-solidity": "Communicating between chains in Solidity",
-  "cross-dom-bridge-eth": "Bridging ETH with the Optimism SDK",
+  "cross-dom-bridge-eth": "Bridging ETH with Viem",
   "cross-dom-bridge-erc20": "Bridging ERC-20 tokens with the Optimism SDK",
   "standard-bridge-custom-token": "Bridging your custom ERC-20 token to OP Mainnet",
   "standard-bridge-standard-token": "Bridging your standard ERC-20 token to OP Mainnet",

pages/builders/app-developers/tutorials/cross-dom-bridge-eth.mdx

@@ -1,12 +1,12 @@
 ---
-title: Bridging ETH with viem
+title: Bridging ETH with Viem
 lang: en-US
 description: Learn how to use Viem to transfer ETH between Layer 1 (Ethereum or Sepolia) and Layer 2 (OP Mainnet or OP Sepolia).
 ---
 
 import { Callout, Steps, Tabs } from 'nextra/components'
 
-# Bridging ETH to OP Mainnet with viem
+# Bridging ETH to OP Mainnet with Viem
 
 This tutorial explains how you can use [Viem](https://viem.sh) to bridge ETH from L1 (Ethereum or Sepolia) to L2 (OP Mainnet or OP Sepolia).
 Viem is a TypeScript interface for Ethereum that provides low-level stateless primitives for interacting with Ethereum.
@@ -45,7 +45,7 @@ Since Viem is a [Node.js](https://nodejs.org/en/) library, you'll need to create
   pnpm init
   ```
 
-  {<h3>Install the viem library</h3>}
+  {<h3>Install the Viem library</h3>}
 
   ```bash
   pnpm add viem
@@ -92,7 +92,7 @@ This will bring up a Node REPL prompt that allows you to run JavaScript code.
 You need to import some dependencies into your Node REPL session.
 
 <Steps>
-{<h3>Import viem and other packages</h3>}
+{<h3>Import Viem and other packages</h3>}
 
 ```js file=<rootDir>/public/tutorials/cross-dom-bridge-eth.js#L3-L6 hash=88319dda3322e76accb9e50222d30abc
 ```

pages/builders/app-developers/tutorials/cross-dom-solidity.mdx

@@ -1,34 +1,32 @@
 ---
-title: Communicating between OP Mainnet and Ethereum in Solidity
+title: Communicating between OP Stack and Ethereum in Solidity
 lang: en-US
-description: Learn how to write Solidity contracts on OP Mainnet and Ethereum that can talk to each other.
+description: Learn how to write Solidity contracts on OP Stack and Ethereum that can talk to each other.
 ---
 
 import { Steps, Callout, Tabs } from 'nextra/components'
-import { WipCallout } from '@/components/WipCallout'
 
-<WipCallout />
-# Communicating between OP Mainnet and Ethereum in Solidity
+# Communicating between OP Stack and Ethereum in Solidity
 
-This tutorial explains how to write Solidity contracts on OP Mainnet and Ethereum that can talk to each other.
-Here you'll use a contract on OP Mainnet that can set a "greeting" variable on a contract on Ethereum, and vice-versa.
+This tutorial explains how to write Solidity contracts on OP Stack and Ethereum that can talk to each other.
+Here you'll use a contract on OP Stack that can set a "greeting" variable on a contract on Ethereum, and vice-versa.
 This is a simple example, but the same technique can be used to send any kind of message between the two chains.
 
 You won't actually be deploying any smart contracts as part of this tutorial.
-Instead, you'll reuse existing contracts that have already been deployed to OP Mainnet and Ethereum.
+Instead, you'll reuse existing contracts that have already been deployed to OP Stack and Ethereum.
 Later in the tutorial you'll learn exactly how these contracts work so you can follow the same pattern to deploy your own contracts.
 
 <Callout type="info">
-Just looking to bridge tokens between OP Mainnet and Ethereum?
-Check out the tutorial on [Bridging ERC-20 Tokens to OP Mainnet With the Optimism SDK](./cross-dom-bridge-erc20).
+Just looking to bridge tokens between OP Stack and Ethereum?
+Check out the tutorial on [Bridging ERC-20 Tokens to OP Stack With the viem](./cross-dom-bridge-erc20).
 </Callout>
 
 ## Message passing basics
 
-OP Mainnet uses a smart contract called the `CrossDomainMessenger` to pass messages between OP Mainnet and Ethereum.
+OP Stack uses a smart contract called the `CrossDomainMessenger` to pass messages between OP Stack and Ethereum.
 Both chains have a version of this contract (the `L1CrossDomainMessenger` and the `L2CrossDomainMessenger`).
-Messages sent from Ethereum to OP Mainnet are automatically relayed behind the scenes.
-Messages sent from OP Mainnet to Ethereum must be explicitly relayed with a second transaction on Ethereum.
+Messages sent from Ethereum to OP Stack are automatically relayed behind the scenes.
+Messages sent from OP Stack to Ethereum must be explicitly relayed with a second transaction on Ethereum.
 Read more about message passing in the guide to [Sending Data Between L1 and L2](/builders/app-developers/bridging/messaging).
 
 ## Dependencies
@@ -80,8 +78,8 @@ It will take a few minutes for your message to reach L2.
 Feel free to take a quick break while you wait.
 
 <Callout type="info">
-You can use the Optimism SDK to programmatically check the status of any message between L1 and L2.
-Later on in this tutorial you'll learn how to use the Optimism SDK and the `waitForMessageStatus` function to wait for various message statuses.
+You can use Viem to programmatically check the status of any message between L1 and L2.
+Later on in this tutorial you'll learn how to use Viem and the `waitToProve` function to wait for various message statuses.
 This same function can be used to wait for a message to be relayed from L1 to L2.
 </Callout>
 
@@ -127,36 +125,27 @@ Feel free to keep this tab open so you can easily copy the transaction hash late
 
 {<h3>Create a demo project folder</h3>}
 
-You're going to use the Optimism SDK to prove and relay your message to L1.
-Since the Optimism SDK is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it.
+You're going to use the viem to prove and relay your message to L1.
 
 ```bash
-mkdir op-sample-project
-cd op-sample-project
+mkdir cross-dom
+cd cross-dom
 ```
 
-{<h3>Initialize the Project</h3>}
+{<h3>Initialize the project</h3>}
 
 Set up the project as a basic Node.js project with `pnpm` or your favorite package manager.
 
 ```bash
 pnpm init
 ```
 
-{<h3>Install the Optimism SDK</h3>}
+{<h3>Install viem</h3>}
 
-Install the Optimism SDK with `pnpm` or your favorite package manager.
+Install Viem with `pnpm` or your favorite package manager.
 
 ```bash
-pnpm add @eth-optimism/sdk
-```
-
-{<h3>Install ethers.js</h3>}
-
-Install `ethers` with `pnpm` or your favorite package manager.
-
-```bash
-pnpm add ethers@^5
+pnpm add viem
 ```
 
 {<h3>Add your private key to your environment</h3>}
@@ -187,46 +176,27 @@ Start the Node.js REPL with the `node` command.
 node
 ```
 
-{<h3>Import the Optimism SDK</h3>}
-
-```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L3 hash=26b2fdb17dd6c8326a54ec51f0769528
-```
-
-{<h3>Import ethers.js</h3>}
+{<h3>Import Viem</h3>}
 
-```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L4 hash=69a65ef97862612e4978b8563e6dbe3a
-```
-
-{<h3>Load your private key</h3>}
-
-```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L6 hash=755b77a7ffc7dfdc186f36c37d3d847a
+```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L3-L5 hash=65b9a5ad5b634bc2e424f5664e6e1f84
 ```
 
 {<h3>Load your transaction hash</h3>}
 
-```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L8 hash=320cd4f397d7bed8d914d4be0c99f8dc
+```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L7 hash=320cd4f397d7bed8d914d4be0c99f8dc
 ```
 
 {<h3>Create the RPC providers and wallets</h3>}
 
-```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L10-L13 hash=9afdce50665ae93bce602068071ffaa1
-```
-
-{<h3>Create a CrossChainMessenger instance</h3>}
-
-The Optimism SDK exports a `CrossChainMessenger` class that makes it easy to prove and relay cross-chain messages.
-
-Create an instance of the `CrossChainMessenger` class:
-
-```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L15-L20 hash=997b9c4cdd5fb1f9d4e0882a683ae016
+```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L8-L9 hash=d47e4991c5153e1e1dc55de5047a8a3e
 ```
 
 {<h3>Wait until the message is ready to prove</h3>}
 
-The second step to send messages from L2 to L1 is to prove that the message was sent on L2.
+Next, you will send messages from L2 to L1 is to prove that the message was sent on L2.
 You first need to wait until the message is ready to prove.
 
-```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L23 hash=25a072666b6147f8d8983d8223f045b8
+```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L12-L16 hash=df275e659d954eb72b8c5765d9baf6de
 ```
 
 <Callout type="info">
@@ -238,34 +208,34 @@ Feel free to take a quick break while you wait.
 
 Once the message is ready to be proven, you'll send an L1 transaction to prove that the message was sent on L2.
 
-```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L26 hash=17922abea43b3d379404fedd87422dde
+```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L18-L23 hash=e4d608ac2c2ceb5a744c8474679bd8cb
 ```
 
 {<h3>Wait until the message is ready for relay</h3>}
 
 The final step to sending messages from L2 to L1 is to relay the messages on L1.
 This can only happen after the fault proof period has elapsed.
-On OP Mainnet, this takes 7 days.
+On OP Stack, this takes 7 days.
 
 <Callout>
 We're currently testing fault proofs on OP Sepolia, so withdrawal times reflect Mainnet times.
 </Callout>
 
-```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L29 hash=45d995aab47ec29afee4bb4577ae9303
+```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L25-L29 hash=88cec1db2fde515ea9008eaa1bbdfd73
 ```
 
 {<h3>Relay the message on L1</h3>}
 
 Once the withdrawal is ready to be relayed you can finally complete the message sending process.
 
-```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L32 hash=b5515811ffcf8b9ada15dea8ae666e44
+```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L31-L33 hash=d7e47c9787d92e2140622a6bdcc6d7bb
 ```
 
 {<h3>Wait until the message is relayed</h3>}
 
 Now you simply wait until the message is relayed.
 
-```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L35 hash=d6e7f89e929eea0ac3217a6751b7e578
+```js file=<rootDir>/public/tutorials/cross-dom-solidity.js#L35-L36 hash=4ff3cdc48f17cfd7de4a6ef2d2671dc2
 ```
 
 {<h3>Check the L1 Greeter</h3>}
@@ -348,10 +318,10 @@ You can follow a similar pattern in your own smart contracts.
 ## Conclusion
 
 You just learned how you can write Solidity contracts on Sepolia and OP Sepolia that can talk to each other.
-You can follow the same pattern to write contracts that can talk to each other on Ethereum and OP Mainnet.
+You can follow the same pattern to write contracts that can talk to each other on Ethereum and OP Stack.
 
 This sort of cross-chain communication is useful for a variety of reasons.
-For example, the [Standard Bridge](/builders/app-developers/bridging/standard-bridge) contracts use this same system to bridge ETH and ERC-20 tokens between Ethereum and OP Mainnet.
+For example, the [Standard Bridge](/builders/app-developers/bridging/standard-bridge) contracts use this same system to bridge ETH and ERC-20 tokens between Ethereum and OP Stack.
 
-One cool way to take advantage of cross-chain communication is to do most of your heavy lifting on OP Mainnet and then send a message to Ethereum only when you have important results to share.
-This way you can take advantage of the low gas costs on OP Mainnet while still being able to use Ethereum when you need it.
+One cool way to take advantage of cross-chain communication is to do most of your heavy lifting on OP Stack and then send a message to Ethereum only when you have important results to share.
+This way you can take advantage of the low gas costs on OP Stack while still being able to use Ethereum when you need it.

pages/builders/app-developers/tutorials/send-tx-from-eth.mdx

@@ -5,9 +5,7 @@ description: Learn how to force transaction inclusion without the OP Stack Seque
 ---
 
 import { Callout, Steps } from 'nextra/components'
-import { WipCallout } from '@/components/WipCallout'
 
-<WipCallout />
 # Triggering OP Stack transactions from Ethereum
 
 OP Stack currently uses a single-Sequencer block production model.

pages/builders/chain-operators/configuration/batcher.mdx

@@ -262,24 +262,24 @@ default value is `10`.
   <Tabs.Tab>`OP_BATCHER_NUM_CONFIRMATIONS=10`</Tabs.Tab>
 </Tabs>
 
-### altda.da-server
+### plasma.da-server
 
 HTTP address of a DA Server.
 
 <Tabs items={['Syntax', 'Example', 'Environment Variable']}>
-  <Tabs.Tab>`--altda.da-server=<value>`</Tabs.Tab>
-  <Tabs.Tab>`--altda.da-server=`</Tabs.Tab>
+  <Tabs.Tab>`--plasma.da-server=<value>`</Tabs.Tab>
+  <Tabs.Tab>`--plasma.da-server=`</Tabs.Tab>
   <Tabs.Tab>`OP_BATCHER_PLASMA_DA_SERVER=`</Tabs.Tab>
 </Tabs>
 
-### altda.da-service
+### plasma.da-service
 
 Use DA service type where commitments are generated by plasma server. The 
 default value is `false`.
 
 <Tabs items={['Syntax', 'Example', 'Environment Variable']}>
-  <Tabs.Tab>`--altda.da-service=<value>`</Tabs.Tab>
-  <Tabs.Tab>`--altda.da-service=false`</Tabs.Tab>
+  <Tabs.Tab>`--plasma.da-service=<value>`</Tabs.Tab>
+  <Tabs.Tab>`--plasma.da-service=false`</Tabs.Tab>
   <Tabs.Tab>`OP_BATCHER_PLASMA_DA_SERVICE=false`</Tabs.Tab>
 </Tabs>
 

pages/builders/chain-operators/management/key-management.mdx

@@ -21,7 +21,7 @@ are compromised, the system can be exploited.
 
 It is up to the chain operator to make the decision on how they want to manage
 these keys. One suggestion is to use a Hardware Security Module (HSM) to provide
-a safer environment for key management. Cloud providers often times provide 
+a safer environment for key management. Cloud providers oftentimes provide 
 Key Management Systems (KMS) that can work with your developer operations 
 configurations. This can be used in conjunction with the `eth_signTransaction`
 RPC method.

pages/builders/chain-operators/management/troubleshooting.mdx

@@ -33,7 +33,7 @@ export IMPL_SALT=$(openssl rand -hex 32)
 
 ## Failed to find the L2 Heads to start from
 
-`op-node` fails to execute the derviation process with the following error:
+`op-node` fails to execute the derivation process with the following error:
 
 ```text
 WARN [02-16|21:22:02.868] Derivation process temporary error       attempts=14 err="stage 0 failed resetting: temp: failed to find the L2 Heads to start from: failed to fetch L2 block by hash 0x0000000000000000000000000000000000000000000000000000000000000000: failed to determine block-hash of hash 0x0000000000000000000000000000000000000000000000000000000000000000, could not get payload: not found"

pages/builders/chain-operators/tools/chain-monitoring.mdx

@@ -19,12 +19,12 @@ Onchain monitoring services provide insights into the overall system, helping ch
 
 Monitorism is a tooling suite that supports monitoring and active remediation actions for the OP Stack chain. Monitorism uses monitors as passive security providing automated monitoring for the OP Stack. They are used to monitor the OP stack and alert on specific events that could be a sign of a security incident.
 
-Currently. the list of monitors includes:
+Currently, the list of monitors includes:
 
 Security integrity monitors: These are monitors necessary for making sure Bridges between L2 and L1 are safe and work as expected. These monitors are divided in two subgroups:
 
 *   Pre-Faultproof Chain Monitors:
-    *   Fault Monitor: checks for changes in output roots posted to the L2OutputOracle contract. When a change is detected, it reconstructs the output root from a trusted L2 source and looks for a match..
+    *   Fault Monitor: checks for changes in output roots posted to the L2OutputOracle contract. When a change is detected, it reconstructs the output root from a trusted L2 source and looks for a match.
     *   Withdrawals Monitor: checks for new withdrawals that have been proven to the OptimismPortal contract. Each withdrawal is checked against the `L2ToL1MessagePasser` contract.
 *   Faultproof chain monitors:
     *   Faultproof Withdrawal: The Faultproof Withdrawal component monitors `ProvenWithdrawals` events on the `OptimismPortal` contract and performs checks to detect any violations of invariant conditions on the chain. If a violation is detected, the issue is logged, and a Prometheus metric is set for the event. This component is designed to work exclusively with chains that are already utilizing the Fault Proofs system. This is a new version of the deprecated `chain-mon`,  `faultproof-wd-mon`. For detailed information on how the component works and the algorithms used, please refer to the component README.
@@ -34,7 +34,7 @@ Security monitors: Those tools monitor other aspects of several contracts used i
 *   Global Events Monitor: made for taking YAML rules as configuration and monitoring the events that are emitted on the chain.
 *   Liveness Expiration Monitor: monitors the liveness expiration on Safes.
 *   Balances Monitor: emits a metric reporting the balances for the configured accounts.
-*   Multisig Monitor: The multisig monitor reports the paused status of the OptimismPortal contract. "If set, reports the latest nonce of the configured Safe address and the latest presigned nonce stored in One Password.. The latest presigned nonce is identified by looking for items in the configured vault that follow a `ready-<nonce>.json` name. The highest nonce of this item name format is reported.
+*   Multisig Monitor: The multisig monitor reports the paused status of the OptimismPortal contract. If set, reports the latest nonce of the configured Safe address and the latest presigned nonce stored in One Password.. The latest presigned nonce is identified by looking for items in the configured vault that follow a `ready-<nonce>.json` name. The highest nonce of this item name format is reported.
 *   Drippie Monitor: tracks the execution and executability of drips within a Drippie contract.
 *   Secrets Monitor: takes a Drippie contract as a parameter and monitors for any drips within that contract that use the `CheckSecrets` dripcheck contract. `CheckSecrets` is a dripcheck that allows a drip to begin once a specific secret has been revealed (after a delay period) and cancels the drip if a second secret is revealed. Monitoring these secrets is important, as their revelation may indicate that the secret storage platform has been compromised and someone is attempting to exfiltrate the ETH controlled by the drip.
 
@@ -76,9 +76,9 @@ Chain operators can easily create their grafana dashboard for Dispute Monitor us
 ## Offchain component monitoring
 
 Offchain monitoring allows chain operators to monitor the operation and behavior of nodes and other offchain components. Some of the more common components that you'll likely want to monitor include `op-node`, `op-geth`, `op-proposer`, `op-batcher`, and `op-challenger`.
-The general steps for enabling offchain monitoring is pretty consistent for all the OP components:
+The general steps for enabling offchain monitoring are pretty consistent for all the OP components:
 
-1.  Expose the monitoring port by enabling the `-—metrics.enabled` flag
+1.  Expose the monitoring port by enabling the `--metrics.enabled` flag
 2.  Customize the metrics port and address via the `--metrics.port` and `--metrics.addr` flags, respectively
 3.  Use [Prometheus](https://prometheus.io/) to scrape data from the metrics port
 4.  Save the data in `influxdb`