Skip to content

Releases: silvra-net/helix

v0.8.5

Choose a tag to compare

@github-actions github-actions released this 22 Jul 13:26

Which download do I need?

Two of them, and you only ever need one.

I want to… Download
Run a node or validator (server, headless, no desktop) helix-cli-… for your platform — unpack it and run helix start. No installer, no dependencies.
Use the wallet on my desktop (send, stake, explorer, run a node from the UI) helix-gui-… for your platform. The wallet already contains the node — you do not need the CLI as well.

Which wallet installer?

  • Linux.AppImage runs anywhere without installing (make it executable and start it) · .deb for Debian/Ubuntu · .rpm for Fedora/RHEL
  • macOS.dmg (Apple Silicon)
  • Windows.exe is the normal installer · .msi is for managed/automated rollout

Running a validator?

Start the node first, confirm peer_count is above zero, and only then send the stake
transaction — see the founding-validator checklist in the
README. The wait itself is safe (a validator
serving its one-epoch activation delay is no longer charged with missed blocks), but a node
that isn't connected can't vote once it is activated.

Your node was being killed for running out of memory?

That was us, not your machine. The embedded database applied its library's default page cache
of 1 GiB, which we never overrode, so a node holding the chain settled at over 1.5 GB
resident — and a full sync on a small server ran out of room and aborted. This release caps it:
a complete sync of the live chain now peaks around 280 MB and stays there, with no loss of
sync speed. HELIX_DB_CACHE_MB raises it again on machines with memory to spare.

Your node cannot catch up, or reports "does not chain from the previous block"?

Its stored chain has diverged from the network's and cannot be repaired in place — it has to
re-sync from scratch. In the wallet: Node → Reset chain data (it renames the old data, it
does not delete it). Headless: stop the node and rename helix-data.redb aside. Your keys and
your stake are untouched by this; only the block history is re-fetched.

Validator operators: this release changes consensus

All operators must update together. A node no longer counts a silent validator out of its
own quorum — that was a local decision each node made for itself, so two nodes could disagree
about it, each finalize a different block at the same height, and split the chain. They did.

The consequence is deliberate and worth stating plainly: a validator set that has lost more
than a third of its voting power now halts until the missing validators return, instead of
producing blocks without them. That is what BFT means, and tolerating one absence takes four
validators, not two. A halt is visible and heals by itself; a fork silently duplicates the
history and every balance in it.

A stalled node now also names the validator it is waiting for, once per round, in its log.


What's in v0.8.5

the chain can no longer fork itself, and the node fits in memory

Update together with the other operators. This changes consensus.

A validator that had been silent for twenty rounds had its voting power zeroed
— in each node's private copy of the validator set. That lowered that node's
quorum threshold until it could finalize alone, which kept blocks flowing
through an outage. It also meant two nodes could each decide the other was
gone, each finalize a different block at the same height, and split the chain.
On 2026-07-22 they did, at height 66918.

The mechanism was unsound however it was tuned, not merely mistuned: if the
available voting power already meets the real quorum, excluding anyone changes
nothing, so the exclusion is only ever load-bearing when the node is about to
commit a block that less than two thirds of the staked power stands behind.

It is gone. A set that has lost more than a third of its power now halts until
the missing validators return — that is what BFT means, and tolerating one
absence takes four validators, not two. A halt is visible and recoverable; a
fork silently duplicates the history and every balance in it.

A stalled node now names the validator it is waiting for, once per round. It
used to log nothing at all while stalled.

The embedded database applied its library's default page cache of 1 GiB, which
we never overrode. A node holding the chain settled above 1.5 GB resident, and
a full sync on a small server ran out of memory and aborted — one operator's
node died with a failed 16 kB allocation.

