Solana's 350ms Slots Go Live — X1 and Solana Now Run the Same Clock

Solana's slot time dropped below 400 milliseconds for the first time this week. The first of four reductions under SIMD-0525 took effect at the start of epoch 1020, cutting the target slot duration from 400ms to 350ms — a 12.5% reduction in the target, or 14.3% more slots produced per unit of time.

It is a real engineering milestone, delivered carefully. It also puts two SVM networks on the same clock. X1 has been producing blocks at that rate since its genesis block in October 2025, and as of this week Solana measures the same.

That is less of a rivalry than it first sounds. These are sister chains — same virtual machine, same client lineage, same inflation schedule, comparable validator sets. What follows is a measurement of where they now sit relative to each other, and where they have deliberately chosen to differ.

What we measured

Target slot time and observed slot time are not the same number. Every network skips some slots, so the wall-clock interval between blocks always runs a little slower than the target. The only fair comparison is measured against measured, so we pulled getBlockTime from each chain's public RPC and divided elapsed seconds by elapsed slots across matched windows.

Solana moved from 414ms to 366ms. X1's ten-month range is 365ms to 388ms and it currently sits at 366ms. Measured honestly, the two networks now produce blocks at the same rate.

You can verify the X1 side without trusting us. The official X1 explorer publishes live 1-minute and 1-hour slot time averages on its front page, and X1 Galaxy shows the same figure alongside epoch progress. Both read 366–368ms as we write, at epoch 350, with validators running Tachyon v3.1.14.

How alike these two chains actually are

The slot time convergence is not a coincidence. X1 runs Tachyon, a client from the same lineage as Solana's Agave, on the same Solana Virtual Machine. The family resemblance runs deeper than the execution layer:

The inflation row is the striking one. Query getInflationGovernor on either chain and you get byte-identical parameters: 8% initial, 15% annual taper, 1.5% terminal floor. X1 did not approximate Solana's monetary policy — it adopted it. The only difference is where each chain sits on the curve. X1's 6.88% is roughly where Solana was in its own early years; Solana has tapered down to 3.69%. X1 additionally runs a 5% foundation allocation over a seven-year term, a provision Solana's schedule has already retired.

Validator counts land in the same range too — 684 active on Solana against 588 on X1, with X1 actually registering the larger total set at 722 against 694. For a network ten months old, standing up a validator base within striking distance of the reference implementation is not a small thing.

Where X1 diverges on purpose

Sister chains, not clones. X1's most consequential departure is that votes are free.

On Solana, consensus voting is a paid transaction, and X1's own technical documentation puts the cost bluntly: at $250/SOL a validator pays roughly $8,600 per month to participate, with 94% of that going to vote fees. That is a barrier that falls hardest on small operators and compounds toward centralisation. X1 removed it, pairing zero-cost votes with congestion-reflective dynamic base fees so that blocks never fill and votes cannot be crowded out.

The second departure is Project Capybara, which reshaped Foundation delegation around a P85 percentile self-stake threshold. Before it, two XNT qualified a validator for delegation — an effectively nonexistent barrier that rewarded minimum-stake VPS farms. Capybara moved the floor to a dynamic percentile of the active set, directing delegation toward operators with real capital and real uptime at risk. Free votes lower the cost of honest participation; Capybara raises the cost of extractive participation. The two policies work as a pair.

The throughput record was a plateau, not a spike

X1's highest recorded throughput is 29,134.2 TPS, set during epoch 216. Peak numbers are easy to dismiss as a momentary burst, so we went back and sampled the chain across that period. It was not a burst.

Sampling consecutive blocks at six points inside epoch 216 and at the midpoint of every neighbouring epoch, X1 held between 4,300 and 6,200 TPS continuously from 28 April to 4 May — a full week — with the 29,134 peak sitting on top of that plateau. The slot time through the same window stayed in the 330–370ms band.

That answers the fair question anyone should ask about a fast clock: does it hold under load? On X1 the answer is measured rather than theoretical. The network sustained multi-thousand-TPS traffic for days without the block interval degrading.

Being precise about what that traffic was: it is predominantly consensus traffic, roughly 98% vote transactions at the block level. That is exactly what zero-cost votes are designed to permit — on Solana that same volume of voting would have been metered and billed to operators. X1's application layer is genuinely early by comparison; Solana currently settles around 3,590 non-vote TPS against X1's 14. That gap is the honest shape of a ten-month-old chain next to a six-year-old one, and it is a demand problem rather than a capacity problem. The pipeline has already demonstrated it can carry the volume when there is volume to carry.

What comes next

SIMD-0525 is four sequential 50ms decrements — 400 to 350, then 300, 250 and 200 — each behind its own feature gate needing supermajority endorsement from roughly two-thirds of staked validators. Each step also carries a one-epoch delay: the 350ms feature activated at slot 440,208,000, the first slot of epoch 1019, but the network held 400ms parameters through that whole epoch and switched only at the first slot of epoch 1020. No activation epoch has been announced for the 300ms step.

Shorter slots also mean smaller blocks. The proposal scales per-slot compute limits inversely with slot duration, using trunc(current_400ms_value * target_slot_ms / 400):

Ticks per slot stay fixed at 64 and the tick duration shrinks, so total compute per second is unchanged. What improves is confirmation latency and market structure: at 200ms a leader's window halves from 1.6 seconds to 800ms, cutting the worst-case time any single leader can delay, reorder or selectively include transactions.

Because the two chains share an execution environment, that work is not walled off. The parameter scaling, the shred-limit handling and the phased activation pattern are all published, tested in public, and applicable to any SVM network that wants to follow. X1 has not announced a timeline for tracking the remaining steps, but it has a well-mapped path and a demonstrated tolerance for a sub-400ms clock.

For now the position is simple and, for a chain not yet a year old, a good one to be in: X1 and Solana produce a block roughly every 366 milliseconds. One of them has just finished a substantial coordinated upgrade to get there. The other has been running that way since 6 October 2025.

Slot times, validator counts and inflation parameters measured 21 August 2026 via getBlockTime, getVoteAccounts and getInflationGovernor on rpc.mainnet.x1.xyz and api.mainnet-beta.solana.com. Historical throughput measured by summing transaction signatures across runs of consecutive blocks and dividing by elapsed block time; vote/non-vote split from per-transaction account keys. Figures are point-in-time and will drift.

Related: Tachyon v3.1.14 hits X1 mainnet · Project Capybara and the P85 threshold · X1 validators · What is X1 Blockchain