1/ SIMD-0266: Efficient Token Program, authored by @0x_febo, propose replacing the current SPL token program with a new compute optimized version called p-token. The upgrade will reduce Token program CU usage by up to 98%. Here’s how it works 🧵
2/ Today, ~10% of block compute units are spent on Token program instructions. By cutting these costs to a fraction of current usage, p-token will free nearly 12% of block space for other transactions, directly increasing Solana’s effective throughput.
3/ p-token is a complete reimplementation of SPL Token: no heap allocations, zero-copy data access, and full backward compatibility. Clients don’t need to change any code and it is a direct drop in replacement designed for maximum efficiency.
4/ New instructions like Batch and UnwrapLamports further reduce compute for common DeFi patterns, allowing multiple token ops per CPI and removing the need for temporary native accounts. Programs can now execute complex flows far more efficiently.
5/ These optimizations make p-token a direct capacity unlock for the network, complementing efforts like 100M CU blocks and higher per-account limits. Neodyme's audit replayed mainnet transactions and confirmed identical outputs with the current SPL token program.
1/ Rotor is Solana’s new block propagation protocol introduced in the Alpenglow upgrade. It’s a single layer of relayers that replaces Turbine’s multi-hop, delivering blocks faster and more uniformly across the network 🧵
2/ How does Rotor work? The leader pipelines a block into slices, erasure-codes each slice into shreds, then sends each shred to a selected relayer. Relayers broadcast their shred to all validators globally in a single round.
3/ Due to erasure coding, a given slice can be reconstructed as soon as half of the shreds are received. This ensures resilience and allows the relayers to start forwarding the data as soon as they receive just one packet.
1/ Introducing the largest Solana Protocol change ever: Alpenglow, Solana's new consensus protocol conceived by the Anza Research team. Say goodbye to Tower BFT and Proof of History. Say hello to Votor & Rotor 🧵👇
2/ Transaction final latency is coming down to 100-150ms (100x reduction), competitive with centralized infrastructure and enabling real time applications
3/ Votor finalizes blocks in a single round of voting if 80% stake is participating, and it finalizes in two rounds of voting if 60% of stake is responsive. Rotor is flattening the turbine tree to reduce network latency. Higher fanout, fewer layers, lower latency
2/ Founded by Professor Roger Wattenhoffer (@TheWattenhofer) and two of his PhD students @DiscoKobi and @qkniep from ETH Zurich in Switzerland, Anza Research will work on fundamental aspects of the protocol to bring Solana to the next level.
3/ This includes designing a more performant and provably correct turbine-based consensus algorithm, as well as researching improvements to latency, resilience, and economics. Bringing a deeply academic and research lens will allow them to improve Solana in previously unexplored ways.
1/ Timelines and what to expect around what @anza_xyz is doing to address the current network congestion on @Solana in our validator client implementation, Agave.
The short version is: significant progress has been made to overcome the current congestion challenges, and we expect to begin releasing fixes next week. In collaboration with other core contributors, we have analyzed the root cause, and evaluated several potential changes.
2/ Having said that, today the Anza team will be testing a patch to address current network congestion. If successful, this patch will be readied for wider rollout.
3/ The core issue relates to a QUIC implementation, and the behavior of the Agave validator client on @solana when asked to process a large number of requests. Anza engineers, with other core contributors, have been working around the clock to diagnose and remedy bottlenecks and increase network performance. Expect more improvements and changes to roll out over the coming months.
1/ Here is a preview of the upcoming Agave v1.18 that will be released to mainnet in the next few weeks. It’s an incremental release that paves the way for Agave v2+. While not a silver bullet for current congestion issues, @anza_xyz devs and other core contributors are heads down working to resolve the issues impacting network usability. We’re on it.
2/ A highlight of Agave v1.18 is the addition of The Central Scheduler, which is disabled by default but can be enabled by including the “--block-production-method central-scheduler” flag.
3/ The Central Scheduler adds a new thread to the TPU (bringing the total to 7) dedicated to minimizing conflicting transactions by routing and ordering incoming tx to worker threads to minimize conflicts and improve block packing. In future releases, the Central Scheduler will be the default scheduler. For now, it is in early evaluation for those who want to try it.