Measured against the live chain, same binary, only the cache size differing: a
complete 71,000-block sync now peaks at 280 MB and stays there, against 469 MB
mid-sync and 1.53 GB at rest. Sync speed did not regress. HELIX_DB_CACHE_MB
raises it again where the memory is available.

  • A node that lost its last peer never dialed the seeds again, so a single
    dropped connection was permanent until someone restarted it by hand. The
    peer-exchange tick now redials while nothing is connected.
  • A validator excluded for silence could never be let back in, because zeroing
    its power ended the very round timeouts that would have cleared the strike.
  • Precommits already collected for a block now survive that block arriving
    already finalized, instead of being discarded with the round.
  • /blocks/height/:n now carries last_commit, the block's finality proof. A
    light client could not verify anything without it.
  • The explorer footer links the project's Chainquiry listing. The logo is
    served by the node itself, like everything else on that page.

Full Changelog: v0.8.4...v0.8.5

v0.8.4

Choose a tag to compare

@github-actions github-actions released this 22 Jul 07:45

Which download do I need?

Two of them, and you only ever need one.

I want to… Download
Run a node or validator (server, headless, no desktop) helix-cli-… for your platform — unpack it and run helix start. No installer, no dependencies.
Use the wallet on my desktop (send, stake, explorer, run a node from the UI) helix-gui-… for your platform. The wallet already contains the node — you do not need the CLI as well.

Which wallet installer?

  • Linux.AppImage runs anywhere without installing (make it executable and start it) · .deb for Debian/Ubuntu · .rpm for Fedora/RHEL
  • macOS.dmg (Apple Silicon)
  • Windows.exe is the normal installer · .msi is for managed/automated rollout

Running a validator?

Start the node first, confirm peer_count is above zero, and only then send the stake
transaction — see the founding-validator checklist in the
README. The wait itself is safe (a validator
serving its one-epoch activation delay is no longer charged with missed blocks), but a node
that isn't connected can't vote once it is activated.

Already jailed? Take this release before sending helix tx unjail — see below.

Validator operators: this release changes consensus

Downtime-jailing and the catch-up loop both changed. Nodes running different versions can
disagree about who is jailed, so all operators should update together. If you are currently
jailed, install this version first and unjail afterwards.


What's in v0.8.4

a validator can finally stay in the set

Fixes the reason the network never had a working second validator: the periodic
RPC catch-up tore down the validator's own consensus round every few seconds, so
it never precommitted, never appeared in a commit certificate, and was jailed for
absence it was not responsible for.

Also closes the door underneath it — a proposer could jail any rival by leaving
its precommit out of the certificate. Convictions now require the certificate to
carry 2/3+1 of the voting power.

Consensus changed: all operators should update together, and anyone currently
jailed should install this before unjailing.

Full Changelog: v0.8.3...v0.8.4

v0.8.3

Choose a tag to compare

@github-actions github-actions released this 21 Jul 21:32

Which download do I need?

Two of them, and you only ever need one.

I want to… Download
Run a node or validator (server, headless, no desktop) helix-cli-… for your platform — unpack it and run helix start. No installer, no dependencies.
Use the wallet on my desktop (send, stake, explorer, run a node from the UI) helix-gui-… for your platform. The wallet already contains the node — you do not need the CLI as well.

Which wallet installer?

  • Linux.AppImage runs anywhere without installing (make it executable and start it) · .deb for Debian/Ubuntu · .rpm for Fedora/RHEL
  • macOS.dmg (Apple Silicon)
  • Windows.exe is the normal installer · .msi is for managed/automated rollout

Running a validator?

Start the node first, confirm peer_count is above zero, and only then send the stake
transaction — see the founding-validator checklist in the
README. Staking before your node is connected
gets it jailed for downtime.


What's in v0.8.3

validating from a passphrase-protected wallet

0.8.2 made the wallet run the bundled node under the wallet's own key, but an
encrypted wallet cannot be read without its passphrase and there was no way to
supply one — the node refused to start. It is now asked for, only when needed,
and passed to the node process without being stored.

