Teranode Releases v0.16.0 and Opens v0.16.1 Beta With Stronger Access Controls

Network Infrastructure Watch / Network & Protocol

In Brief

Teranode published v0.16.0 as a regular release on October 5, followed by v0.16.1-beta-1 as a new pre-release.

The regular release promotes the code previously distributed as v0.16.0-beta-15. The next beta introduces mandatory authentication for the Blockchain service, additional protection for remote storage writes, and changes to block-assembly processing.

These are separate release milestones: the new authentication requirements belong to v0.16.1-beta-1.

News Report

The 0.16 Series Reaches a Regular Release

GitHub now marks v0.16.0 as Teranode’s latest regular release. Its source commit is identical to v0.16.0-beta-15, the September 30 build covered by BSV TIMES on October 1.

The comparison between those tags contains no additional commits. The extensive v0.16.0 changelog consolidates the series’ development since v0.15.9, including earlier work on validation, recovery, synchronization and seeding.

For operators moving from v0.15.x, the release notes describe an upgrade that retains existing data. Services restart using the new image and resume from their persisted blockchain height and operating state.

Mandatory Authentication in the Next Beta

The subsequent v0.16.1-beta-1 release changes how Teranode’s Blockchain service handles access from other software components.

Under pull request #1755, the service refuses to start without a valid shared API key. Calls to its blockchain and peer-registry interfaces require authentication, with the basic HealthGRPC health check remaining accessible without credentials.

The requirement covers reads and subscriptions as well as operations that change state. Services and command-line clients must present the matching key, allowing credential problems to surface as explicit configuration errors.

The release guidance recommends a randomly generated secret of at least 32 characters, supplied through an environment variable or secret store. The implementation rejects missing, placeholder and weak keys.

This is an access-control change. API-key authentication does not itself encrypt the connection.

Remote Storage Writes Gain a Separate Protection

Pull request #1800 adds authentication to requests that create, modify or delete data through Teranode’s HTTP blob-storage interface.

Deployments using that interface between nodes must configure a matching shared token on the serving node and its writing clients. Requests without valid authorization are rejected, while the storage listener defaults to the local machine’s loopback interface.

The change also blocks redirected peer POST requests from replaying their contents to another destination and checks that persisted UTXO changes match the block under which they are read.

The scope is specific. Quickstart and the shipped configurations use file-based storage and do not require this remote-storage token. HTTP reads remain unauthenticated, and the change does not add TLS encryption to the blob interface.

Block Assembly Changes Continue

The beta also includes work on the delay between applying a block and making subsequent mining candidates available.

Pull request #1881 allows a completed block transition to be reported before queued-transaction cleanup finishes and processes eligible cleanup work in parallel. The intended benefit is to reduce the time block assembly spends withholding usable mining candidates.

The developer notes that part of the reduction in the associated timing metric comes from moving cleanup outside the measured interval. That distinction matters when interpreting performance dashboards.

BSV TIMES Read

The release pair shows two parts of infrastructure development progressing together: establishing a regular release and tightening the operational requirements of the next version.

For BSV Blockchain, reliable node operation depends on the boundaries between services as well as transaction validation. Credentials, storage permissions and predictable upgrade behavior affect whether a deployment can keep operating correctly.

The immediate distinction for readers and operators is the release channel: v0.16.0 promotes the previously published beta build, while the additional access controls enter through a beta that remains under evaluation.

Developer Context

The highlighted changes come from several Teranode contributors:

Siggi (icellan) authored the Blockchain service authentication change and the block-assembly queue-processing work.
NGUYEN Chi Thanh (ctnguyen) authored the combined redirect, HTTP storage and persisted-UTXO validation correction.
oskarszoon published both releases and contributed logging and automated review updates included in the beta.

Source Links

Posted on October 6, 2026