Breakpoint 2025: Anza Block: Max Resnick

The single-leader problem has long been a thorn in Solana's side. Now, after a year of intense research and multiple iterations, Anza researcher Max Resnick has unveiled Supernova Part One—a protocol upgrade that finally delivers on the promise of multiple concurrent proposers (MCP) and true censorship resistance.

Summary

Top Projects

Lulo

Score: 7,586.13

Bonk

Score: 4,806.12

Sphere

Score: 2,544.42

Moonwalk

Score: 2,026.11

At Breakpoint 2025, Max Resnick presented what he called the "final, final, final" version of MCP—a protocol enhancement that addresses one of Solana's most pressing concerns: the ability of single leaders to selectively censor transactions. This isn't just theoretical; Resnick revealed that late packing and other forms of transaction manipulation are already occurring on Solana's mainnet.

The core innovation of Supernova Part One is deceptively simple: instead of one leader controlling which transactions make it into a block, multiple proposers now submit transactions simultaneously. These proposals are then aggregated by a consensus leader, with relay nodes attesting to which shreds (data fragments) they've received. This creates a system where either your transaction gets included, or nobody's does—eliminating selective censorship entirely.

Resnick explained that Solana's trading-centric design, dating back to the Serum days, makes this upgrade particularly crucial. Modern prop AMMs (proprietary automated market makers) rely on fair oracle updates and timely execution. When leaders can delay or block oracle updates, it creates market inefficiencies and unfair advantages. The new protocol aims to level the playing field while maintaining Solana's famous speed.

The presentation also touched on future goals, including "pre-trade privacy"—the ability to hide transaction contents from leaders until after consensus is achieved. This would prevent front-running and other predatory behaviors that plague decentralized exchanges.

Key Points

The Problem with Single Leaders

Solana's current architecture gives block leaders significant power over transaction ordering and inclusion. Because leaders can co-locate their trading operations with their validator, they can insert transactions at the last moment while potentially blocking or delaying others. Resnick pointed to real-world evidence of this happening: oracles not getting their updates included due to late packing or other manipulative behaviors.

This creates an asymmetric information advantage. In auction theory terms, the leader who acts later sees more price data and can exploit this knowledge. If prices rise, they get outbid by faster traders; if prices fall, they've overbid. This causes "unraveling" in financial markets—a phenomenon where the efficiency of price discovery breaks down because participants can't trust the fairness of the system.

Supernova Part One Architecture

The new protocol introduces several key components. Clients now send transactions to multiple proposers rather than a single leader. These proposers create their own blocks of transactions and forward shreds to relay nodes (turbine routes), which immediately broadcast them to validators—maintaining Solana's existing fast propagation model.

The critical addition is that relays also send "attestation messages" to a consensus leader, certifying which shreds they've received. The consensus leader aggregates these attestations into a matrix and broadcasts the aggregate block. Validators then apply specific validation rules: at least 60% of relays must have attested, blocks need 40% of valid shreds present to be scheduled for inclusion, and 20% of shreds allows full block reconstruction.

This architecture preserves Solana's erasure coding advantages while distributing proposal power across multiple participants.

The Evolution of MCP Designs

Resnick provided valuable context on why this specific design was chosen over alternatives explored throughout the year. Alpenglow, the current protocol, is mathematically optimal for bandwidth and latency but lacks censorship resistance. Multiplicity, proposed years ago, still gave leaders too much power. Braid, which treated each thread as separate consensus, suffered from performance issues since chains would proceed at the pace of the slowest participant.

A simpler approach of voting on aggregated blocks multiplied failure rates unacceptably. GNR, presented at a previous event in Chicago, had liveness issues and performance problems. Supernova Part One represents the refined solution that addresses all these concerns while remaining practical to implement.

Future Goals: Pre-Trade Privacy

Beyond censorship resistance, the team is targeting "hiding" as a future property—formally defined in the presentation as ensuring adversaries cannot guess what's in an honest leader's block before the protocol reaches "valency" (a form of pre-finality). This pre-trade privacy would enable traders to use mixed strategies, reducing the distortion caused by information asymmetry.

