BNB Smart Chain node requirements in 2026: full, fast and archive

A BNB Smart Chain full node needs 16 cores, 64 GB of RAM, a fast SSD and 5 MB/s of bandwidth, and a validator 128 GB, 7 TB of NVMe and 512 Mbps, per BNB Chain’s documentation. Disk is the moving target: October 2026 snapshots were about 1.9 TB pruned and 7.4 TB with full history, compressed.

Most of those figures predate the Fermi hard fork of January 14, 2026, which brought BSC to 0.45-second blocks. Below, we compare them with the October 2026 snapshots, name the archive client that replaced BSC-Erigon, and map each node type to a server.

The short version

Snapshot sizes are compressed downloads; BNB Chain asks for extra room to extract them. The docs’ archive figures were written for Erigon, now unmaintained.

BNB Chain’s official hardware requirements

BNB Chain’s requirements sit on pages that were not updated together. The Node Best Practices page, last updated on July 18, 2024, sets 16 cores and at least 5 MBps for every node type, plus:

• Fast node, labeled the “Recommended Configuration”: 32 GB of RAM and a 2 TB SSD.
• Full node: 64 GB of RAM and a 3 TB SSD.
• Archive node: 128 GB of RAM and 10 TB of SSD, NVMe “recommended for optimal performance”.

The bsc client’s README adds disk performance for a mainnet full node: “3 TB(Dec 2023) of free disk space”, 8k IOPS, 500 MB/s and read latency under 1 ms, on NVMe for snap sync, with 16 cores, 64 GB and 5 MB/s up and down, about 40 Mbit/s. The Node Maintenance page, updated in February 2026, repeats the disk figures.

Since April 2025, three hard forks have cut the block interval from 3 seconds to 1.5, 0.75 and 0.45, and the data grew with them: by the snapshot repository’s own rule of free space twice the snapshot’s size, the README’s 3 TB no longer covers even the pruned snapshot.

How much disk a BSC node needs in October 2026

BNB Chain advises against syncing from genesis and publishes monthly Geth snapshots in its bsc-snapshots repository: a full snapshot with every block since genesis, and a pruned one with the state and recent blocks only. Summing their file lists gives this growth curve, in compressed sizes:

Over twelve months the chain added about 62 million blocks; the full snapshot grew 73%, roughly 260 GB a month, and the pruned one 48%, roughly 50 GB a month, with a faster pace since August (about 350 and 75 GB). That is our arithmetic on BNB Chain’s file lists, not an official forecast. Three consequences:

• Plan for more than the download. The README asks for “extra disk space for extraction”, an older guide for “at least twice the size of the snapshot”. The pruned snapshot is one 1,899 GB archive, held next to its extracted data unless you stream the download into tar and skip the MD5 check.
• Smaller community snapshots exist. 48Club, credited in BNB Chain’s repository, published zstd snapshots of 1,371.98 GB (full node) and 460.87 GB (fast node) at block 127,680,000 on October 15, 2026, both set to keep the latest 600,000 blocks.
• Bandwidth sets the restore time. At a sustained 1 Gbps, the pruned snapshot takes about 4 hours and the full one 16½; at the documented 5 MB/s, 4½ and 17 days.

Fast node, pruned node or full history: which one you need

All three run the Geth-based bnb-chain/bsc client and differ in the history they keep and in state verification:

• Complete history is the default (--history.blocks 0, “entire chain”). It serves any old block, transaction or receipt, as explorers and indexers need, and costs the 7.4 TB above.
• Recent history: the pruned snapshot with --history.blocks=600000 and matching index limits keeps about 75 hours of blocks and still verifies every state root (--tries-verify-mode=local, the default).
• Fast node: --tries-verify-mode none skips state-root verification, with “a very small chance that the state is not consistent with other peers”, says the client’s help text. Once geth db delete-trie-state has run, “there is no way to switch back to Full Node” without a new snapshot.

None of these is an archive node. BNB Chain’s snapshot FAQ says only “the state of the most recent 129(128+1) blocks can be queried through RPC”, under a minute at 0.45 seconds per block, and that a fast node may return 0 instead of an error when state is missing. Balances or contract state at older blocks need an archive node.

A documentation trap: the Node Maintenance page still recommends --pruneancient and the offline prune-block tool. Release v1.5.18 deprecated the first and removed the second, both replaced by --history.blocks.

BSC archive node: Reth-BSC has replaced Erigon

BNB Chain’s archive node page, last updated in January 2025, still recommends NodeReal’s BSC-Erigon, able to “sync an archive node from scratch in just 3 days, using 4.3 TB of disk space”, with 64 GB of RAM and a 5 TB minimum. That advice has expired. BSC-Erigon’s end-of-life notice stopped development and maintenance after December 31, 2025 and points users to Reth-BSC; the repository was archived on April 23, 2026. Its last release, v1.4.3, predates the Mendel (April 2026) and Pasteur (August 2026) hard forks, both mandatory upgrades.

