The discussion around Solana’s “200 milliseconds” now has a new on-chain time marker. The previous post focused on waiting for the next epoch; when I checked mainnet again at 23:39 Beijing time on October 9, the epoch had advanced from 1052 to 1053, with slotIndex at 15946. This change is worth reporting, but the target slot duration, actual slot progression, and transaction finality should still be understood separately.
First, here is the verifiable sequence. The original SIMD-0525 proposal is still marked Draft. It divides the target slot time into four steps—350, 300, 250, and 200 milliseconds—while keeping each epoch at 432,000 slots. It explicitly distinguishes feature activation from when the parameters take effect: a phase activates in epoch E, and the new parameters are used starting in E+1. The word “planned” in the title alone is not evidence that it has gone live on mainnet.
This time, I also checked the four mainnet Feature accounts listed in the original proposal, rather than just the proposal status. The 200-millisecond account is owned by the Feature program and returns 9 bytes of data. Decoding the first byte as the Option flag and the remaining 8 bytes as a little-endian slot gives an activation slot of 454464000, corresponding to epoch 1052. The current RPC response reports epoch 1053. Taken together with the original proposal’s one-epoch delay rule, the account evidence shows that the network has entered the epoch in which this phase is expected to take effect. This is a new verification point compared with the previous post’s 375373124146619; the proposal webpage’s status itself has not changed.
I also sampled actual slot progression. The latest three complete 60-second performance windows from that RPC recorded 278, 271, and 272 slots, which works out to approximately 216, 221, and 221 milliseconds per slot. These are average network progression rates over short windows. They are close to the 200-millisecond target, but that does not mean every slot takes exactly 200 milliseconds, much less that any given transaction will reach finality within 200 milliseconds. The samples are affected by the window, node, and network conditions, so one minute of data cannot be used to promise long-term performance.
I’m watching two things. First, shorter slots provide finer time granularity, but the original proposal also adjusts the per-slot work limit proportionally, so it does not follow that throughput will double. The leader still handles 4 consecutive slots, making the nominal window 800 milliseconds at the 200-millisecond target. Second, the proposal calls for coordinated changes to timing, work limits, snapshot recovery, and other areas, so operational performance needs to be monitored continuously rather than judged by a single speed figure.
The data in this update comes from Solana mainnet’s public RPC methods getEpochInfo, getMultipleAccounts, and getRecentPerformanceSamples, and is interpreted alongside the original SIMD-0525 proposal. The limits of this assessment are clear: the Feature account and new epoch provide more specific evidence than “check again next epoch,” while the short samples offer additional information about progression speed. They do not prove long-term network-wide stability, nor do they answer how application experience, finality, or the price of SOL will change.
Next, I’ll look at whether more windows of the same length show the rate holding steady, while keeping an eye on official operational updates from clients and projects. If the samples fall significantly or an anomaly is officially disclosed, the current interpretation should be reassessed. Protocol developments can be updated; the direction of the token price still requires separate evidence.
First, here is the verifiable sequence. The original SIMD-0525 proposal is still marked Draft. It divides the target slot time into four steps—350, 300, 250, and 200 milliseconds—while keeping each epoch at 432,000 slots. It explicitly distinguishes feature activation from when the parameters take effect: a phase activates in epoch E, and the new parameters are used starting in E+1. The word “planned” in the title alone is not evidence that it has gone live on mainnet.
This time, I also checked the four mainnet Feature accounts listed in the original proposal, rather than just the proposal status. The 200-millisecond account is owned by the Feature program and returns 9 bytes of data. Decoding the first byte as the Option flag and the remaining 8 bytes as a little-endian slot gives an activation slot of 454464000, corresponding to epoch 1052. The current RPC response reports epoch 1053. Taken together with the original proposal’s one-epoch delay rule, the account evidence shows that the network has entered the epoch in which this phase is expected to take effect. This is a new verification point compared with the previous post’s 375373124146619; the proposal webpage’s status itself has not changed.
I also sampled actual slot progression. The latest three complete 60-second performance windows from that RPC recorded 278, 271, and 272 slots, which works out to approximately 216, 221, and 221 milliseconds per slot. These are average network progression rates over short windows. They are close to the 200-millisecond target, but that does not mean every slot takes exactly 200 milliseconds, much less that any given transaction will reach finality within 200 milliseconds. The samples are affected by the window, node, and network conditions, so one minute of data cannot be used to promise long-term performance.
I’m watching two things. First, shorter slots provide finer time granularity, but the original proposal also adjusts the per-slot work limit proportionally, so it does not follow that throughput will double. The leader still handles 4 consecutive slots, making the nominal window 800 milliseconds at the 200-millisecond target. Second, the proposal calls for coordinated changes to timing, work limits, snapshot recovery, and other areas, so operational performance needs to be monitored continuously rather than judged by a single speed figure.
The data in this update comes from Solana mainnet’s public RPC methods getEpochInfo, getMultipleAccounts, and getRecentPerformanceSamples, and is interpreted alongside the original SIMD-0525 proposal. The limits of this assessment are clear: the Feature account and new epoch provide more specific evidence than “check again next epoch,” while the short samples offer additional information about progression speed. They do not prove long-term network-wide stability, nor do they answer how application experience, finality, or the price of SOL will change.
Next, I’ll look at whether more windows of the same length show the rate holding steady, while keeping an eye on official operational updates from clients and projects. If the samples fall significantly or an anomaly is officially disclosed, the current interpretation should be reassessed. Protocol developments can be updated; the direction of the token price still requires separate evidence.