Nick Pettas, a core developer at X1 Labs, has posted the v4.0 plan to the X1 Validators Telegram group. It is the clearest public statement so far of what changes next at X1's protocol layer, and it comes with a number that anchors everything else: twelve feature gates.
"We're currently on v3.1, with v4.0 coming out soon. Solana just released v4.2," he wrote. "All of our v3.1 FGs have been activated."
Both halves check out against the chains themselves. X1 mainnet answers getVersion with solana-core 3.1.14 — the Tachyon build validators have been running through the summer. Solana mainnet answers 4.2.1. X1 sits roughly one major version behind its upstream, and v4.0 is the release that closes most of that gap in a single pass.
What a feature gate actually is
A feature gate is a dormant switch inside the validator client. Consensus-affecting behaviour ships in a release but stays inert; it activates only once a supermajority of stake is running a version that understands it and the activation epoch arrives. It is how an SVM chain rewrites its own rules without a coordinated stop-the-world hard fork, and it is why the same binary can produce different blocks depending on which epoch it is in.
Two structural facts about X1's list matter more than any individual entry.
First: none of these twelve are X1 inventions. Every one is a Solana Improvement Document, specified and implemented upstream, and the headline gates have already been exercised in production on Solana mainnet. SIMD-0266 — the largest of them — went live on Solana at epoch 971, requiring at least Agave v3.1.7. SIMD-0490 activated on Solana on 18 June 2026. X1 is not running an experiment here. It is importing a batch that has already been stress-tested at considerably larger scale, on a network with the same virtual machine and the same client lineage.
Second: the sequencing is deliberate. Pettas notes that the p-token migration "goes first, alone in its epoch," and that gates 9 and 10 activate together because Solana activated both at the same slot. X1 epochs are 216,000 slots long, and the chain is currently producing a slot every 366ms — the official explorer reads 47.9% epoch progress with roughly 11h 28m remaining as we write, at epoch 362. That puts an X1 epoch at about 22 hours. A gate-per-epoch cadence on X1 is close to a gate per day, which is a considerably tighter rollout schedule than the same list ran on at ~2-day Solana epochs.
The twelve, in order
| # | Gate | SIMD | What it changes |
|---|---|---|---|
| 1 | replace_spl_token_with_p_token | 0266 | SPL Token swapped for p-token, same instruction set at a fraction of the compute |
| 2 | create_account_allow_prefund | 0312 | Account creation on an address that already holds lamports |
| 3 | remove_simple_vote_from_cost_model | 0458 | Votes costed by the normal cost model instead of a static value |
| 4 | alt_bn128_little_endian | 0284 | Little-endian I/O for BN254 syscalls |
| 5 | enable_alt_bn128_g2_syscalls | 0302 | BN254 G2 group operations as syscalls |
| 6 | enable_bls12_381_syscall | 0388 | BLS12-381 group ops, pairings, hash-to-curve |
| 7 | upgrade_bpf_stake_program_to_v5 | 0490 | Stake program v5.0.0, with a 1 XNT minimum delegation |
| 8 | delay_commission_updates | 0249 | Commission changes take effect one epoch later |
| 9 | validate_chained_block_id | 0340 | Shreds carry a chained block ID, bound to the parent |
| 10 | validate_chained_block_id_2 | 0340 | The encompassing check; same epoch as #9 |
| 11 | enable_sbpf_v3_deployment_and_execution | 0178 / 0189 / 0377 | SBPFv3 programs: static syscalls, stricter ELF, eBPF ISA compatibility |
| 12 | syscall_parameter_address_restrictions | 0459 | Restricts which addresses a syscall parameter may point to |
The one every user will feel: p-token
SIMD-0266 replaces the SPL Token program with p-token, a Pinocchio-based rewrite that keeps account layouts, instruction discriminators and account structures byte-for-byte identical. Nothing about your wallet, your token accounts or your existing programs changes. What changes is the bill.
| Instruction | SPL Token | p-token | Remaining |
|---|---|---|---|
| Transfer | 4,645 CU | 76 CU | 1.6% |
| MintTo | 4,538 CU | 119 CU | 2.6% |
| InitializeAccount | 4,527 CU | 154 CU | 3.4% |
| Approve | 2,904 CU | 124 CU | 4.2% |
A 95–98% reduction in compute across the instruction set. Compute units are the scarce resource in a block, so this is not a fee story so much as a capacity story: token transfers stop being the dominant line item in a block's budget, and everything else on X1 — DEX routes, bridge mints, game transactions, confidential transfers — gets more room to execute alongside them. On a chain whose entire retail surface is token movement, it is the single highest-leverage change on the list.
It goes first and alone because it is a one-shot core-BPF migration that fires at the activation epoch. Nothing else should be moving while the token program is being swapped underneath the network.
The one thing that does break is off-chain indexing. p-token adds three instructions — batch, withdraw_excess_lamports and unwrap_lamports — and any explorer, bot or analytics pipeline that parses X1 token instructions against an old IDL will need updating. X1's explorer operators, indexers and trading bots should treat that epoch as a deadline, not a surprise.
The one stakers will feel: stake program v5
SIMD-0490 upgrades the core-BPF Stake program to v5.0.0. Most of it is routine: sysvar account inputs become optional, the split processor is rewritten so deactivated stakes can be split, and merges now sweep all lamports from the source account rather than just delegation plus reserve. Pettas flags that it also requires a program buffer to be deployed beforehand — an operational prerequisite, not a user-facing one.
The clause that gets attention is the minimum. After activation, you cannot create a new stake account with a delegation below 1 XNT. Existing accounts are untouched, and merges are still allowed even when the destination does not clear the threshold — this is a creation rule, not a confiscation.
On Solana that rule bites: 1 SOL is about $102 at the time of writing, and it priced a lot of small delegators out of creating fresh stake accounts. On X1 the same rule costs about $0.39. The identical SIMD lands with completely different force on the two chains, purely because of the token price.
It will, however, end a very specific X1 habit. We pulled every stake account on X1 mainnet: 7,678 accounts, 7,546 of them carrying a delegation. Of those, 3,221 — 42.7% — hold less than 1 XNT, and they hold about 103 XNT between them. That is 43% of X1's stake accounts by count and effectively 0% by value. The median delegation on the network is 2.01 XNT; 63% of accounts sit below 10 XNT.
Whatever produced that long tail of dust — faucet-era experiments, scripted account creation, testing — v5 stops more of it from being created, for the price of a fifth of a cup of coffee. The accounts already on-chain keep working.
The one delegators should care about: delayed commission
SIMD-0249 is small, boring, and the most directly protective change in the batch. Today a validator can raise its commission moments before rewards are distributed and capture a slice of a full epoch's yield that delegators were never told about. After activation, commission changes take effect a full epoch later, using the commission recorded at the epoch snapshot.
X1 has 589 active vote accounts and roughly 1.007 billion XNT staked. It also caps commission at 10% by protocol design, which already limits the size of the theft, but a cap does not stop the timing trick — it only bounds it. This gate removes the trick itself, and it does so on a network where most delegators are not watching commission fields between epochs.
The cryptography block: 0284, 0302, 0388
Three gates extend what programs can compute on-chain.
SIMD-0284 adds little-endian input and output to the existing alt_bn128 (BN254) syscalls. This is a byte-order fix with real consequences: EVM and most zk tooling speak little-endian, and today every X1 or Solana program consuming proofs from that world has to byte-swap in BPF, burning compute on a pure formatting problem. SIMD-0302 adds BN254 G2 group operations, without which pairing-based proof systems can only be partially implemented on-chain.
SIMD-0388 is the strategic one. It adds BLS12-381 group operations, point validation, batch pairings and decompression — a 128-bit-security curve suitable for Groth16 verification, and, more to the point, for BLS signature aggregation. The upstream driver is Alpenglow: when validators register BLS public keys on-chain they must supply a proof of possession, and verifying that inside a BPF program needs exactly these syscalls. X1 runs the same consensus lineage as Solana, so this gate is X1 laying the groundwork for the same class of consensus upgrade rather than an abstract cryptography wishlist.
For X1 builders the near-term reading is simpler: after v4.0, zk verifiers, privacy protocols and proof-carrying bridges become cheap enough to deploy on X1 without a bespoke workaround. X1 already ships confidential payments through Token-2022; this is the layer underneath the next generation of that work.
The safety block: 0340, 0459, and SBPFv3
SIMD-0340 — shipped as two gates that activate in the same epoch — validates a chained block ID carried in shreds, binding every block to its parent at the shred level rather than only at the bank level. Pettas calls it "anti-equivocation groundwork," which is the right framing: it does not by itself stop a validator from producing two conflicting versions of a block, but it makes such a fork detectable at the point of propagation.
SIMD-0459 restricts which memory addresses a syscall parameter may point to, closing a class of cross-region pointer tricks in CPI. It is the successor to the withdrawn SIMD-0219, which attempted a much broader ABI cleanup and was scaled back to the part that could ship safely.
enable_sbpf_v3_deployment_and_execution bundles three SIMDs — SIMD-0178 static syscalls, SIMD-0189 stricter ELF headers, and SIMD-0377 eBPF ISA compatibility. Together they let X1 deploy and execute SBPFv3 programs: syscalls resolved statically at load time instead of through a runtime hash lookup, malformed binaries rejected at deploy rather than discovered at execution, and an instruction set that lines up with standard eBPF. Existing programs keep running; this is an additive capability that newer toolchains will target.
Finally, SIMD-0458 stops assigning simple vote transactions a statically defined compute cost and runs them through the same cost model as every other transaction. It also removes the vote CU limit entirely. The trigger is upstream: SIMD-0387 takes the Vote program out of builtin cost modelling, so the static assumption it rested on no longer holds.
This is block-space bookkeeping, not a fee. It is worth being explicit, because the wording invites the wrong reading: X1 validators do not pay lamports to vote today, and this gate does not change that. We sampled four recent finalized blocks on X1 mainnet — 581 to 591 vote transactions in each, and every one of them carried a fee of exactly 0 lamports. The handful of non-vote transactions sharing those blocks paid 1,500 lamports each. Nothing in SIMD-0458 touches the lamport side of a vote; it changes only how many compute units the block cost model counts against the block limit.
And the direction of that change is not the one you might expect. Actual consumption is unchanged at 3,428 CU before and after — 720 CU for the signature, 600 for two write locks, 2,100 for the vote instruction and 8 to load small accounts. What changes is the reservation: because the general cost model includes default account-data-loading costs, a simple vote reserves about 19,812 CU instead of 3,428, roughly 16K more. Under block-packing strategies that reserve upfront and refund unused CUs after execution, that means a larger initial reservation followed by a refund. So for X1 this gate is a correctness and consistency change that keeps vote accounting aligned with the rest of the cost model — not a source of extra block capacity, and mildly the opposite during packing. The capacity story in this batch belongs to p-token alone.
What v4.0 adds up to
Read as a set rather than a list, the twelve gates do three things. They reclaim block space (p-token). They close protocol-level footguns (syscall address restrictions, chained block IDs, delayed commission, the stake minimum). And they extend what can be computed on-chain (BN254 G2, little-endian alt_bn128, BLS12-381, SBPFv3).
None of it is speculative. Every gate has production mileage on a network moving far more transactions than X1 does, which is the underrated benefit of being a Solana-lineage chain one version behind: the upstream network runs the beta test, and X1 inherits the result with the failure modes already known.
What is genuinely X1-specific is the pace. At ~22-hour epochs and a gate-per-epoch schedule, a twelve-gate rollout that took Solana months of staggered activations compresses into a matter of weeks here. Validators should watch for the release announcement and the buffer deployment that gate #7 requires; everyone running an indexer, explorer or bot should be ready for p-token's three new instructions on day one.
No activation epochs have been published yet. We will track them as they are announced — the running log sits in Community Pulse on the front page.