Skip to content

Releases: jetsam-chain/jetsam

v1.2.0 — consensus change at block 8450

Choose a tag to compare

@Jetsam-dev Jetsam-dev released this 11 Sep 14:05

Jetsam v1.2.0 — consensus change at block 8450

This release is mandatory for every node and every miner. The consensus
rules change at block 8450, expected on 2026-09-12 around 17:30–18:15 UTC.
A node still running v1.1.x at that height stops being able to follow the chain.

Upgrade any time before then. Until block 8450 this build behaves exactly like
v1.1.2 — same wire format, same limits, same network identity — so there is no
reason to wait and no benefit to timing it.

What changes at 8450

  • Shared-path proof terminals. The fused HistoryStep terminal carried by
    every block now shares Merkle path segments instead of repeating them.
    A 25-page terminal goes from 971 732 to 874 420 bytes on the wire; a 255-page
    terminal from 1 081 108 to 980 148.
  • The terminal size cap rises from 1 048 576 to 1 200 000 bytes.

Together these make the 255-page proof class publishable for the first time.
Until now every block was limited to 25 user transaction pages, because the
larger class produced a terminal that no node would accept — the defect that
stopped the chain for 6 146 seconds on 2026-09-07.

Nothing else changes. The proof circuits, the state layout, the network profile
and the address format are untouched; this build peers with v1.1.x normally
until the activation height.

If you upgrade late

Your node will fail to sync, with unsupported HistoryStep version 5 in its
log. Nothing is corrupted and nothing needs erasing: install this build and
restart, keeping your data directory as it is. Your node reinstalls from a
snapshot and catches up on its own. Your wallet is untouched.

Verifying what you downloaded

jetsam --version reports 1.2.0. That tells you the application changed; it
does not tell you the activation height compiled into it, so for a consensus
change compare against SHA256SUMS in this release as well.

Assets

File For
jetsam-node-linux-x86_64 the node, Linux x86-64
jetsam-cli-linux-x86_64 the command-line wallet, Linux
jetsam-node-windows-x86_64.exe the node, Windows x64
jetsam-cli-windows-x86_64.exe the command-line wallet, Windows
Jetsam-Desktop-1.2.0-linux-x64.tar.gz the desktop wallet, Linux
Jetsam-Desktop-1.2.0-windows-x64.zip the desktop wallet, Windows
SHA256SUMS checksums for all of the above

The Linux binaries are built against glibc 2.34, so they run on Ubuntu 22.04,
Debian 12, AlmaLinux/Rocky 9 and anything newer.

Desktop wallet users: the application bundles its own node. Updating the
application updates that node — there is no separate step — but an application
left un-updated is a node left behind.

v1.1.2 — storage safety, publishable blocks, and networking under your control

Choose a tag to compare

@Jetsam-dev Jetsam-dev released this 08 Sep 08:39

No consensus rule changes in this release. A v1.1.2 node and a v1.1.1 node
agree on every block and connect to each other; upgrading is safe at any time
and needs no coordination.

Storage safety: a path that could have cost somebody their wallet is gone

No user has been affected, and we know of no case where this happened. It was a
latent path in code inherited from upstream, found while auditing, and removed
before it could find anyone.

