Releases: jetsam-chain/jetsam
Release list
v1.2.0 — consensus change at block 8450
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
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
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-missingJetsam v1.1.0 — hardfork at height 2000, NAT traversal, desktop app
⚠️ 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-missingRunning 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
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_64Windows 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
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_64Windows 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
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 sendworks. The client-side check still required the upstream
address prefix and rejected every validj1…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 miningreports it on demand. --benchmeasures what a machine is worth before you commit it — no
wallet, no chain data, no network.--helpnow lists the commands you actually use, node and wallet.- An empty wallet on a node started with
--miner-addressnow 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_64Windows — 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 4Leave 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-addresspays somewhere else, on purpose. Passing it makes the
node credit blocks to that address, not to the wallet on this machine — so
balancehere 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 JTMBack 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/data4. 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.