6-second slots are under discussion likely for the i* hard fork in 2027-28. But imo we should just aim to do faster finality/3slot finality in i*, instead of 6s slots. 6s slots aren't a game changer. Ironically, perhaps the top line item benefit of 6s slots is halving finality time. But 3SF (a leading faster finality solution) is a 22x improvement (36 seconds to finality) vs 6s is a 2x improvement (6.5 minutes to finality). imo the "real problem" in the eth L1 protocol this era is not that users have to wait an average of 6s instead of 3s for L1 confirmation. Or that finality times aren't 6.5mins and are instead 13mins (needs to be *way* lower than 6.5mins, is a real problem). Or that L1 mev is higher due to 12s slots instead of 6s. imo the actual real problems: 1. ~13min finality greatly affects L2 and CEX deposit/withdrawal UX. It needs to be sub-minute or better to be "solved", not 6.5mins. 3slot finality (3SF) may be emerging as a research winner, which would give us 36-second finality, a 22x improvement. Then we get 18-second finality (or faster) after eventually shipping 6-second slots (or faster) over the longer term. 2. Eth doesn't yet hvae enough blobs, by far. This is not to take away from epic recent wins with peerDAS and BPO forks. Someday, blobs will saturate, earn high fees, there will be new L2s that can't afford to use blobs, and major existing L2s that have to leave blobs. We want that day to be as far in the future as possible to maximize eth's network effect accumulation before the pain of saturation. E.g. we don't want either Base or World Chain to leave blobs. Each is growing so fast that them "outgrowing blobs" is a realistic threat to the L1+L2 model's nascent success and market acceptance. Other real problems: 3. Lean ethereum isn't live, so L1 execution is not yet powered by zk validity proofs. Without validity proofs, validators still have to re-execute all L1 transactions and receive all the data to do so, a major scalability blocker. Lean eth will not be production ready for ~4-5 years, in whole or part, so it's not a competitor in i* fork scheduling. ...