A node whose .network-storage-epoch marker was missing or belonged to another
network would delete every file in its data directory — the wallet with it —
and would do so on any invocation, including --export-wallet-secret, the
command someone runs to rescue that wallet. A marker is a dotfile: cp data/*
drops it, backup tools skip it, disk repair loses it. None of that ever meant
the directory belonged to another network.

That code is now gone rather than guarded. Nothing walks the data directory
deleting entries any more. The marker now records and decides nothing, so
losing it is a non-event. The question it was pretending to answer is asked of
the genesis header the database itself holds: on a mismatch the node refuses to
start, names the directory, and says the wallet is still in it. Moving it is
the operator's call.

Two consequences of removing that branch, both wanted: the configuration you
wrote is no longer replaced by defaults on first start, and the default
install's jetsam.toml is no longer rewritten to point at whichever data
directory happened to be starting.

A block that cannot be published is no longer built

Proof classes have a fixed terminal size — 971,732 bytes for the 25-page class,
1,081,108 for the 255-page one — against a consensus cap of 1,048,576. The
larger class has therefore never been publishable, on any height, since genesis.
The page budget was decided on proof time alone, so a node fast enough selected
it, mined a block nobody could accept, and refused its own solution after the
proof of work was spent. The chain stopped for 6,146 seconds at block 3575 on
7 September this way.

The budget now never grants a class whose terminal exceeds the cap, expressed
over the measured sizes rather than a constant, so raising the cap later frees
the larger class on its own. Such a template is refused at construction, not at
solution time: after mining, the transactions are frozen into the hash and no
solution can be rescued.

Networking

--lan-discovery — mDNS peer discovery is now off by default. It broadcast on
every interface and dialled whatever answered, which is zero-config on a LAN you
own and unwanted on a VPS, where the local segment belongs to the provider and
is shared with other tenants.

--no-upnp — port mapping stays on by default, because a node behind a home
router otherwise receives blocks and serves none, and can now be refused.

--p2p-listen repeats, and network.listen accepts a list, so a node can be
reached over IPv4 and IPv6 at once. An address that will not bind is logged with
its reason and no longer kills the node; only having none left does.

Desktop wallet

A Connections panel: turn off UPnP, add peers by hand, and settings that live
beside the wallet so an update keeps them. Anything typed there is validated as
HOST:PORT before it can reach the node's command line.

"Difficulty: 38 leading zeros" is now the network hash rate it implies, next to
the one your machine produces.

Reproducible Windows builds

The published libmdbx 0.6.6 does not compile for x86_64-pc-windows-gnu. Our
two-line fix lived on one machine and was injected at build time, so nobody
outside could rebuild or verify the Windows binaries. It is vendored in
third_party/ with the diff documented; a clone now builds Windows with no
extra flag. Build paths no longer travel inside any binary, Windows included.

Jetsam v1.1.1 — relayed peers stop being closed, and a pool can be built

Choose a tag to compare

@Jetsam-dev Jetsam-dev released this 06 Sep 18:14

No consensus change. No activation height, no coordinated upgrade, no
deadline. A v1.1.0 node stays on this chain indefinitely. Update when it suits
you — or only if you run a pool.


Relayed peers are no longer closed the moment they connect

A node behind NAT reaches most of the network through relays. A relayed address
carries the relay's IP:

/ip4/<relay>/tcp/9700/p2p/<relay-id>/p2p-circuit/p2p/<destination>

The neighbour-diversity guard read the first IP it found — the relay's — and
counted every peer behind one relay into that relay's /16. With a budget of two
peers per prefix, the third circuit was admitted and closed within the same
second
, dropped from the routing table, rediscovered, and dialled again. The
more useful a relay was, the harder we fought it.

Measured on rented machines in five countries, before and after:

Circuits opened Closed by the guard
Before 217 110 (up to 86% on one machine)
After 135 0

Hole punching gets its chance too: DCUtR attempts roughly doubled once circuits
survived long enough to matter.

Circuits are now budgeted by carrier — the axis relayed peers genuinely
share. Losing one relay still drops everyone behind it, so the bound stays; it
is sixteen peers per relay instead of two.

The mining RPC can now carry a pool

Everything a pool needs and had to work around:

The template describes itself. template_seq (same work, same number),
parent_id, miner_address, timestamp, state, ttl_remaining_ms and
difficulty. All optional, so a client written against v1.1.0 keeps working.

ttl_remaining_ms is real. expires_in_seconds is a constant and always
reported the full window, so a pool re-served a 40-second-old template believed
it had two minutes and watched its miners' work die at eighty seconds. The
remaining lifetime is now measured when the response is built.

A valid nonce is no longer thrown away. While the node proves a template it
could not answer a submission, so a genuinely won block was lost and the miner
told to retry blindly. The PoW input is published before proving starts — that
is the whole point of the overlap — so a submission is now judged against it: a
wrong nonce is rejected in microseconds without touching anyone's template, and
a correct one is held until the proof lands.

waitBlockTemplate(miner_address, known_seq, timeout_s). One call that
returns as soon as there is new work. Without it a pool polls once a second or
tails the node's log file.

Stable error codes. Every mining failure used to arrive as -32000 with a
sentence, so a caller had to match on prose to tell "your nonce is wrong" from
"you lost the race" from "fetch a new template":

Code Meaning
-32020 template unknown or purged
-32021 template expired
-32022 already claimed by another submission
-32024 parent is no longer the tip
-32025 digest is not below the target
-32026 nonce could not be decoded
-32027 the node will not hand out work yet

A failed preparation withdraws its preview. It used to stay on offer for its
full window with an id that could never be submitted.

Linux: one binary, from Rocky 9 to Debian 13

Built against GLIBC_2.34, verified starting on Rocky/AlmaLinux 9, Ubuntu
22.04, Debian 12, Ubuntu 24.04 and Debian 13. There is no separate "old distro"
download and there should not be: glibc is only compatible forwards, so the
low-floor binary is the one that runs everywhere.

Downloads

You want File
Desktop app, Windows Jetsam-Desktop-1.1.1-windows-x64.zip
Desktop app, Linux Jetsam-Desktop-1.1.1-linux-x64.tar.gz
Node only, Linux jetsam-node-linux-x86_64
Node only, Windows jetsam-node-windows-x86_64.exe
Command-line wallet jetsam-cli-linux-x86_64 / jetsam-cli-windows-x86_64.exe

The desktop app carries its own node; you do not need the node file as well.

sha256sum -c SHA256SUMS --ignore-missing

Jetsam v1.1.0 — hardfork at height 2000, NAT traversal, desktop app

Choose a tag to compare

@Jetsam-dev Jetsam-dev released this 05 Sep 19:39

⚠️ Consensus change at block 2000 — every node must update

The difficulty polynomial this chain has run since genesis was mis-transcribed
from the BCH reference. Its quadratic term is divided by 65536 once too often
and its cubic term is identically zero, so it sits up to 15.2 % below the
2^x curve it is meant to approximate and steps by 18 % at every halflife
crossing. That is why blocks have been settling near 99 s against a 90 s target.

The corrected polynomial is within 0.012 % of 2^x and continuous. It
activates at height 2000.

Below height 2000 both curves agree byte for byte — proven against real
mainnet headers by production_next_target_replays_mainnet_headers_exactly.
Nothing about your mining changes until block 2000.

From height 2000, a node older than v1.1.0 computes the old target and will
reject blocks that follow the corrected one.
It will keep building a separate
chain with whatever hashrate stays behind it. Updating is not optional.

Expected effect after activation: stationary difficulty about 8–9 % lower,
and block intervals settling on the 90 s target instead of drifting above it.


Also in this release

NAT traversal — nothing to configure. The node now speaks upnp and
autonat. Behind a home router it asks for the P2P port to be mapped, and it
learns whether it is genuinely reachable from outside instead of silently
remaining a leaf that only ever dials out. When no gateway answers, the log
tells you the real port to forward — it reads the port from the running
listener rather than guessing.

Three DNS seeds. mseed1, mseed2 and mseed3 at jetsamchain.com, all
live, all reachable on TCP 9700.

Jetsam Desktop — wallet, node and CPU miner in one window. The node is
embedded and started for you; there is no separate miner to install and no pool
account to create. Receive shows your address as a QR code, Send can read one
from the camera, and the Node tab carries the node's own output so you can see
what it is doing.

Wallet fixes. Both window headers spelled out the upstream project's name.
The address hints still said o1 in English, Russian and Chinese while the
validator had already moved to the j1 prefix — the wallet was refusing exactly
the addresses it told you to paste.


Downloads

You want File
The desktop app, Windows Jetsam-Desktop-1.1.0-windows-x64.zip
The desktop app, Linux Jetsam-Desktop-1.1.0-linux-x64.tar.gz
Just the node, Linux jetsam-node-linux-x86_64
Just the node, Windows jetsam-node-windows-x86_64.exe
Command-line wallet jetsam-cli-linux-x86_64 / jetsam-cli-windows-x86_64.exe

The desktop app carries its own node — you do not need the node file as well.

Verify what you downloaded against SHA256SUMS:

sha256sum -c SHA256SUMS --ignore-missing

Running the node on its own

chmod +x jetsam-node-linux-x86_64
./jetsam-node-linux-x86_64 --mode miner --miner-address j1…

Leave off --mode miner to verify without mining. The node finds its peers
through the DNS seeds; no --peer argument is needed.

Jetsam v1.0.4 — the template stamps the clock, not parent + 1

Choose a tag to compare

@Jetsam-dev Jetsam-dev released this 05 Sep 11:55

Important

Miners: please upgrade. This release fixes a defect in v1.0.1–v1.0.3 that makes the
whole network's difficulty climb without bound. It is not a consensus change — your blocks
stay valid either way — but the fix only works if the nodes that build templates run it.

What was wrong

Every block template served over JSON-RPC was stamped one second after its parent, whatever
the real time was. The comment justifying it claimed a block's difficulty target is derived from
its own timestamp. That has not been true since the target was anchored on the parent, and the
test difficulty_target_is_anchored_on_parent_not_on_self proves it: two children of one parent
receive the same target no matter what they stamp.

So stamping early bought the miner nothing at all. What it did was tell ASERT that one second
had elapsed since the parent, and ASERT responded by hardening the target of the next block
— for everyone, the stamper included.

Why it got worse over time

Every upgraded node stamped this way, so the effect grew as the network updated. Measured on
mainnet:

Height range Blocks stamped parent + 1
1019–1118 0%
1219–1318 38%
1419–1518 53%
last 50 before the fix 62%

Single steps of +29% in target. 155% in thirteen blocks. A 38-minute gap between two
consecutive heights under a target no honest cadence could meet. The chain only kept moving
because some miners still stamped real time and relieved the pressure — with every miner
upgraded, the ratchet has no bound: the target multiplies by 1.77 per six-block epoch.

The fix

getBlockTemplate now stamps the wall clock, floored at median-of-last-11 + 1 so validity is
unchanged. This is exactly what the in-process miner has always done — none of its blocks carry
a one-second stamp.

This is a policy change, not a consensus change. There is no activation height and no fork.
Blocks produced by nodes that have not upgraded remain valid. But every node still running
v1.0.1–v1.0.3 keeps tightening the ratchet for everyone, which is why this asks for an upgrade
rather than announcing one.

Upgrading

Drop-in replacement. No database migration, no configuration change.

BASE=https://github.com/jetsam-chain/jetsam/releases/download/v1.0.4
curl -LO $BASE/jetsam-node-linux-x86_64
curl -LO $BASE/jetsam-cli-linux-x86_64
curl -LO $BASE/SHA256SUMS
sha256sum -c SHA256SUMS --ignore-missing
chmod +x jetsam-node-linux-x86_64 jetsam-cli-linux-x86_64

Windows builds are attached to this release as well.

Verification

This binary was started against mainnet before publication: peers within 30 seconds, synced,
followed the tip, zero network-v7 profile mismatch. Its embedded HistoryStep class bank
matches the one the running network uses.

Jetsam v1.0.3 — a bad nonce no longer takes the template away

Choose a tag to compare

@Jetsam-dev Jetsam-dev released this 05 Sep 07:40

Note

Binaries replaced on 5 September 2026. The first upload of this release was built
against the wrong HistoryStep class bank and could not peer with the network. If you
downloaded jetsam-node-* from this tag before 12:00 UTC, download it again and check it
against SHA256SUMS. The current files are correct and have been verified against the
live network; nothing about the consensus rules changed.

Mining

A bad nonce no longer takes the block template away from everyone.
The node prepares one external template at a time. submitBlock used to consume that template before checking the submitted nonce was a proof of work, so a single invalid submission destroyed the template every other worker was still mining. Template ids are a namespace plus a counter, so they are guessable: a caller sending junk nonces could keep a pool permanently without work. The proof of work is now verified while the template is still staged, and only a valid nonce consumes it.

A pooled miner can be given a nonce range of its own.
jetsam-miner now accepts an optional nonce_prefix field on the block template and searches inside prefix << 96 — a region of 2^96 nonces per worker. Without it, every machine receiving the same template started somewhere in a window of 10^9 nonces and spent much of its time re-hashing what its neighbours had already covered. A node that does not send the field is handled exactly as before, so solo mining is unchanged.

The nonce search no longer forgets where it stopped.
A template that expires mid-search is fetched again and searched again. The miner used to restart from a fresh random point, re-hashing the range the previous pass had already covered. The search cursor now only moves forward.

Wallet

A payment caught in a reorganization stays in your history.
When the block holding one of your payments left the canonical chain, the entry was deleted unless the same transaction reappeared in the replacement blocks — while the coins returned to your balance. You saw a refund with no record of ever having sent anything. The payment now returns to the pending state, and is confirmed again at its new height if it is mined on the replacement branch. The receipt, which commits to the orphaned block header, is still removed.

A payment the mempool drops no longer haunts the wallet.
Nothing undid a send that was accepted into the mempool and later evicted: the history kept a "sent" line that could never confirm, and the UTXOs that send had reserved were excluded from every later coin selection for the rest of the process's life. The wallet now learns of the eviction and releases exactly that transaction's reservation. Eviction under pool pressure is deliberately left alone — the transaction is still valid and another node may mine it.

Upgrading

Drop-in replacement for v1.0.2. No database migration, no configuration change, no consensus change — a v1.0.3 node and a v1.0.2 node stay on the same chain.

BASE=https://github.com/jetsam-chain/jetsam/releases/download/v1.0.3
curl -LO $BASE/jetsam-node-linux-x86_64
curl -LO $BASE/jetsam-cli-linux-x86_64
curl -LO $BASE/SHA256SUMS
sha256sum -c SHA256SUMS --ignore-missing
chmod +x jetsam-node-linux-x86_64 jetsam-cli-linux-x86_64

Windows builds are attached to this release as well. Every binary Jetsam
publishes lives here, on GitHub Releases, and nowhere else.

Jetsam v1.0.2 — sending works, and the miner reports its hashrate

Choose a tag to compare

@Jetsam-dev Jetsam-dev released this 04 Sep 16:16

Jetsam v1.0.2 — mainnet, with the hashrate in plain sight

Jetsam is on mainnet. A node mines on its own CPU — there is no separate
miner to install and no pool account to create. Download two files, run one
command, and you are mining. Your node finds the network by itself through the
built-in seeds; you never pass an IP.

New in this release

  • Windows binaries. The node and the wallet now ship for Windows x86-64 as
    well, self-contained and with no runtime to install.
  • jetsam-cli send works. The client-side check still required the upstream
    address prefix and rejected every valid j1… address before it reached the
    node, so no coin could be spent from the CLI. Fixed, with a regression test.
  • The miner reports its measured hashrate every 15 seconds, and
    jetsam-cli mining reports it on demand.
  • --bench measures what a machine is worth before you commit it — no
    wallet, no chain data, no network.
  • --help now lists the commands you actually use, node and wallet.
  • An empty wallet on a node started with --miner-address now says so,
    instead of suggesting you check your data directory.

1. Download

Copy-paste this — it fetches the node, the wallet, and the checksums, then makes
them runnable:

Linux

curl -sL -O https://github.com/jetsam-chain/jetsam/releases/latest/download/jetsam-node-linux-x86_64 \
        -O https://github.com/jetsam-chain/jetsam/releases/latest/download/jetsam-cli-linux-x86_64 \
        -O https://github.com/jetsam-chain/jetsam/releases/latest/download/SHA256SUMS
sha256sum -c --ignore-missing SHA256SUMS      # both must say: OK
chmod +x jetsam-node-linux-x86_64 jetsam-cli-linux-x86_64

Windows — PowerShell. The executables are self-contained: nothing to install,
no runtime, no DLL.

curl.exe -sL -O https://github.com/jetsam-chain/jetsam/releases/latest/download/jetsam-node-windows-x86_64.exe
curl.exe -sL -O https://github.com/jetsam-chain/jetsam/releases/latest/download/jetsam-cli-windows-x86_64.exe
Get-FileHash -Algorithm SHA256 .\jetsam-node-windows-x86_64.exe, .\jetsam-cli-windows-x86_64.exe
# compare both hashes against SHA256SUMS on this page
.\jetsam-node-windows-x86_64.exe --check-hardware
File What it is
jetsam-node-linux-x86_64 / jetsam-node-windows-x86_64.exe the node — runs the chain and mines on CPU
jetsam-cli-linux-x86_64 / jetsam-cli-windows-x86_64.exe your wallet: balance, address, send

Requirements: 64-bit Linux or Windows, a CPU with SSE4.1 + PCLMULQDQ (any CPU
since ~2011). A CPU with AVX-512 selects a much faster backend automatically:
measured 99.2 kH/s per thread on an AVX-512 desktop against 15.1 kH/s per thread
on a Zen 2 server core.
Check the machine, and see what it is worth before you commit it:

./jetsam-node-linux-x86_64 --check-hardware      # must end with: NODE READY
./jetsam-node-linux-x86_64 --bench               # TowerHash rate, 10 seconds

--bench touches nothing: no wallet, no chain data, no network. It prints the
rate this machine will mine at, and the rate of a single thread — the figure
that tells you how many threads a given CPU needs to pull its weight.

2. Start mining

One command. It creates your wallet on first run, connects to the network, and
mines to your own address:

./jetsam-node-linux-x86_64 --mode miner --cpu-threads 4

Leave it running. Use more threads for more hashrate (--cpu-threads 8, etc.).
Every 15 seconds it tells you exactly what it is doing:

12:04:31  INFO miner: 2.79 MH/s (16 threads, 41068544 hashes total) height=757

That's it — you are mining.

--miner-address pays somewhere else, on purpose. Passing it makes the
node credit blocks to that address, not to the wallet on this machine — so
balance here will stay at zero forever, which is correct and is now stated
plainly. Leave the flag out to mine to your own wallet.

3. Your wallet

Open a second terminal (the node must stay running):

./jetsam-cli-linux-x86_64 address      # your j1... address — this is what you mine to
./jetsam-cli-linux-x86_64 balance      # your JTM balance
./jetsam-cli-linux-x86_64 mining       # difficulty, block reward, payout address, your hashrate
./jetsam-cli-linux-x86_64 send j1_destination 10.5    # send 10.5 JTM

Back up your wallet. Everything you own is in ~/.jetsam/data/wallet.key.
Copy it somewhere safe. To restore on another machine:

./jetsam-node-linux-x86_64 --export-wallet-secret --data-dir ~/.jetsam/data > my-secret.txt
# later, on any machine:
cat my-secret.txt | ./jetsam-node-linux-x86_64 --import-wallet-secret --data-dir ~/.jetsam/data

4. Every command

--help on either binary prints the complete interface. These are the ones you
will actually use.

Node./jetsam-node-linux-x86_64 <flags>

Flag What it does
(none) ordinary node: verify and relay, no mining
--mode miner mine to your own wallet address
--cpu-threads N keep the miner to N logical CPUs
--bench [SECONDS] measure this machine's hashrate, then exit
--check-hardware verify CPU support, then exit
--miner-address j1... pay blocks to another address (not this wallet)
--seed HOST:9700 add an explicit entry point
--data-dir PATH use a different data directory

Wallet./jetsam-cli-linux-x86_64 <command>, with the node running

Command What it does
status sync state, peers, tip height
mining difficulty, block reward, payout address, your hashrate
address your j1... address
balance what you have mined
utxos your individual coins
utxos-of <j1...> coins held by any address
send <j1-address> 10.5 send 10.5 JTM (--dry-run to price it first)
history your past transactions
mempool transactions waiting to be mined
peers / state network and chain detail
stop shut the node down cleanly

Details

  • Addresses are j1... (bech32m). Amounts are in JTM (1 JTM = 1,000,000 µJTM).
  • Ports: 9700 peer-to-peer (open it inbound in your firewall for best
    connectivity), 9701 local RPC (keep it private — do not expose it).
  • Genesis and the network seeds are built into the binary. No configuration,
    no --seed, no IP to type.
  • Genesis block ID
    6e592c07be6fd1b4259eeacbf4eb7eb2948a77f1d02626a12fdab42c448c5f44.
  • Live height, difficulty and supply: explorer.jetsamchain.com.

GPU mining

There is no GPU miner in this release, and there won't be an official one. A
node mines on CPU out of the box; a faster GPU miner is for the community to
build. The proof-of-work is TowerHash and the work protocol is
jetsam_getBlockTemplate / jetsam_submitBlock over the node's RPC — enough
to write one. Build the fastest miner and the rewards are yours to take.