Constellation and the Future of Block Production on Solana: What Validators Need to Know

Anza recently published Constellation, the first formalized proposal for Multiple Concurrent Proposers (MCP) on Solana. It's one of the most consequential protocol design proposals since Alpenglow, and it touches everything from censorship resistance and transaction ordering to MEV market structure and validator economics.

This post is a primer. We're going to explain what Constellation proposes, why it matters, where the debate stands, and what independent validators like Chainflow should be paying attention to. We're not taking a position on MCP vs IBRL yet, that deserves its own treatment once we've had more time with the whitepaper and community discussions. But understanding what's being proposed is step one.

The Problem Constellation Addresses

Today, Solana operates on a single-leader model. Every slot (~400ms), one validator is designated as the leader and given full control over which transactions to include in its block and in what order. This creates a temporary monopoly with three well-documented consequences.

Selective censorship. The leader can deliberately exclude specific transactions - whether for competitive advantage, compliance pressure, or MEV extraction.

Extractive ordering. The leader can reorder transactions to front-run, back-run, or sandwich user trades, capturing value at the user's expense.

Inclusion gatekeeping. The leader decides what gets in and what gets dropped. During congestion, this discretion becomes economically significant.

These aren't theoretical risks. They're structural features of the current design that the ecosystem has been managing through off-protocol mechanisms - Jito's block engine, Harmonic's aggregation layer, BAM, and various policy-based approaches. Constellation proposes to address them at the protocol level.

What Constellation Proposes

Constellation introduces Multiple Concurrent Proposers — a system where multiple validators submit transaction batches simultaneously, rather than one leader controlling the entire slot.

The design separates block production into three distinct roles:

Proposers (16 per slot) collect user transactions and, every 50ms cycle, convert them into erasure-coded fragments (called pshreds) and distribute them to attesters. Each slot is approximately 400ms, meaning there are roughly 8 proposer cycles per slot — censorship resistance therefore kicks in at the sub-slot level, not just once per slot. Users can send transactions to more than one proposer, which means no single proposer can unilaterally censor a transaction.

Attesters (256 per slot) act as watchdogs. They timestamp the pshreds they receive from proposers and issue cryptographic attestations of receipt, signed proofs that create a binding inclusion obligation. These attestations, along with the pshreds themselves, are relayed to the leader. It is the cryptographic attestation, not the relay, that enforces the inclusion guarantee.

The leader still assembles the final block, but with sharply constrained discretion. The leader compiles all transactions that have received sufficient attestations, orders them by priority fee per compute unit, and assigns them to a virtual execution schedule - the ordering layer that sequences transactions for the SVM.

The censorship resistance guarantee works like a quorum requirement. As currently proposed, if 25% or more of attesters (64 out of 256) have received a proposer's pshreds and issued attestations, that data must be included in the block. For a leader to censor a specific proposer, fewer than 64 out of 256 attesters would need to have received and attested to the data - a threshold that's extremely difficult to breach in a well-connected network.

This mechanism uses the same erasure coding technology that already powers Solana's Turbine block propagation. Note that threshold parameters like these are subject to change between proposal and final implementation.

Anza claims this produces the fastest protocol-enforced, censorship-resistant tick rate (50ms) of any blockchain currently in production.

How Fee Economics Change

Under Constellation, validator revenue comes from two sources rather than one.

Inclusion fees are paid directly to the proposers who include transactions. This is new - today, only the leader earns transaction fees.

Priority fees are distributed across all validators by stake weight at epoch end, rather than going entirely to the leader who processes the slot.

The intent is to prevent leaders from capturing disproportionate value from their temporary control over the block. Revenue gets distributed more broadly across the validator set.

Where the Debate Stands

Constellation has been widely celebrated as a major step toward protocol-level censorship resistance. But it's not without significant pushback.

