Contribute storage. Keep the web free.

Your node must first fully sync with the network — watch for pullsyncRate dropping to zero, which typically takes a few hours. Then you need to stake a minimum of 10 xBZZ to participate in the redistribution game. The stake is non-refundable — it's locked collateral, not spent.

Before staking, it's worth checking if your hardware is fast enough by calling the /rchash endpoint. This benchmarks how long your node takes to generate a reserve commitment hash. If durationSeconds exceeds ~360 seconds (6 minutes), your node will likely fail to submit proofs in time, resulting in missed rounds or freezing. If too slow: prioritize faster SSD first, then more RAM, then faster CPU.

From there, earnings are probabilistic — the network runs ~113 rounds/day, each selecting one neighborhood at random. Your first win could come within days or take a few weeks. It's a lottery, not a queue.

Key risk: if your node submits an incorrect reserve commitment — for example because it wasn't fully synced — it gets frozen for up to ~9 days at current storage radius. Make sure sync is complete before you stake.

Several, and they tend to compound:

• Not checking if your hardware is fast enough. Once your node is fully synced, use the /rchash endpoint to benchmark how long the sampler takes. If it exceeds ~360 seconds, your node will fail to submit proofs in time — leading to missed rounds or freezing. Fix: upgrade to SSD (ideally NVMe), add RAM, or get a faster CPU.

• Using a public/free RPC endpoint. Rate limiting or missing historical data causes the node to fall out of sync with on-chain state, leading to incorrect reserve commitments and freezing. Run your own Gnosis node or use a reliable paid provider.

• Skipping port forwarding. Port 1634 (TCP+UDP) must be reachable from the internet. If isReachable shows false in the /status endpoint, your node can't fully participate. Watch out for Carrier-Grade NAT — you may need to contact your ISP.

• Using the same Gnosis Chain address for multiple nodes. Each node needs its own address, chequebook, and ports. Sharing an address between nodes violates the protocol and breaks staking.

• Restarting during an active redistribution round. Check /redistributionstate before updating or restarting — if lastPlayedRound == round, wait for the round to complete or you risk losing winnings or getting frozen.

No disaster — but you miss earnings and need to be careful about how you go offline. Every round your node is offline, it simply doesn't participate. Rounds happen every ~12.7 minutes, so a few days means hundreds of missed chances. There's no retroactive claim.

What you don't lose: your stake stays intact (it's locked regardless), and your chunks are safe. Other nodes in your neighborhood hold copies of the same data, and pull-sync will restore your chunk inventory when you come back online.

The one danger: going offline mid-round. If your node has already submitted a commit transaction but goes down before the reveal phase, it can get frozen for up to ~9 days at current storage radius. Always check /redistributionstate before shutting down — if lastPlayedRound == round, wait for the round to complete.

Coming back online: the node will re-sync automatically via pull-sync. Once pullsyncRate drops back to zero and isFullySynced shows true, you're back in the game.

Once set up properly, very little — but the initial investment in automation makes the difference.

Daily (automatable to near-zero): Check node health — isFullySynced, hasSufficientFunds, isFrozen, and that lastPlayedRound matches the current round via the /redistributionstate endpoint. Monitor xDAI balance. Bee exposes Prometheus metrics at /metrics, so all of this can run unattended with alerts via Prometheus + Grafana.

Weekly (~5–10 minutes): Cash out cheques — not automatic, requires API calls or a script. Once a week is more than sufficient; doing it too frequently is unnecessary.

Every 1–3 months (~10–30 minutes): Software upgrades. Bee stable releases come roughly every 1–5 months. The upgrade itself is straightforward (stop, upgrade, start) — always check /redistributionstate first to avoid restarting mid-round.

Bottom line: invest a couple of hours upfront setting up monitoring and a cheque cashout script, and ongoing maintenance is roughly 10–15 minutes per week for a single node. Without automation, expect more like 30 minutes of manual checking.

Both work, but the economics differ. Hetzner is the most commonly cited value/performance option among serious operators — particularly their dedicated servers with unmetered bandwidth. A few caveats worth knowing: not all machines with identical listed specs perform equally; older hardware that's been running for years can behave noticeably differently from a freshly provisioned server.