The less time advantage a leader has over other participants, the smaller the market distortion. This creates a direct incentive alignment between protocol improvements and trading efficiency.

Facts + Figures

• Solana has been fundamentally designed for trading since day one, starting with Serum and evolving to modern prop AMMs

• Late packing and oracle censorship issues are currently occurring on Solana mainnet—not just theoretical attacks

• The new protocol requires attestations from at least 60% of relay nodes for block validation

• Blocks need 40% of valid shreds present in the aggregation to be scheduled for inclusion

• Only 20% of shreds are required to reconstruct a complete block using erasure coding

• Multiple design iterations were explored including Alpenglow, Multiplicity, Braid, and GNR before arriving at Supernova Part One

• The protocol maintains Solana's existing turbine routing and erasure coding infrastructure

• Transactions from multiple proposers are ordered by priority fee and deduplicated during execution

• Additional fee payer checks are implemented to prevent denial-of-service attacks

Top quotes

• "Solana is fundamentally for trading and about trading, and it has been from day one."

• "What happens when that leader decides they want to be the only person who's allowed to submit new information to the chain? In the current protocol, they actually can do that."

• "This is kind of transformed from not necessarily a theoretical attack to something that's going on right now on Mainnet with late packing."

• "When you submit a transaction to the chain, either you should get in or nobody should get in. That's fairness."

• "We ended the leader monopoly."

• "We're collecting the receipts of everybody who says we're not going to be able to ship this thing quickly, and I will be posting them on Twitter."

• "The less time advantage you get... the less distortion there is in this mixed strategy model."

Questions Answered

Why does Solana need multiple block proposers?

Currently, Solana's single-leader model gives one validator complete control over which transactions get included in their block. This creates opportunities for censorship, where leaders can block competitors' transactions—particularly oracle updates—to gain trading advantages. Real evidence of this happening through late packing has already been observed on mainnet. Multiple proposers eliminate this centralized control, ensuring that if any honest proposer includes your transaction, it will make it into the chain.

How does the new Supernova protocol prevent censorship?

The protocol distributes transaction submission across multiple proposers who simultaneously create blocks. Relay nodes receive these blocks and send attestation messages to a consensus leader, confirming which data they've seen. The consensus leader aggregates these attestations, and validators only accept blocks where at least 60% of relays have attested. This means no single party can selectively exclude transactions—either everyone's submissions get through or the block fails validation entirely.

What is pre-trade privacy and why does it matter for traders?

Pre-trade privacy, also called "hiding," prevents adversaries from seeing what transactions are in a block before consensus is achieved. This is crucial because knowing upcoming transactions allows front-running and other predatory strategies. When leaders can see transactions before others, they gain unfair information advantages. The protocol aims to level this playing field, allowing traders to employ optimal strategies without being exploited by better-positioned participants.

How does this affect Solana's performance and speed?

The design specifically preserves Solana's existing high-performance infrastructure, including turbine routing and erasure coding. The flow remains similar to current Alpenglow: transactions go to proposers, shreds go to relays, relays broadcast to validators. The main addition is the attestation step, which runs in parallel with existing propagation. Previous design iterations that significantly impacted latency or bandwidth were rejected in favor of this more efficient approach.

When will Supernova Part One be available?

While Resnick didn't announce a specific launch date, he emphasized that the team is focused on shipping quickly. The presentation concluded with a playful challenge to skeptics, promising to publicly share criticism from those who doubted the timeline—suggesting the team is confident in near-term delivery. The design has undergone multiple iterations throughout 2024-2025 specifically to ensure it's production-ready.

What happened to previous MCP proposals like Braid?

Several alternative designs were explored and rejected for specific technical reasons. Braid treated each proposer thread as a separate consensus algorithm, but this meant the system would proceed at the pace of the slowest chain—creating unacceptable latency in some scenarios. Multiplicity still gave leaders too much censorship power. GNR had liveness issues. Supernova Part One represents the synthesis of lessons learned from all these approaches, specifically engineered to avoid their shortcomings.