Bee Version 2.8.1 Release Announcement

Bee v2.8.1 Released

Bee v2.8.1 is a non-disruptive release focused on performance, data durability, and developer experience, with some operational cleanup. It is scheduled for release on July 1st, 2026.

What Is Changing

This release brings faster chunk hashing, stronger crash safety for local storage, reduced blockchain RPC traffic, and a step toward browser-based uploads, alongside some operational cleanup.

Faster Chunk Hashing with SIMD

Bee v2.8.1 adds an optional, hardware-accelerated (SIMD) path for chunk hashing, a frequent and CPU-intensive operation. On supported hardware it noticeably lowers the CPU cost of hashing, which speeds up uploads and other hashing-heavy work. The SIMD acceleration relies on specialized x86-64 CPU instructions that are currently built for Linux amd64.

Crash-Safe Local Storage

This release fixes a data-integrity issue that could affect a node interrupted mid-write (for example, by a crash or power loss while actively uploading). Under those conditions, a node could end up with corrupted local storage and, in some cases, serve invalid chunk data. Idle nodes were not affected.

Bee v2.8.1 closes the window that caused this and adds an automatic integrity check: after an unclean shutdown, the node now validates chunks against their content hashes during recovery and removes any that are corrupted, so it starts clean and avoids serving corrupted data. This recovery is automatic. No manual action or repair command is required. The change improves the real-world durability and reliability of data stored across the network.

Reduced Blockchain RPC Traffic

Bee nodes query their blockchain RPC endpoint constantly, which adds cost and rate-limit pressure for operators on paid or self-hosted RPC providers. Bee v2.8.1 substantially reduces how often a node makes those calls (in part by relying on the chain’s average block time to estimate values locally between syncs), lowering RPC cost and load.

block-sync-interval: 10

Client-Side Stamping for Browser Uploads

Bee v2.8.1 lets a client sign its own postage stamps and upload already-stamped chunks, rather than handing raw data to a node to stamp. This opens up new possibilities for applications built on Swarm:

• Browser-based uploads with the key in the browser. The signing key can stay client-side, so an app can upload to Swarm directly from the browser without entrusting its key to a node.
• Faster uploads through parallel stamping. Stamp signing can be spread across Web Workers, parallelizing the work to improve upload performance.
• Per-chunk batch selection. Different chunks can be stamped with different postage batches within the same upload.

Together with the AutoTLS and secure WebSocket (WSS) support from v2.7.0, this is another step toward running Bee directly in the browser.

Dev Mode Has Been Removed

The bee dev command (and its devnode / start-dev internals) has been removed. Bee now supports only its three production runtime modes: light, full, and ultra-light. This completes the deprecation first announced with Bee v2.7.0.

Node operators are unaffected, as production nodes never ran in dev mode.

More Efficient Peer Handshakes

Previously, a Bee node re-signed a new address record on every handshake, each carrying a fresh timestamp, so even when nothing had changed, the record looked new to its peers. Receiving nodes treated each one as an update, wrote it to their address book, and re-gossiped it, producing needless disk writes, signing work, and gossip traffic across the whole network.

Bee v2.8.1 fixes this: the node now signs its address record once and reuses the identical record, re-signing only when its advertised addresses or chequebook actually change. A reconnecting peer now costs a cached read and no disk write, reducing disk I/O, CPU, and gossip traffic across the network.

Bee v2.6.0 Support Removed

The network’s minimum supported version has been v2.8.0 since the v2.8.0 release, which introduced breaking p2p protocol changes. Bee v2.8.1 now removes the remaining v2.6.0 backward-compatibility code, so nodes still on v2.6.0 or earlier also lose the ability to upgrade directly to v2.8.1.

API & Developer Changes

This release includes several additive, backward-compatible API changes:

• The /soc endpoint now honors the Swarm-Tag, Swarm-Pin, and Swarm-Deferred-Upload headers, bringing single-owner-chunk uploads in line with other upload endpoints.
• A new GET /batches/{batch_id} endpoint fetches a single global postage batch directly by ID.
• A new PATCH /stamps/{batch_id} endpoint updates the label of an existing postage batch; the label is local metadata only, has no on-chain effect, and persists across restarts.
• GET /chainstate now returns minimumValidityBlocks, so applications can compute postage-batch validity and cost without querying the chain directly.
• Postage stamp responses (GET /stamps, GET /stamps/{batch_id}) now include utilizationRatio, a value between 0 and 1 giving true fractional batch usage.
• For single-file POST /bzz, Content-Type is optional: if the client sends it, it is preserved exactly. If not, the content type is automatically detected.
• GET /wallet now returns balances even when swap or chequebook is disabled, so light and chequebook-disabled nodes can read their balances.
• The ACT and grantee endpoints now honor a caller-specified default redundancy level.

Bug Fixes & Maintenance

A few reliability fixes worth highlighting:

• A node that lacks sufficient stake for reserve-capacity doubling no longer fails at startup; it now starts normally (without redistribution participation) and updates its on-chain status automatically once enough stake is added.
• The redundancy retrieval path now reads exactly the values it expects and fails cleanly instead of returning an incomplete result, improving erasure-coding correctness.
• The hive (peer discovery) and pullsync (chunk sync) protocols are hardened against malformed peer messages to prevent rare panics.
• The OpenAPI specification has been aligned with the actual API behavior, so generated clients match runtime behavior.

This release also includes a set of smaller fixes: clearer fail-fast behavior when a node’s stored block is ahead of its RPC’s chain tip, more reliable stamp-expiry handling, reconciled peer counts in the status endpoints, the ability to set the blockchain RPC endpoint via environment variable, and a fix that prevents --resync from wiping the postage snapshot.

On the maintenance side: the Docker Compose environment variables were updated to match the current configuration; a postage-snapshot optimization from v2.7.1 was reverted and re-applied without the component that caused issues (keeping the faster snapshot sync); and go-ethereum was updated, pulling in upstream security and vulnerability fixes.

Full Changelog

For the complete list of changes, see the Bee v2.8.1 release changelog on GitHub (live on release day).

Need Help?

If you’re a node operator or developer with questions about upgrading or the new features, join the #node-operators channel on the Swarm Discord.

Bee v2.8.1 is scheduled for release on July 1st, 2026. This post will be updated when it goes live. Start planning your upgrade now, especially if you use dev mode for local development or still run a Bee v2.6.0 node.