Nitro CLI documentation guide

docs/launch-arbitrum-chain/04-maintain-your-chain/04-guidance/batch-poster-troubleshooting.mdx

@@ -121,7 +121,6 @@ The exact phrasing and context of retry errors can vary across Nitro versions. T
 2. **Review the queued transaction storage**: If using DB or Redis, the stored transaction state may be stale. A node restart typically resolves transient storage inconsistencies.
 3. **Check parent chain connectivity**: Ensure the batch poster can reliably reach the parent chain RPC. Intermittent connectivity causes retry failures.
 4. **Inspect RBF fee escalation**: If the error mentions “replacement transaction underpriced”, the fee increase between attempts may be insufficient. The parent chain typically requires at least a 10% fee increase for RBF. Review the `blob-tx-replacement-times` schedule—shorter intervals may not allow enough price movement between attempts.
-5. **Consider clearing storage as a last resort**: The `--node.batch-poster.data-poster.dangerous.clear-dbstorage` flag clears the queued transaction database on startup. Use this only when necessary, as it discards any tracked pending transactions. See the [Node key rotation guide](/launch-arbitrum-chain/04-maintain-your-chain/04-guidance/key-rotation.mdx) for context on when this flag is used.
 
 ## Quick reference
 

docs/launch-arbitrum-chain/04-maintain-your-chain/04-guidance/key-rotation.mdx

@@ -55,22 +55,12 @@ setBatchPosterManager(<new_address>)
 - Update your node configuration to use the new private key
 - Restart the batch poster service with the new configuration
 
-#### 3. Handle potential mempool issues
-
-If you encounter the error: `"posting this transaction will exceed max mempool size: transaction nonce: xxx, unconfirmed nonce: xx, max mempool size: xx"`
-
-**Temporary fix**:
-
-- Add the `--node.batch-poster.data-poster.dangerous.clear-dbstorage` flag
-- Restart the batch poster
-- **Remove this flag** before the next start
-
-#### 4. Verify operation
+#### 3. Verify operation
 
 - Monitor logs to confirm the new batch poster is successfully submitting batches
 - Check that transactions are processing normally
 
-#### 5. Disable the old batch poster
+#### 4. Disable the old batch poster
 
 ```solidity
 setIsBatchPoster(<old_address>, false)
@@ -101,20 +91,12 @@ setValidator([<new_validator_address>], [true])
 - Update your validator node configuration to use the new private key
 - Restart the validator service
 
-#### 3. Handle potential mempool issues
-
-If you encounter the error: `"posting this transaction will exceed max mempool size: transaction nonce: xxx, unconfirmed nonce: xx, max mempool size: xx"`
-
-- Add `--node.staker.data-poster.dangerous.clear-dbstorage` flag temporarily
-- Restart the validator
-- **Remove this flag** before the next start
-
-#### 4. Verify the new validator operation
+#### 3. Verify the new validator operation
 
 - Monitor that the new validator successfully posts bond transactions
 - Confirm that assertion and confirmation transactions are submitted successfully
 
-#### 5. Disable the old validator
+#### 4. Disable the old validator
 
 ```solidity
 setValidator([<old_validator_address>], [false])

docs/launch-arbitrum-chain/05-customize-your-chain/customize-stf.mdx

@@ -72,7 +72,7 @@ Next, make your changes to the State Transition Function. For example, you could
 After this step, you should visit [Customize ArbOS version](./customize-arbos.mdx) to see if your changes need to upgrade the ArbOS version. If so, please continue
 follow that document to add an ArbOS upgrade logic to your code.
 
-### Step 3. Run the node without fraud proofs
+### Step 3. Run the node
 
 To build the Arbitrum Nitro node image, you'll first need to install Docker.
 You can confirm if it's already setup by running `docker version` in a terminal.
@@ -81,23 +81,13 @@ install Docker from your distribution's package manager and start the Docker ser
 
 Once you have Docker installed, you can simply run `docker build . --tag custom-nitro-node` in the `nitro` folder to build your custom node.
 
-Once you've built your new Nitro node image, you have to modify the configuration file of your node to add a new parameter, `--node.staker.dangerous.without-block-validator`, which disables fraud proof verification.
+:::note
 
-To do that, open your `nodeConfig.json` file (stored by default in the `config` folder) and add the new parameter inside the `staker` element:
+A chain running a customized State Transition Function will produce blocks that don't match the verified Nitro WASM module root on the parent chain. Coordinate with Offchain Labs before operating a customized STF against a production chain, as the validator configuration required is not covered in this guide.
 
-```json
-...
-"staker": {
-  ...
-  "dangerous": {
-    "without-block-validator": true
-  }
-  ...
-},
-...
-```
+:::
 
-With that, you have now two ways of running your node.
+You have two ways of running your node.
 
 #### 1. Using the docker-compose file
 
@@ -163,11 +153,9 @@ Once you have the WASM module root, you can put it onchain by calling `setWasmMo
 The `upgradeExecutor` contract address and Rollup contract address can be found in the chain deployment info JSON.
 You can confirm that the WASM module root was updated by calling `wasmModuleRoot()` on the Rollup contract.
 
-Once you have set the new WASM module root onchain, you can re-enable fraud proofs and run your node.
-
-To re-enable fraud proofs, open your `nodeConfig.json` file again, and remove the `"dangerous"` section (containing the `without-block-validator` property) that you previously added.
+Once you have set the new WASM module root onchain, the validator will recognize blocks produced by your customized STF. You can now run your node with fraud proof verification enabled.
 
-After that, you'll have, again, two ways of running your node.
+You have two ways of running your node.
 
 #### 1. Using the docker-compose file