Bandwidth is the critical constraint. Swarm nodes are bandwidth-hungry, and capped plans can become a serious cost at scale. Prioritize providers offering unlimited or unmetered traffic over raw compute spec when comparing options.

Bare metal is worth considering once you're running enough nodes to justify it — lower per-node cost at scale, and no shared CPU contention affecting proof performance.

Significantly, and non-linearly. Storage depth determines how large a reserve of chunks each node is responsible for. When storage depth is higher, each node's reserve is smaller — lower disk and CPU requirements. When storage depth drops, nodes take on a larger reserve, which increases storage needs and makes the redistribution game's sampler process significantly more CPU-intensive. The sampler has to compute a reserve commitment hash over a larger dataset, and CPU usage can spike dramatically at lower storage depths.

The scaling is non-linear — you can't extrapolate from disk usage to CPU needs. Memory has generally not been a bottleneck; you'll hit disk or CPU limits well before running out of RAM. The real balancing act is finding the right ratio between node count per machine and available CPU and storage headroom — and that ratio shifts as network conditions change.

Quite volatile — several moving parts compound. On the network side: storage demand drives rewards (more postage stamps purchased = larger pool), and node count changes affect per-node share. The State of the Network reports track this monthly — check the current reports rather than relying on any specific figures here, as the range shifts as the network grows or shrinks.

On the individual node level: wins are probabilistic. The redistribution game selects one neighborhood per round — if yours is selected, one node in it wins, weighted by stake density. You might win twice one month and not at all the next.

On top of that: all earnings are in xBZZ. If you measure costs in fiat (VPS bills, electricity), the xBZZ/fiat exchange rate adds a significant additional layer of volatility on top of the network-side fluctuations.

Multiple nodes across different neighborhoods is generally more effective than a single heavily-staked node — neighborhood coverage matters for reward eligibility. The redistribution game selects one neighborhood per round, then selects a winner from that neighborhood weighted by stake density (stake × 2^storage depth). You want presence across the network, not just depth in one spot.

On stake amount: the minimum is 10 xBZZ, but experienced operators run higher individual stakes. Nodes using reserve doubling — participating in two neighborhoods simultaneously — need 20 xBZZ. The right balance between node count, stake per node, and reserve configuration varies with network conditions; the node operator Discord channel is where current strategy is discussed most openly.

Your node must first fully sync with the network — watch for pullsyncRate dropping to zero, which typically takes a few hours. Then you need to stake a minimum of 10 xBZZ to participate in the redistribution game. The stake is non-refundable — it's locked collateral, not spent.

Before staking, it's worth checking if your hardware is fast enough by calling the /rchash endpoint. This benchmarks how long your node takes to generate a reserve commitment hash. If durationSeconds exceeds ~360 seconds (6 minutes), your node will likely fail to submit proofs in time, resulting in missed rounds or freezing. If too slow: prioritize faster SSD first, then more RAM, then faster CPU.

From there, earnings are probabilistic — the network runs ~113 rounds/day, each selecting one neighborhood at random. Your first win could come within days or take a few weeks. It's a lottery, not a queue.

Key risk: if your node submits an incorrect reserve commitment — for example because it wasn't fully synced — it gets frozen for up to ~9 days at current storage radius. Make sure sync is complete before you stake.

No disaster — but you miss earnings and need to be careful about how you go offline. Every round your node is offline, it simply doesn't participate. Rounds happen every ~12.7 minutes, so a few days means hundreds of missed chances. There's no retroactive claim.

What you don't lose: your stake stays intact (it's locked regardless), and your chunks are safe. Other nodes in your neighborhood hold copies of the same data, and pull-sync will restore your chunk inventory when you come back online.

The one danger: going offline mid-round. If your node has already submitted a commit transaction but goes down before the reveal phase, it can get frozen for up to ~9 days at current storage radius. Always check /redistributionstate before shutting down — if lastPlayedRound == round, wait for the round to complete.

Coming back online: the node will re-sync automatically via pull-sync. Once pullsyncRate drops back to zero and isFullySynced shows true, you're back in the game.