Its successor, Reth-BSC, lives in the bnb-chain GitHub organization:

• Maturity. Its README calls the project “experimental and under active development”. Release v0.1.1, of July 2026, scheduled the Pasteur hard fork on mainnet; v0.1.2 fixed a state-root issue at that transition.
• Size. The October 2, 2026 mainnet archive snapshot totals 7,461.58 GB in eight compressed files and asks for --db.max-size=12TB. On disk it takes more: the README cited 10.6 TB in September 2025, and in September 2026 an operator reported 793 GB of MDBX plus 12 TB of static files.
• Disk speed. On two September and October 2026 issues about archive nodes lagging on virtual or cloud disks, a project contributor named disk performance as the likely bottleneck and advised local NVMe. One operator fell behind above about 180 RPC requests per second.

Plan an archive node around 16 TB or more of local NVMe, rather than the 10 TB listed in 2024, and at least 16 cores and 128 GB. Reth-BSC’s README marks its --full mode “Recommended”; that mainnet snapshot was 3,473.25 GB on October 2.

BSC validator requirements: hardware and stake

The Run BSC Validator page, updated on February 6, 2026, sets a higher bar than any other node type:

• Compute: an AWS i7i.8xlarge or i7ie.6xlarge, “better to disable HyperThread, which could have 10%+ performance gain”, “or other instance spec to meet >=400 mgasps”. AWS lists them at 32 vCPUs with 256 GiB and 24 vCPUs with 192 GiB, on 5th-generation Xeon Scalable processors with a 3.2 GHz all-core turbo: 16 and 12 cores without Hyper-Threading.
• Memory: 128 GB.
• Disk: “IMPORTANT 7TB, NVMe SSD, 40k IOPS, 500 MB/S throughput, read latency <1ms.”
• Network: 512 Mbps or more.

The client logs mgasps, million gas per second, on each “Imported new chain segment” line; check it while catching up from a snapshot, before you register.

Stake comes on top: at least 2,000 BNB of self-delegation. A daily election picks the top 45 validators by stake, 21 “Cabinets” and 24 “Candidates”, and each epoch 21 of them produce blocks. Missing more than 50 blocks in 24 hours forfeits rewards; more than 150 costs 10 BNB and two days in jail; the same keys signing on two machines at once is a double sign, slashed 200 BNB with 30 days in jail.

So the backup node BNB Chain recommends takes over through miner.stop() on one machine and miner.start() on the other, never as a second live signer; budget for two servers. A validator can expose its IP or hide behind sentry nodes, as the Enhanced Validator Network (EVN) guide describes. That guide names no region but quotes AWS-measured latencies of about 100 ms from Asia-Pacific to Europe, 80 ms from Asia-Pacific to the US and 35 ms from the US to Europe, against a 450 ms block interval.

Ports and bandwidth

BNB Chain’s firewall section gives 30303 for Geth’s TCP and UDP ports and keeps JSON-RPC private, “because from there you can do admin operations”. The config.toml shipped with v1.7.8, however, sets ListenAddr = ":30311", the port in the EVN and Reth-BSC peer lists; open whichever your configuration uses. Reth-BSC’s snapshot example binds RPC to 0.0.0.0, so firewall it.

No page estimates monthly traffic; the shipped configuration allows 200 peers (MaxPeers = 200). On an unmetered 10 Gbps port, neither snapshot downloads nor peer traffic show up on the bill.

Which PowerDedi server for a BSC node

Every configuration below has its own 10 Gbps unmetered port and month-to-month billing. You choose the disk layout when you order or reinstall: two-drive servers default to RAID 1 and also offer RAID 0 or No RAID; the four-drive EPYC 9555P and 9965 default to RAID 10 and also offer RAID 5 or RAID 0, as our software RAID guide explains.

The trade-offs, stated plainly:

• RAID 0 is a bet on snapshots. Striping doubles a two-drive server’s capacity, but a failed drive means a reinstall and a restore: hours for a pruned node, most of a day for full history at 1 Gbps. A mirror rides through a drive failure; for a validator, the backup node is the real redundancy.
• Full history is outgrowing two drives. At 7.4 TB compressed and 260 to 350 GB more each month, it leaves no room on two 3.84 TB drives, even striped. On the EPYC 9555P, RAID 5 leaves about 4 TB above the compressed size, a year or so at that pace; RAID 0 gives 15.36 TB, unprotected.
• Restoring onto 3.84 TB is tight. On the 9950X3D mirrored, or the 9950X striped, BNB Chain’s twice-the-snapshot rule for the 1,899 GB pruned archive takes almost the whole volume; stream the download or use 48Club’s smaller snapshot. The EPYC 4585PX ($179/mo) has the 9950X’s drives with ECC memory.
• Archive alternatives. The EPYC 9555P in RAID 0 also gives 15.36 TB, for less, without redundancy and with little headroom. Our storage servers do not fit: their capacity is on hard drives, and BNB Chain asks for SSD or NVMe throughout.
• When PowerDedi is not the right fit. Below about 33 requests per second, and without eth_getLogs, BNB Chain’s public endpoints may be enough (see below).

