What I’d really like to see is a dev perspective on why it does/doesn’t work. With data. No words. I think we already have lots of data. The issue is that most of them are not directly from affected teams. We made the effort to make visible all consequences (the one we thought about 😅), so it’s now time for real devs to show how this will affect their operations in a more granular way. Let’s empower the data, let’s show how governance can be done analyzing facts.

So, it's happening: Slot time is going lower. But what that means? - Reducing slot time from 400 to 200 ms halves the four-slot leader window from 1.6 s to 800 ms, limiting how long a single execution regime can persist - Shorter slots reduce modeled stale-price arbitrage against external reference markets, with the effect increasing for wider fee bands and lower short-horizon volatility. Current snapshot of arbitrage indicates intensive on-chain routing; arbitrage will likely remain unchanged after slot time reduction - Sandwich MEV is not sign-definite: shorter reaction windows reduce attack feasibility, while lower intra-slot contention can leave more residual slippage available to fast attackers - More frequent leader opportunities reduce validator block-reward variance, with a larger reduction in downside uncertainty than in the long-tail upside - At 200 ms, validators vote roughly twice as often per unit of wall-clock time; expected vote-fee recapture thresholds remain similar, but smaller validators face larger absolute voting costs - Current vote timing and leader-handoff distributions leave limited latency headroom at 200 ms, so the impact on TVCs and consensus performance remains an empirical mainnet question Below the relevant charts. Read the full report at

I think these are the 3 relevant charts one should keep in mind when looking at larger txs size and v1 format 👇 The first shows serialized size composition of transactions (v0 and legacy), the second shows their counterfactual v1 serialized size. What I think is super interesting is that, despite the removals of Account Lookup Tables, a 3.3x on txs size is not saturated by format conversion. A counterfactual v1 serialized size has a long right-tail of txs that roughly double in size. Txs with > 1440 bytes are mostly due to txs dense in ALT usage (predominant component is from ALT removals in this range). Tho, this is a small payment in terms of size given what v1 allows. - Validators and client teams: v1 exposes fee and resource requests directly in transaction metadata, enabling earlier prioritization and more efficient block construction, with the potential for better fee capture; it also removes state-dependent ALT resolution from ingestion - Application developers: the 4,096-byte envelope enables richer atomic transactions, but the unchanged 64-account limit can still constrain account-heavy applications - Traders, routers, and searchers: larger transactions can support more complex atomic routes, although dense ALT users consume more of the new byte budget when addresses are inlined - Privacy, multisig, and cryptographic applications: larger payloads create substantially more room for proofs, signatures, and other data-heavy constructions without increasing compute or account limits. The last chart shows remaining v1 account slots, decomposed by top-level instruction headroom. Thus, it's clear that under v1 txs will be limited by accounts limit (which is going to be increased You are not ready for what v1 format + increase in account lock limit is bringing on chain. Read the full article here:

I'm joining @SolanaFndn . Over the years, I’ve had the chance to work across different ecosystems and study most major PoS networks closely. But only one truly kept pulling me back: Solana. It’s been a 4+ year journey of comings and goings, and now it finally feels like the right time to go all in. This wouldn’t have been possible without the freedom and trust I was given at @ChorusOne. I’m incredibly grateful for the opportunity I have had to learn, build, and grow alongside some of the brightest people in crypto. I still remember my interviews with @FelixLts, @0xave, and @crainbf. I knew almost nothing about blockchains back then, yet they saw something in me and took a chance on me. I’ll always be grateful for that. I’m also thankful to @KamBenbrik, @hongkim__, and @HHorsley for giving me the freedom to focus deeply on Solana research over the last period. My time with @Bitwise was brief, but I’m convinced the team they’re building is exceptional, and I’m excited to see what comes next for them. Now, joining Solana Foundation feels like the natural next step — a chance to go all-in and help push the ecosystem forward. I’m incredibly excited for this new chapter, for the challenges ahead, and to have finally found a place I can truly call home.