English
Node Operators
Running your own DotOne node, whether it's a full node, an archive node, or the base for a validator, means you're not stuck sharing public RPC endpoints with everyone else. Here's what you need for hardware, configuration, and day-to-day operation.
Node Types
| Type | Purpose | Typical Use |
|---|---|---|
| Full | Keeps recent state and full block history | RPC serving, indexing, general integration |
| Archive | Keeps full historical state at every block | Explorers, analytics, historical queries |
| Fast | Prunes older state aggressively for lower disk usage | Lightweight RPC serving, testing |
Minimum Hardware
| Node Type | CPU | RAM | Storage | Network |
|---|---|---|---|---|
| Fast | 16 cores | 32 GB | 2 TB SSD | Stable 5 MBps+ |
| Full | 16 cores | 64 GB | 3 TB SSD | Stable 5 MBps+ |
| Archive | 16 cores | 128 GB | 10 TB SSD (NVMe preferred) | Stable 5 MBps+ |
These specs are based on BSC's own operational recommendations and are minimums for keeping up with mainnet block production — validator nodes should provision above these baselines, since missed blocks due to resource exhaustion can trigger slashing. For Full and Archive nodes, use NVMe storage with solid throughput and IOPS, not a generic SATA SSD. Expect storage needs to keep growing over time too, as chain history, transaction volume, and smart contract state all accumulate.
Peer Configuration
- Mainnet nodes discover peers automatically through built-in bootnodes — no manual peer configuration is required for normal operation.
- Testnet — coming soon. Testnet is currently in development; peer configuration guidance will be published here once it's available.
Syncing
Don't sync from genesis if you can avoid it — grabbing a recent chaindata snapshot instead will save you a lot of waiting. Once you're running, keep an eye on your client's sync-speed metric (blocks or gas processed per second); if it stalls or drops off a cliff, that's usually disk I/O or a peer problem, not CPU. Also make sure the client actually has enough memory for its internal cache — starve it and block processing turns into a disk-bound bottleneck fast.
Monitoring
Three things are worth alerting on from day one. A mempool that's growing fast can mean your node is stuck, or it can mean the whole network is congested — either way you want to know. Block import time creeping toward (or past) the block interval means you're falling behind. And rising RPC latency on your own endpoints will quietly break every service downstream of it, so it's worth catching early.
Troubleshooting: No Peers
Testnet-specific guidance coming soon, once Testnet is available.
If a Mainnet node can't find peers:
- Re-check
config.tomlagainst the latest client release. - If peers still don't connect, remove the local chaindata/keystore directories for a clean re-sync rather than debugging a possibly-corrupted database.
- Re-download a fresh chaindata snapshot if the resync is taking too long from genesis.
Security
Keep validator and operator private keys in a hardware wallet or HSM if you can — plaintext on a node's filesystem is asking for trouble. If your RPC port doesn't need to be public, don't expose it; if it does, put it behind a reverse proxy with rate limiting. Patch your node software regularly, since most chain client vulnerabilities get disclosed and fixed upstream well before anyone exploits them in the wild.
It's also worth backing up your validator configuration and keys on a schedule, encrypted and stored off-node, so a hardware failure doesn't turn into a lost-key event on top of everything else. And if you're running a validator specifically, Secure Validator covers sentry-node architecture and DDoS mitigation in more depth.