Arbitrum Nitro v3.8.0-rc.14

This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:v3.8.0-rc.14-0623d69
This Docker image specifies default flags in its entrypoint which should be replicated if you're overriding the entrypoint: /usr/local/bin/nitro --validation.wasm.allowed-wasm-module-roots /home/user/nitro-legacy/machines,/home/user/target/machines

If you're running a validator without a split validation server (this will be true of most validators), you should instead use the image offchainlabs/nitro-node:v3.8.0-rc.14-0623d69-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.

Note

This is a Release Candidate, and should only be used to upgrade nodes that are already running a previous release candidate.

Special Note about ArbOS 50 Support

Release v3.8.0-rc.14 is unrelated to ArbOS50. A future version of Nitro that supports ArbOS50 will eventually be mandatory if the DAO votes to adopt ArbOS50, but this will be addressed later.

Special Note For Database Schema

• Nitro 3.8.0 changes the database schema, so once a database has been run with 3.8.0, the database can no longer be opened with Nitro 3.7.x.

Schema Change

• ArbOS database schema version is updated to version 2. This is a one-way upgrade and nodes may not be downgraded to a pre-v3.8.0 release without restoring their database from a backup.

User-facing Changes

• Port - Fix fast confirm not working for EOA on pre - bold (#3902): #3903
• Port - Add hardcoded transaction hash and gas for ArbSepolia (#3876, #3901): #3904

Full Changelog: v3.8.0-rc.13...v3.8.0-rc.14

Arbitrum Nitro v3.8.0-rc.13

This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:v3.8.0-rc.13-1d5e968
This Docker image specifies default flags in its entrypoint which should be replicated if you're overriding the entrypoint: /usr/local/bin/nitro --validation.wasm.allowed-wasm-module-roots /home/user/nitro-legacy/machines,/home/user/target/machines

If you're running a validator without a split validation server (this will be true of most validators), you should instead use the image offchainlabs/nitro-node:v3.8.0-rc.13-1d5e968-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.

Note

This is a Release Candidate, and should only be used to upgrade nodes that are already running a previous release candidate.

Special Note about ArbOS 50 Support

Release v3.8.0-rc.13 is unrelated to ArbOS50. A future version of Nitro that supports ArbOS50 will eventually be mandatory if the DAO votes to adopt ArbOS50, but this will be addressed later.

Special Note For Database Schema

• Nitro 3.8.0 changes the database schema, so once a database has been run with 3.8.0, the database can no longer be opened with Nitro 3.7.x.

Schema Change

• ArbOS database schema version is updated to version 2. This is a one-way upgrade and nodes may not be downgraded to a pre-v3.8.0 release without restoring their database from a backup.

What's Changed

Improve node stability, fix feed issues and reduce warning log messages

Internal Highlights

• getNextBlockToRead does not depend on FillInBatchGasField (#3851): #3864
• Exclude BatchDataStats from feed for old ArbOS versions (#3853): #3866
• Fix broadcast client shutdown deadlock: #3885
• Turn off feed-signed flag for arbSepolia: #3895
• Revert #3866 Exclude BatchDataStats from feed for old ArbOS versions: #3866

Full Changelog: v3.8.0-rc.12...v3.8.0-rc.13

Arbitrum Nitro v3.8.0-rc.12

This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:v3.8.0-rc.12-28ae8ba
This Docker image specifies default flags in its entrypoint which should be replicated if you're overriding the entrypoint: /usr/local/bin/nitro --validation.wasm.allowed-wasm-module-roots /home/user/nitro-legacy/machines,/home/user/target/machines

If you're running a validator without a split validation server (this will be true of most validators), you should instead use the image offchainlabs/nitro-node:v3.8.0-rc.12-28ae8ba-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.

Note

This release should only be used by batch posters on L2 chains that submit blobs to L1 Sepolia for DA. These batch posters will need to upgrade to this release before Sepolia activates the fusaka hardfork on October 14th 2025. A new version of Nitro will be released more than 7 days before Mainnet Ethereum activates fusaka hardfork which is currently expected occur early December 2025.

Special Note about ArbOS 50 Support

Release v3.8.0-rc.12 is unrelated to ArbOS50. A future version of Nitro that supports ArbOS50 will eventually be mandatory if the DAO votes to adopt ArbOS50, but this will be addressed later.

Special Note For Database Schema

• Nitro 3.8.0 changes the database schema, so once a database has been run with 3.8.0, the database can no longer be opened with Nitro 3.7.x.

Special Notes about log index system changes to filtermaps from upstream go-ethereum

• Nitro 3.7.0 pulled in go-ethereum 1.15.6 which changed log index from bloombits to filtermap. This means that database previously running pre-Nitro 3.7.0 on startup there will be elevated CPU usage for 50+ hours while new FilterMaps are generated for log indexing. If log queries are not used, the parameter --execution.rpc.log-no-history can be used to completely disable log indexing.
• Nitro 3.7.0 pulled in go-ethereum 1.15.11 which includes a brand new log indexing system called filtermaps that has resulted in an increase in log indexing latency due to Nitro’s current reliance on HashDB (instead of PathDB). In some cases, this can delay log queries from being served anywhere between 5 seconds to 2 minutes on Arbitrum One during long tail unindexing. We’ve observed that this happens roughly once per day based on Arbitrum One mainnet traffic levels. Teams who need to serve log queries with consistent latency (e.g. eth_getLogs, eth_getFilterLogs, eth_getFilterChanges) can use the configuration parameter --execution.rpc.log-history=0 to keep all log history, which will only slightly increase database growth. Teams running their own log indexer may be unaffected. At some point, a future release of Nitro is expected to fix the issue of log index pruning being able to block log queries.

What's Changed

• Fix out of bounds config access in dataposter by @Tristan-Wilson in #3839

Full Changelog: v3.8.0-rc.11...v3.8.0-rc.12

Arbitrum Nitro v3.8.0-rc.11

This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:v3.8.0-rc.11-2bfbe14
This Docker image specifies default flags in its entrypoint which should be replicated if you're overriding the entrypoint: /usr/local/bin/nitro --validation.wasm.allowed-wasm-module-roots /home/user/nitro-legacy/machines,/home/user/target/machines

If you're running a validator without a split validation server (this will be true of most validators), you should instead use the image offchainlabs/nitro-node:v3.8.0-rc.11-2bfbe14-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.

Note

This release should only be used by batch posters on L2 chains that submit blobs to L1 Sepolia for DA. These batch posters will need to upgrade to this release before Sepolia activates the fusaka hardfork on October 14th 2025. A new version of Nitro will be released more than 7 days before Mainnet Ethereum activates fusaka hardfork which is currently expected occur early December 2025.

Special Note about ArbOS 50 Support

Release v3.8.0-rc.11 is unrelated to ArbOS50. A future version of Nitro that supports ArbOS50 will eventually be mandatory if the DAO votes to adopt ArbOS50, but this will be addressed later.

Special Note For Database Schema

• Nitro 3.8.0 changes the database schema, so once a database has been run with 3.8.0, the database can no longer be opened with Nitro 3.7.x.

Special Notes about log index system changes to filtermaps from upstream go-ethereum

• Nitro 3.7.0 pulled in go-ethereum 1.15.6 which changed log index from bloombits to filtermap. This means that database previously running pre-Nitro 3.7.0 on startup there will be elevated CPU usage for 50+ hours while new FilterMaps are generated for log indexing. If log queries are not used, the parameter --execution.rpc.log-no-history can be used to completely disable log indexing.
• Nitro 3.7.0 pulled in go-ethereum 1.15.11 which includes a brand new log indexing system called filtermaps that has resulted in an increase in log indexing latency due to Nitro’s current reliance on HashDB (instead of PathDB). In some cases, this can delay log queries from being served anywhere between 5 seconds to 2 minutes on Arbitrum One during long tail unindexing. We’ve observed that this happens roughly once per day based on Arbitrum One mainnet traffic levels. Teams who need to serve log queries with consistent latency (e.g. eth_getLogs, eth_getFilterLogs, eth_getFilterChanges) can use the configuration parameter --execution.rpc.log-history=0 to keep all log history, which will only slightly increase database growth. Teams running their own log indexer may be unaffected. At some point, a future release of Nitro is expected to fix the issue of log index pruning being able to block log queries.

What's Changed

• Toggle rpc endpoint used on errors (3.8.0 backport) by @gligneul in #3837

Full Changelog: v3.8.0-rc.10...v3.8.0-rc.11

Arbitrum Nitro v3.7.6

This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node: v3.7.6-c0fe95e
This Docker image specifies default flags in its entrypoint which should be replicated if you're overriding the entrypoint: /usr/local/bin/nitro --validation.wasm.allowed-wasm-module-roots /home/user/nitro-legacy/machines,/home/user/target/machines

If you're running a validator without a split validation server (this will be true of most validators), you should instead use the image offchainlabs/nitro-node: v3.7.6-c0fe95e-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.

Special Note 1

Nitro 3.7.0 pulls in go-ethereum 1.15.6 which changed log index from bloombits to filtermap. This means that on startup there will be elevated CPU usage for 50+ hours while new FilterMaps are generated for log indexing. If log queries are not used, the parameter --execution.rpc.log-no-history can be used to completely disable log indexing.

Special Note 2

Nitro 3.7.0 pulls in go-ethereum 1.15.11 which includes a brand new log indexing system called filtermaps that has resulted in an increase in log indexing latency due to Nitro’s current reliance on HashDB (instead of PathDB). In some cases, this can delay log queries from being served anywhere between 5 seconds to 2 minutes on Arbitrum One during long tail unindexing. We’ve observed that this happens roughly once per day based on Arbitrum One mainnet traffic levels. Teams who need to serve log queries with consistent latency (e.g. eth_getLogs, eth_getFilterLogs, eth_getFilterChanges) can use the configuration parameter --execution.rpc.log-history=0 to keep all log history, which will only slightly increase database growth. As above, there will likely be elevated CPU usage for some time while it creates new indexes. Teams running their own log indexer may be unaffected. At some point, a future release Nitro is expected to fix the issue of log index pruning being able to block log queries.

What's Changed

Automatically handle beacon RPC changes before Fusaka and after Fusaka hard fork.

This PR also introduces a --parent-chain.blob-client.dangerous.skip-blob-proof-verification flag which allows skipping the verification of blob proofs returned from the beacon client. This allows the node to be robust when connecting to a beacon node client like Teku which doesn't provide blob proofs after the fusaka fork AND doesn't support the new blobs endpoint.

User-facing Changes

• Attempt both blob_sidecars and blobs beacon api endpoints and add skip KZG flag: #3836

Full Changelog: v3.7.5...v3.7.6

Arbitrum Nitro v3.8.0-rc.9

This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:v3.8.0-rc.9-899f8da
This Docker image specifies default flags in its entrypoint which should be replicated if you're overriding the entrypoint: /usr/local/bin/nitro --validation.wasm.allowed-wasm-module-roots /home/user/nitro-legacy/machines,/home/user/target/machines

If you're running a validator without a split validation server (this will be true of most validators), you should instead use the image offchainlabs/nitro-node:v3.8.0-rc.9-899f8da-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.

Note

This release should only be used by batch posters on L2 chains that submit blobs to L1 Sepolia for DA. These batch posters will need to upgrade to this release before Sepolia activates the fusaka hardfork on October 14th 2025. A new version of Nitro will be released more than 7 days before Mainnet Ethereum activates fusaka hardfork which is currently expected occur early December 2025.

Special Note about ArbOS 50 Support

Release v3.8.0-rc.9 is unrelated to ArbOS50. A future version of Nitro that supports ArbOS50 will eventually be mandatory if the DAO votes to adopt ArbOS50, but this will be addressed later.

Special Note For Database Schema

• Nitro 3.8.0 changes the database schema, so once a database has been run with 3.8.0, the database can no longer be opened with Nitro 3.7.x.

Special Notes about log index system changes to filtermaps from upstream go-ethereum

• Nitro 3.7.0 pulled in go-ethereum 1.15.6 which changed log index from bloombits to filtermap. This means that database previously running pre-Nitro 3.7.0 on startup there will be elevated CPU usage for 50+ hours while new FilterMaps are generated for log indexing. If log queries are not used, the parameter --execution.rpc.log-no-history can be used to completely disable log indexing.
• Nitro 3.7.0 pulled in go-ethereum 1.15.11 which includes a brand new log indexing system called filtermaps that has resulted in an increase in log indexing latency due to Nitro’s current reliance on HashDB (instead of PathDB). In some cases, this can delay log queries from being served anywhere between 5 seconds to 2 minutes on Arbitrum One during long tail unindexing. We’ve observed that this happens roughly once per day based on Arbitrum One mainnet traffic levels. Teams who need to serve log queries with consistent latency (e.g. eth_getLogs, eth_getFilterLogs, eth_getFilterChanges) can use the configuration parameter --execution.rpc.log-history=0 to keep all log history, which will only slightly increase database growth. Teams running their own log indexer may be unaffected. At some point, a future release of Nitro is expected to fix the issue of log index pruning being able to block log queries.

What's Changed

• Add support for new beacon chain /blobs endpoint: #3831

Full Changelog: v3.8.0-rc.8...v3.8.0-rc.9

v3.8.0-rc.10

This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:TBD
This Docker image specifies default flags in its entrypoint which should be replicated if you're overriding the entrypoint: /usr/local/bin/nitro --validation.wasm.allowed-wasm-module-roots /home/user/nitro-legacy/machines,/home/user/target/machines

If you're running a validator without a split validation server (this will be true of most validators), you should instead use the image offchainlabs/nitro-node:TBD-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.

Note

This release should only be used by batch posters on L2 chains that submit blobs to L1 Sepolia for DA. These batch posters will need to upgrade to this release before Sepolia activates the fusaka hardfork on October 14th 2025. A new version of Nitro will be released more than 7 days before Mainnet Ethereum activates fusaka hardfork which is currently expected occur early December 2025.

Special Note about ArbOS 50 Support

Release v3.8.0-rc.10 is unrelated to ArbOS50. A future version of Nitro that supports ArbOS50 will eventually be mandatory if the DAO votes to adopt ArbOS50, but this will be addressed later.

Special Note For Database Schema

• Nitro 3.8.0 changes the database schema, so once a database has been run with 3.8.0, the database can no longer be opened with Nitro 3.7.x.

Special Notes about log index system changes to filtermaps from upstream go-ethereum

• Nitro 3.7.0 pulled in go-ethereum 1.15.6 which changed log index from bloombits to filtermap. This means that database previously running pre-Nitro 3.7.0 on startup there will be elevated CPU usage for 50+ hours while new FilterMaps are generated for log indexing. If log queries are not used, the parameter --execution.rpc.log-no-history can be used to completely disable log indexing.
• Nitro 3.7.0 pulled in go-ethereum 1.15.11 which includes a brand new log indexing system called filtermaps that has resulted in an increase in log indexing latency due to Nitro’s current reliance on HashDB (instead of PathDB). In some cases, this can delay log queries from being served anywhere between 5 seconds to 2 minutes on Arbitrum One during long tail unindexing. We’ve observed that this happens roughly once per day based on Arbitrum One mainnet traffic levels. Teams who need to serve log queries with consistent latency (e.g. eth_getLogs, eth_getFilterLogs, eth_getFilterChanges) can use the configuration parameter --execution.rpc.log-history=0 to keep all log history, which will only slightly increase database growth. Teams running their own log indexer may be unaffected. At some point, a future release of Nitro is expected to fix the issue of log index pruning being able to block log queries.

What's Changed

• For L3 on arbitrum return false for shouldEnableCellProofs instread of erroring out: #3827
• backport #3828: don't open freezer for wasm and arbitrumdata databases: #3832
• Remove misleading blob-related dataposter config: #3833

Full Changelog: v3.8.0-rc.9...v3.8.0-rc.10

Arbitrum Nitro v3.7.5

Warning

If you are using v3.7.5 on mainnet ethereum, use --parent-chain.blob-client.use-legacy-endpoint to use the pre-fusaka blob API

This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:v3.7.5-91ebb83
This Docker image specifies default flags in its entrypoint which should be replicated if you're overriding the entrypoint: /usr/local/bin/nitro --validation.wasm.allowed-wasm-module-roots /home/user/nitro-legacy/machines,/home/user/target/machines

If you're running a validator without a split validation server (this will be true of most validators), you should instead use the image offchainlabs/nitro-node:v3.7.5-91ebb83-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.

Special Note 1

Nitro 3.7.0 pulls in go-ethereum 1.15.6 which changed log index from bloombits to filtermap. This means that on startup there will be elevated CPU usage for 50+ hours while new FilterMaps are generated for log indexing. If log queries are not used, the parameter --execution.rpc.log-no-history can be used to completely disable log indexing.

Special Note 2

Nitro 3.7.0 pulls in go-ethereum 1.15.11 which includes a brand new log indexing system called filtermaps that has resulted in an increase in log indexing latency due to Nitro’s current reliance on HashDB (instead of PathDB). In some cases, this can delay log queries from being served anywhere between 5 seconds to 2 minutes on Arbitrum One during long tail unindexing. We’ve observed that this happens roughly once per day based on Arbitrum One mainnet traffic levels. Teams who need to serve log queries with consistent latency (e.g. eth_getLogs, eth_getFilterLogs, eth_getFilterChanges) can use the configuration parameter --execution.rpc.log-history=0 to keep all log history, which will only slightly increase database growth. As above, there will likely be elevated CPU usage for some time while it creates new indexes. Teams running their own log indexer may be unaffected. At some point, a future release Nitro is expected to fix the issue of log index pruning being able to block log queries.

What's Changed

Added support for new beacon chain endpoint

User-facing Changes

• Remove pre sylus validation (#3785): #3793
• Add support for new beacon chain /blobs endpoint: #3826

Full Changelog: v3.7.4...v3.7.5

Arbitrum Nitro v3.7.5-rc.1

This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:v3.7.5-rc.1-91ebb83
This Docker image specifies default flags in its entrypoint which should be replicated if you're overriding the entrypoint: /usr/local/bin/nitro --validation.wasm.allowed-wasm-module-roots /home/user/nitro-legacy/machines,/home/user/target/machines

If you're running a validator without a split validation server (this will be true of most validators), you should instead use the image offchainlabs/nitro-node:v3.7.5-rc.1-91ebb83-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.

Special Note 1

Nitro 3.7.0 pulls in go-ethereum 1.15.6 which changed log index from bloombits to filtermap. This means that on startup there will be elevated CPU usage for 50+ hours while new FilterMaps are generated for log indexing. If log queries are not used, the parameter --execution.rpc.log-no-history can be used to completely disable log indexing.

Special Note 2

Nitro 3.7.0 pulls in go-ethereum 1.15.11 which includes a brand new log indexing system called filtermaps that has resulted in an increase in log indexing latency due to Nitro’s current reliance on HashDB (instead of PathDB). In some cases, this can delay log queries from being served anywhere between 5 seconds to 2 minutes on Arbitrum One during long tail unindexing. We’ve observed that this happens roughly once per day based on Arbitrum One mainnet traffic levels. Teams who need to serve log queries with consistent latency (e.g. eth_getLogs, eth_getFilterLogs, eth_getFilterChanges) can use the configuration parameter --execution.rpc.log-history=0 to keep all log history, which will only slightly increase database growth. As above, there will likely be elevated CPU usage for some time while it creates new indexes. Teams running their own log indexer may be unaffected. At some point, a future release Nitro is expected to fix the issue of log index pruning being able to block log queries.

What's Changed

Added support for new beacon chain endpoint

User-facing Changes

• Remove pre sylus validation (#3785): #3793
• Add support for new beacon chain /blobs endpoint: #3826

Full Changelog: v3.7.4...v3.7.5-rc.1

Arbitrum Nitro v3.8.0-rc.8

This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:v3.8.0-rc.8-146b5d2
This Docker image specifies default flags in its entrypoint which should be replicated if you're overriding the entrypoint: /usr/local/bin/nitro --validation.wasm.allowed-wasm-module-roots /home/user/nitro-legacy/machines,/home/user/target/machines

If you're running a validator without a split validation server (this will be true of most validators), you should instead use the image offchainlabs/nitro-node:v3.8.0-rc.8-146b5d2-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.

Note

This release should only be used by batch posters on L2 chains that submit blobs to L1 Sepolia for DA. These batch posters will need to upgrade to this release before Sepolia activates the fusaka hardfork on October 14th 2025. A new version of Nitro will be released more than 7 days before Mainnet Ethereum activates fusaka hardfork which is currently expected occur early December 2025.

Special Note about ArbOS 50 Support

Release v3.8.0-rc.8 is unrelated to ArbOS50. A future version of Nitro that supports ArbOS50 will eventually be mandatory if the DAO votes to adopt ArbOS50, but this will be addressed later.

Special Note For Database Schema

• Nitro 3.8.0 changes the database schema, so once a database has been run with 3.8.0, the database can no longer be opened with Nitro 3.7.x.

Special Notes about log index system changes to filtermaps from upstream go-ethereum

• Nitro 3.7.0 pulled in go-ethereum 1.15.6 which changed log index from bloombits to filtermap. This means that database previously running pre-Nitro 3.7.0 on startup there will be elevated CPU usage for 50+ hours while new FilterMaps are generated for log indexing. If log queries are not used, the parameter --execution.rpc.log-no-history can be used to completely disable log indexing.
• Nitro 3.7.0 pulled in go-ethereum 1.15.11 which includes a brand new log indexing system called filtermaps that has resulted in an increase in log indexing latency due to Nitro’s current reliance on HashDB (instead of PathDB). In some cases, this can delay log queries from being served anywhere between 5 seconds to 2 minutes on Arbitrum One during long tail unindexing. We’ve observed that this happens roughly once per day based on Arbitrum One mainnet traffic levels. Teams who need to serve log queries with consistent latency (e.g. eth_getLogs, eth_getFilterLogs, eth_getFilterChanges) can use the configuration parameter --execution.rpc.log-history=0 to keep all log history, which will only slightly increase database growth. Teams running their own log indexer may be unaffected. At some point, a future release of Nitro is expected to fix the issue of log index pruning being able to block log queries.

What's Changed

• Backport Correct the order TransactionStreamer and PopulateFeedBacklog: #3813
• Reject Estimates for BoLD Txs that Exceed Fusaka's Max Tx Gas Cap: #3815

Full Changelog: v3.8.0-rc.7...v3.8.0-rc.8