Locations: the 9950X in Amsterdam, Frankfurt, London, New York, Miami, Los Angeles, Singapore and Tokyo; the 9950X3D in Amsterdam, Frankfurt, New York and Los Angeles; the 9555P in Amsterdam, Frankfurt, New York and Tokyo; the 9965 in Amsterdam, Frankfurt and New York. Put an RPC node near your application; for a validator, BNB Chain gives no regional guidance, so measure latency to peers once synced.

How to run a BSC full node: setup outline

These steps follow BNB Chain’s full node guide and snapshot README, with one change: pin the release. The guide fetches GitHub’s “latest” release, which in October 2026 was v1.8.0-alpha, a preview “not intended for production”; the newest stable one was v1.7.8, of August 11, 2026.

# 1. Pinned binary and mainnet config (config.toml, genesis.json)
wget https://github.com/bnb-chain/bsc/releases/download/v1.7.8/geth_linux
mv geth_linux geth
chmod -v u+x geth
wget https://github.com/bnb-chain/bsc/releases/download/v1.7.8/mainnet.zip
unzip mainnet.zip

# 2. Download, verify and extract the pruned snapshot into the datadir
wget https://raw.githubusercontent.com/bnb-chain/bsc-snapshots/main/dist/fetch-snapshot.sh
bash fetch-snapshot.sh -d -e -c -p --auto-delete -D /data/snapshot -E /data/bsc mainnet-geth-pbss-20261009

# 3. Start with recent history only (docs: --cache of about a third of RAM)
./geth --config ./mainnet/config.toml --datadir /data/bsc --cache 20000 --rpc.allow-unprotected-txs --syncmode=full --tries-verify-mode=local --history.transactions=600000 --history.blocks=600000 --history.logs=600000

# 4. Follow the import speed (mgasps)
tail -f /data/bsc/bsc.log | grep "Imported new chain segment"

Stop the node with kill -HUP, as the docs do, not kill -9, which forces a replay of recent blocks. Run it as a systemd service and open only SSH and the P2P port. A validator adds --mine --vote and consensus and BLS vote keys created with geth account new and geth bls account new.

Common questions

Do I need my own node to use BNB Smart Chain? Not for occasional use. BNB Chain’s public mainnet endpoints allow 10,000 requests per five minutes, about 33 a second, with eth_getLogs disabled. Indexers, exchanges and trading systems that read event logs or need more throughput run their own node or pay an RPC provider.

Can I run it on a VPS or a cloud instance? The README mentions a “VPS”, and the validator page names AWS instances with local NVMe. Network block storage is the weak point: both lagging Reth-BSC nodes above ran on virtual or cloud disks.

Is running a validator “mining”? No. The --mine flag produces blocks under Proof of Staked Authority. Running nodes and validators is allowed on PowerDedi; crypto mining is not.

For other EVM chains, see our Ethereum node hardware guide. Current stock is on the blockchain node hosting page, payable in BTC, ETH, XMR, USDT on TRON or SOL.

Sources

• BNB Smart Chain (BSC) Node Configuration: Best Practices — BNB Chain Documentation (updated July 18, 2024)
• Run BSC Validator — BNB Chain Documentation (updated February 6, 2026)
• Full Node, Fast Node on BNB Smart Chain and Node Maintenance — BNB Chain Documentation (updated February 6, 2026)
• How to Run an Archive Node on BNB Smart Chain — BNB Chain Documentation (updated January 23, 2025)
• BSC Validator Overview (updated July 17, 2025) and EVN Best Practice — BNB Chain Documentation
• JSON-RPC-Endpoint — BNB Chain Documentation (updated August 19, 2026)
• bnb-chain/bsc README and releases, including v1.5.10, v1.5.18 and v1.6.4, and the mainnet config.toml of v1.7.8 — BNB Chain on GitHub
• About BSC Snapshots (October 9, 2026 snapshot and past file lists) and FAQs — bnb-chain/bsc-snapshots on GitHub
• bsc-snapshots — 48Club on GitHub (block 127,680,000, October 15, 2026)
• Reth @ BSC, its releases and issues #500, #517 and #544 — bnb-chain/reth-bsc on GitHub (September and October 2026)
• BSC-Erigon Client: End of Life Notice — node-real/bsc-erigon on GitHub (archived April 23, 2026)
• Amazon EC2 I7i instances — Amazon Web Services (covers I7i and I7ie)