On validator economics: Solana Foundation Head of Ecosystem Engineering Ilan Gitter has suggested that MCP could lead to short-term revenue losses for validators because "their discretion over what goes in gets sharply constrained." Solana co-founder Anatoly Yakovenko has publicly disagreed, arguing there's "no reason" validators would be impacted. The honest answer is probably somewhere in the middle - revenue distribution changes, and some validators will benefit more than others depending on their current revenue composition (MEV-heavy vs. fee-heavy vs. delegation-heavy).

On the perps debate: The timing of Constellation's release coincided with a Solana Foundation essay by Chase Barker on the state of perpetual trading on Solana, arguing that protocol-level improvements are needed for competitive perps infrastructure. Some in the community, notably Temporal co-founder Ben Coverston, argue that Solana's perps underperformance is a demand problem, not a protocol problem, and that projects like BULK and Bullet have already found working solutions through dedicated execution environments. Others counter that these sidecar architectures exist precisely because the L1 can't handle the requirements natively, and MCP is part of the path to making them unnecessary.

On design concerns: Critics have noted that Constellation effectively hard-codes bundle-like structures into the protocol. FluxRPC's Scott Hague has described it as "basically pre-block coordination with witnesses." There are also open questions about potential collusion between proposers and large MEV clients to bypass the censorship resistance guarantees.

On implementation timeline: Constellation is designed as a preprocessor for Alpenglow. Anza is targeting mainnet deployment of Alpenglow for Q3 2026, with the first version of Constellation to follow. Some components, including improvements to transaction ordering and execution flow, may arrive on mainnet earlier, with the full system taking longer to develop and deploy.

What This Means for Independent Validators

For operators like Chainflow, several aspects of Constellation deserve close attention.

Revenue redistribution. The shift from leader-only fee capture to distributed inclusion and priority fees could benefit smaller validators who currently earn less during their leader slots due to lower MEV flow. It could also compress revenue for validators who have optimized their leader slots for maximum MEV extraction. For independent operators, this redistribution may actually be net positive, but the details of the implementation will determine whether that holds.

Reduced leader discretion. Under the current system, validators who run Jito, Harmonic, or BAM benefit from sophisticated block-building strategies during their leader slots. Under Constellation, the leader's role becomes more mechanical by assembling attested transactions rather than constructing optimized blocks. This could reduce the competitive advantage that well-connected, institutionally backed validators currently hold during their leader slots.

Proposer economics. Running a proposer node is a new role that doesn't exist today. The economics of being a proposer - how proposers are selected, how inclusion fees are sized, whether smaller validators can effectively compete as proposers - will significantly affect whether MCP helps or hurts independent operators.

The MCP vs IBRL question. IBRL (Anza's broader performance roadmap) encompasses MCP but also includes other improvements (Alpenglow, block limit increases, p-token optimization) that address different bottlenecks. The community debate about whether MCP is necessary now versus waiting for IBRL's other components to land first is essentially a sequencing question with real economic consequences for validators. Chainflow will follow this debate closely before taking a public position.

Our Perspective, For Now

Chainflow has always evaluated protocol changes through a consistent lens: does this strengthen or weaken decentralization, censorship resistance, and the viability of independent operators?

On those criteria, Constellation's direction is promising. Protocol-enforced censorship resistance is categorically better than policy-based censorship resistance. Distributing fee revenue more broadly across validators reduces the concentration of economic power in leader slots. And reducing the leader's unilateral control over transaction ordering aligns with the decentralization principles that Chainflow was founded on.

But the details matter enormously. How proposer selection works, how fee economics actually play out for smaller operators, whether the 50ms tick introduces latency that advantages co-located validators, and how the transition affects existing block-building infrastructure — these are all open questions that will determine whether Constellation is good for the kind of validators the ecosystem needs most.

We'll continue studying the proposal, engaging with the community discussion, and will share a more detailed position once we've had the time to evaluate the implementation specifics. In the meantime, we encourage every validator and delegator to read the whitepaper and engage with the debate.

This is the kind of protocol decision that shapes Solana's trajectory for years. It deserves careful thought, not hot takes.

Resources:

Want to stake with a validator that takes governance seriously?
Stake SOL with Chainflow

Have thoughts or feedback? Connect with us on X!