You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+17Lines changed: 17 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -128,6 +128,23 @@ This part will update the glossary.
128
128
129
129
4. Commit your changes and open a PR.
130
130
131
+
### Update Nitro CLI flag reference
132
+
133
+
`docs/run-arbitrum-node/nitro/cli-flags-reference.mdx` is auto-generated from `scripts/data/nitro-cli-flags.json` by `scripts/generate-cli-reference.ts`. Do not edit the `.mdx` file by hand — your changes will be overwritten on the next regeneration.
134
+
135
+
To regenerate the reference after updating the JSON data file:
136
+
137
+
```shell
138
+
yarn generate-cli-reference
139
+
```
140
+
141
+
To verify the committed `.mdx` is in sync with the JSON data (used in CI):
142
+
143
+
```shell
144
+
yarn generate-cli-reference --check
145
+
```
146
+
147
+
The script also accepts `--output <path>` to write to a different location and `--nitro-path <path>` (or the `NITRO_REPO_PATH` env var) to point at a local Nitro checkout — useful when refreshing the JSON data against a specific Nitro version.
131
148
### Restructuring docs (moving or renaming pages)
132
149
133
150
The tooling handles internal links, the moved file's own relative links, sidebar entries,
description: 'Reference list of chainConfig JSON parameters available when deploying or managing your Arbitrum chain.'
4
+
content_type: reference
5
+
sidebar_label: chainConfig reference
6
+
---
7
+
8
+
The full `chainConfig` contains the standard Ethereum genesis/fork fields, but the [Chain SDK](https://github.com/OffchainLabs/arbitrum-chain-sdk)'s [`prepareChainConfig()`](https://github.com/OffchainLabs/arbitrum-chain-sdk/blob/main/src/prepareChainConfig.ts) only exposes a small subset for customization. Everything else is filled from hardcoded `defaults` and should not be changed.
9
+
10
+
When you call `prepareChainConfig`, you pass a `chainId` (top-level) and an `arbitrum` object where `InitialChainOwner` is required and the fields below are optional overrides.
|`AllowDebugPrecompiles`|`false`| Debug precompiles; must stay disabled. |
50
+
51
+
## Standard fields
52
+
53
+
:::warning For informational purposes only
54
+
55
+
The following fields are populated automatically from the SDK's hardcoded `defaults`. They are standard Ethereum genesis/fork-activation parameters and are **not** exposed for customization by `prepareChainConfig`.
56
+
57
+
**Changing these fields can produce an invalid or non-functional chain configuration**.
Copy file name to clipboardExpand all lines: docs/launch-arbitrum-chain/operate/batch-poster-troubleshooting.mdx
+8-9Lines changed: 8 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,11 +27,11 @@ The [Monitoring tools and considerations](/launch-arbitrum-chain/operate/monitor
27
27
-**Query the balance directly**: Use the parent chain RPC to check the batch poster EOA balance at regular intervals.
28
28
-**Set up alerting**: Configure external monitoring (e.g., a balance-checking script, onchain monitoring service, or infrastructure alerting tool) to notify you when the balance drops below a threshold.
There is no universally recommended balance threshold—the appropriate level depends on your parent chain's gas prices, your chain's batch posting frequency, and batch sizes. As a general approach, estimate your daily batch posting cost (number of batches per day multiplied by average gas cost per batch) and maintain a buffer of several days' worth of posting costs. Monitor actual spending over time and adjust accordingly.
33
33
34
-
:::
34
+
</VanillaAdmonition>
35
35
36
36
### Funding strategy
37
37
@@ -57,11 +57,11 @@ This error indicates that the parent chain node's mempool has rejected a transac
57
57
2.**Review your queued transaction storage configuration**: If you're using DB or Redis storage, pending transactions accumulate and rely on RBF for inclusion. Consider whether your RBF schedule (`--node.batch-poster.data-poster.replacement-times` for non-blob batch poster, `--node.batch-poster.data-poster.blob-tx-replacement-times` for blob batch poster) is escalating fees quickly enough. See Queued transaction database selection for storage option details.
58
58
3.**Consider Noop storage for parent chains without mempools**: If your parent chain is an Arbitrum chain or another chain without a traditional mempool, Noop storage avoids this issue entirely by waiting for each transaction receipt before submitting the next one.
The exact mempool weight limits depend on the parent chain node’s configuration, not the batch poster itself. The batch poster does not control the parent chain node’s mempool size. If you are running your own parent chain node, consult its documentation for mempool configuration. If using a third-party RPC provider, the mempool limits are determined by the provider’s infrastructure.
63
63
64
-
:::
64
+
</VanillaAdmonition>
65
65
66
66
## Batch posting backlog diagnosis
67
67
@@ -83,11 +83,11 @@ A batch posting backlog occurs when the sequencer continues ordering transaction
83
83
-**Check the sequencer's transaction backlog size**: As noted in the [Monitoring tools and considerations](/launch-arbitrum-chain/operate/monitoring.mdx) guide, a large and growing backlog can be a sign of network health issues.
84
84
-**Review batch poster logs**: Look for error messages related to transaction submission failures, fee estimation errors, or the data poster pausing.
The specific log messages and metrics that indicate a backlog depend on the Nitro node version and configuration. Operators should familiarize themselves with their node’s log output during normal operation so that deviations are easier to spot. Key log prefixes to watch for include `BatchPoster:` and `DataPoster:` entries.
89
89
90
-
:::
90
+
</VanillaAdmonition>
91
91
92
92
### Resolution approaches
93
93
@@ -109,19 +109,18 @@ This error appears when the data poster attempts to resubmit a batch posting tra
109
109
-**Storage inconsistencies**: When using DB or Redis for queued transaction tracking, mismatches between the stored transaction state and the onchain state can cause resubmission failures. This can happen after a node restart if the storage wasn't cleanly synced.
110
110
-**Parent chain rejection**: The parent chain node may reject the replacement transaction for various reasons—the replacement fee isn't high enough (must be at least 10% higher for standard RBF), the transaction format is invalid, or the parent chain node is experiencing issues.
The exact phrasing and context of retry errors can vary across Nitro versions. The "failed to re-send transaction" message generally indicates an RBF attempt that didn't succeed. Check the surrounding log lines for more specific error details (for example, "nonce too low", "replacement transaction underpriced", or connection errors).
115
115
116
-
:::
116
+
</VanillaAdmonition>
117
117
118
118
### Resolution
119
119
120
120
1.**Check if the original transaction was included**: Query the parent chain for the batch poster’s latest nonce and compare it to what the data poster expects. If the original transaction was already included, the retry error is benign—the data poster should recover automatically on the next cycle.
121
121
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.
122
122
3.**Check parent chain connectivity**: Ensure the batch poster can reliably reach the parent chain RPC. Intermittent connectivity causes retry failures.
123
123
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.
124
-
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/operate/key-rotation.mdx) for context on when this flag is used.
Copy file name to clipboardExpand all lines: docs/launch-arbitrum-chain/operate/key-rotation.mdx
+14-32Lines changed: 14 additions & 32 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,22 +11,22 @@ content_type: how-to
11
11
12
12
This guide covers how to rotate keys for different roles in your Arbitrum Orbit chain: batch poster, validator/bonder, and Data Availability Servers (DAS).
For sequencer nodes running both the sequencer and batch poster on the same server, you **must** first split them and then configure Redis for message synchronization. Failure to do so may cause chain reorganizations. Refer to the [High Availability Sequencer documentation](/launch-arbitrum-chain/run-a-node/high-availability-sequencer.mdx) for setup instructions.
- Update your node configuration to use the new private key
56
56
- Restart the batch poster service with the new configuration
57
57
58
-
#### 3. Handle potential mempool issues
59
-
60
-
If you encounter the error: `"posting this transaction will exceed max mempool size: transaction nonce: xxx, unconfirmed nonce: xx, max mempool size: xx"`
61
-
62
-
**Temporary fix**:
63
-
64
-
- Add the `--node.batch-poster.data-poster.dangerous.clear-dbstorage` flag
65
-
- Restart the batch poster
66
-
-**Remove this flag** before the next start
67
-
68
-
#### 4. Verify operation
58
+
#### 3. Verify operation
69
59
70
60
- Monitor logs to confirm the new batch poster is successfully submitting batches
- Update your validator node configuration to use the new private key
102
92
- Restart the validator service
103
93
104
-
#### 3. Handle potential mempool issues
105
-
106
-
If you encounter the error: `"posting this transaction will exceed max mempool size: transaction nonce: xxx, unconfirmed nonce: xx, max mempool size: xx"`
107
-
108
-
- Add `--node.staker.data-poster.dangerous.clear-dbstorage` flag temporarily
109
-
- Restart the validator
110
-
-**Remove this flag** before the next start
111
-
112
-
#### 4. Verify the new validator operation
94
+
#### 3. Verify the new validator operation
113
95
114
96
- Monitor that the new validator successfully posts bond transactions
115
97
- Confirm that assertion and confirmation transactions are submitted successfully
116
98
117
-
#### 5. Disable the old validator
99
+
#### 4. Disable the old validator
118
100
119
101
```solidity
120
102
setValidator([<old_validator_address>], [false])
@@ -148,11 +130,11 @@ Call the following function on the `SequencerInbox` contract. The caller must be
148
130
setValidKeyset(<new_keyset_bytes>)
149
131
```
150
132
151
-
:::note
133
+
<VanillaAdmonitiontype="note">
152
134
153
135
The `setValidKeyset` function takes the raw keyset bytes as its only parameter. The assumed-honest count is encoded within the keyset bytes themselves during keyset generation — it is not a separate contract parameter.
154
136
155
-
:::
137
+
</VanillaAdmonition>
156
138
157
139
#### 3. Deploy new DAS servers
158
140
@@ -173,16 +155,16 @@ Once the new DAS servers and keyset are fully verified, you can optionally inval
173
155
invalidateKeysetHash(<old_keyset_hash>)
174
156
```
175
157
176
-
:::note
158
+
<VanillaAdmonitiontype="note">
177
159
178
160
After invalidating the old keyset, you **must** stop and restart the batch poster so it picks up the new keyset. If you skip this step, the batch poster will continue attempting to use the old (now invalid) keyset and fail to submit batches.
179
161
180
-
:::
162
+
</VanillaAdmonition>
181
163
182
-
:::caution
164
+
<VanillaAdmonitiontype="caution">
183
165
184
166
- You can obtain the old keyset hash from the `SetValidKeyset` event that was emitted when the old keyset was originally registered
185
167
- Do **not** invalidate the old keyset until the new keyset is fully verified and the batch poster is successfully posting with the new DAS servers — invalidating prematurely can disrupt data availability for your chain
186
168
- After invalidation, the old keyset can no longer be used to certify data availability certificates
0 commit comments