Tachyon v4.0.3 is ready for X1 mainnet. Nicholas Pettas, a core developer at X1 Labs, announced the release today, and it is the one that closes the gap with upstream: Tachyon rebases from Agave v3.1.14 onto Agave v4.0.3, carrying across every X1 customization — the dynamic fee model, feature-gate keys, reward and fee distribution, genesis configuration, RPC endpoints and branding.
The release was published at 17:42 UTC on September 10, 2026. X1's public RPC endpoint already answers getVersion with solana-core: 4.0.3 — up from the 3.1.14 that validators have been running since the summer.
Operators should read this one carefully. The upgrade itself is unusually gentle, but it contains a genuine one-way door.
The good news: it is a rolling restart
X1 Labs ran mixed-cluster validation before shipping, and the results are about as reassuring as this kind of test gets. A v4.0 node successfully joined a v3.1-led cluster: gossip shred versions matched, a v3.1-produced snapshot loaded and replayed in lockstep, and independently recomputed bank hashes matched at every comparable rooted slot — including across an epoch boundary. Snapshots remain wire-compatible in both directions.
In practice that means you do not need a coordinated network-wide stop. Validators can upgrade on their own schedule and coexist with nodes still on v3.1 while the rollout proceeds.
The catch: "rolling restart" assumes your flags are already correct
This is the part worth emphasising, because the phrase makes the upgrade sound more automatic than it is. If your startup script still contains flags that v4.0 removed, the node will not start. Fix the configuration first, then restart.
Three changes will stop a node cold:
- QUIC only. UDP transaction ingestion is gone entirely.
--tpu-enable-udp,--tpu-disable-quic,--use-udpand--use-quichave all been removed. --block-verification-method blockstore-processoris no longer supported. Drop the flag, or switch it tounified-scheduler.- A wider port range is required. v4 needs more room than v3 did — set
--dynamic-port-range 8000-8030, and make sure your firewall and any cloud security group actually permit that range. A node that starts but cannot reach its full port range will look healthy and perform badly.
The full list of deprecated flags removed in this release:
--accounts-db-clean-threads | --accounts-db-hash-threads |
--accounts-db-read-cache-limit-mb | --accounts-hash-cache-path |
--cuda | --disable-accounts-disk-index |
--dev-halt-at-slot | --monitor (exit subcommand) |
--transaction-struct | --wait-for-exit (exit subcommand) |
--tpu-coalesce-ms | --tpu-disable-quic |
--tpu-enable-udp |
The one-way door: blockstore formats
v4.0 drops fallback reads for several legacy blockstore formats — PerfSampleV1, SlotMetaV1 and IndexV1, and pre-v1.18 transaction-metadata keys.
The consequence deserves stating bluntly: once a ledger has been written by v4.0, there is no clean downgrade path. Snapshots are wire-compatible in both directions, but the ledger itself is not. If you need the ability to roll back to v3.1, take a snapshot before you upgrade and be prepared to start from it rather than from the existing ledger directory.
This is not a reason to delay — it is a reason to have your rollback plan written down before you start, rather than discovering the constraint at three in the morning.
Twelve feature gates, all shipping inactive
The release carries X1's full slate of twelve feature gates, and every one of them ships inactive. Installing v4.0.3 does not change consensus behaviour on day one. The gates activate later, at their activation epochs, once enough stake is running a version that understands them.
We covered the slate in depth when the plan was announced — see Twelve Feature Gates: Inside X1's v4.0 Upgrade Plan for what each one does and why it matters. The two Pettas singled out today are the two with the widest blast radius:
| Gate | SIMD | Effect |
|---|---|---|
replace_spl_token_with_p_token | 0266 | Replaces the SPL Token program with p-token — same instruction set, a fraction of the compute cost. A one-shot core-BPF migration fires at the activation epoch. |
upgrade_bpf_stake_program_to_v5 | 0490 | Upgrades the Stake program to v5.0.0 and raises the minimum stake delegation to 1 XNT for new delegations. Existing delegations are unaffected. |
The gate keys, for anyone verifying on-chain: AHK6QUkHPbom1bFpJi45qzKVGh3E12dVqEh5NSE7c1Up for p-token, and EuvKrWuxk9Dtu448etY554V1iU7CXXnT3gS6drqQwByc for stake v5.
The remaining ten cover account prefunding (0312), delayed commission updates (0249), chained block ID validation (0340), SBPFv3 deployment and execution (0178 / 0189 / 0377), syscall address restrictions (0459), three cryptography gates for alt_bn128 and BLS12-381 (0284, 0302, 0388), and vote cost-model accounting (0458).
One gate on the list is X1-only rather than an upstream SIMD: vote_min_stake_1_xnt, which raises the minimum vote-account stake required for vote inclusion to 1 XNT.
How to upgrade
Switch to either the v4.0 branch or the v4.0.3 tag at github.com/x1-labs/tachyon, then:
- Audit your startup flags first against the removal list above. This is the step that breaks upgrades.
- Set
--dynamic-port-range 8000-8030and open the range at the firewall. - Take a snapshot if you want a viable rollback, given the blockstore change.
- Build and restart. No coordinated network stop is required.
- Confirm with
getVersionthat your node answers4.0.3, then watch your vote credits and skip rate through the next epoch boundary.
Operators running through a management console rather than by hand should wait for their tooling to catch up before switching branches. If you are tracking your delegation status while you upgrade, note that the X1 Foundation's delegation criteria include a minimum client version — our delegation program guide covers how those checks work.
What this means for X1
Before today, X1 ran roughly one major version behind Solana. Tachyon v4.0.3 closes most of that distance in a single pass, and it does so without asking the network for a coordinated fork — a rolling restart, validated against a mixed cluster, with every consensus change held behind a gate that has not fired yet.
That is a deliberately conservative way to ship a major version, and it is the right one. The interesting part of v4.0 is not the release; it is the twelve gates waiting behind it, and the epochs at which they turn on.
Release: Tachyon v4.0.3 on GitHub, published 17:42 UTC on September 10, 2026. Version confirmed against X1 mainnet RPC the same day.