Also: the wallet reads from your own node while it runs instead of a public
one, shows which node is answering, gains a reset button for a local chain
that can no longer follow the network, and puts Send/Receive in the sidebar.

Full Changelog: v0.8.2...v0.8.3

v0.8.2

Choose a tag to compare

@github-actions github-actions released this 21 Jul 20:58

Which download do I need?

Two of them, and you only ever need one.

I want to… Download
Run a node or validator (server, headless, no desktop) helix-cli-… for your platform — unpack it and run helix start. No installer, no dependencies.
Use the wallet on my desktop (send, stake, explorer, run a node from the UI) helix-gui-… for your platform. The wallet already contains the node — you do not need the CLI as well.

Which wallet installer?

  • Linux.AppImage runs anywhere without installing (make it executable and start it) · .deb for Debian/Ubuntu · .rpm for Fedora/RHEL
  • macOS.dmg (Apple Silicon)
  • Windows.exe is the normal installer · .msi is for managed/automated rollout

Running a validator?

Start the node first, confirm peer_count is above zero, and only then send the stake
transaction — see the founding-validator checklist in the
README. Staking before your node is connected
gets it jailed for downtime.


What's in v0.8.2

a wallet user can actually become a validator

0.8.1's wallet started the bundled node without a validator key, so the node
generated its own and validated as an address nobody had staked. The node ran,
connected and followed the chain while the staked address never signed a block.
Anyone setting up a validator should skip 0.8.1.

Also: the node serves RPC during the initial sync instead of answering nothing
for 36 minutes and now reports real progress; sync responses are gzipped (4.1x
less traffic, and for every node rather than only those behind a CDN); a failed
chain write exits instead of leaving the node quietly producing nothing; and the
epoch-rotation log no longer claims nobody meets the stake minimum when
candidates are simply serving their activation epoch.

Upgrading from 0.8.1 is a restart, not a reset — genesis reconstruction is
unchanged and the two interoperate.

Full Changelog: v0.8.1...v0.8.2

v0.8.1

Choose a tag to compare

@github-actions github-actions released this 21 Jul 16:51

Which download do I need?

Two of them, and you only ever need one.

I want to… Download
Run a node or validator (server, headless, no desktop) helix-cli-… for your platform — unpack it and run helix start. No installer, no dependencies.
Use the wallet on my desktop (send, stake, explorer, run a node from the UI) helix-gui-… for your platform. The wallet already contains the node — you do not need the CLI as well.

Which wallet installer?

  • Linux.AppImage runs anywhere without installing (make it executable and start it) · .deb for Debian/Ubuntu · .rpm for Fedora/RHEL
  • macOS.dmg (Apple Silicon)
  • Windows.exe is the normal installer · .msi is for managed/automated rollout

Running a validator?

Start the node first, confirm peer_count is above zero, and only then send the stake
transaction — see the founding-validator checklist in the
README. Staking before your node is connected
gets it jailed for downtime.


What's in v0.8.1

validators are no longer jailed for the wait the protocol imposes

A validator serving the one-epoch activation delay was scored for downtime
and jailed after 150 blocks, before the rotation that would have activated
it ever arrived. Since jailing also cost it its accrued wait, whether a new
validator could join at all came down to where in the 100-block epoch it
happened to stake. Found live, three identical cycles, never once active.

Also: the epoch rotation moved into block execution, so a node catching up
over RPC no longer computes different state from the same blocks; a slashed
double-signer leaves the scored set at once instead of collecting a downtime
jail on top of its slash; and a node now warns when its sync peer runs a
different version.

Upgrading from 0.8.0 is a restart, not a reset — genesis reconstruction is
unchanged. But it is not mix-and-match: a node left on 0.8.0 jails a waiting
validator that 0.8.1 considers fine and stalls block production. Move every
node on a shared chain together.

Full Changelog: v0.8.0...v0.8.1