Constellation: Dismantling the Leader Monopoly

Yesterday, Anza, the core client developer behind Solana, unveiled Constellation. The one-line summary is "multiple proposers submit transactions simultaneously to ensure fairness," but the scope of what that single line touches spans block production architecture, fee economics, censorship resistance mechanisms, and the MEV market structure as a whole.

Here is a detailed look at what changes, based on the whitepaper and the published spec.

1. Constellation's Architecture

1.1 The Problem with the Current Design

Solana's block production today operates as a single-leader monopoly. Each slot (roughly 400ms), one validator is designated as leader according to a predetermined schedule and given full discretion over which transactions to include and in what order to arrange them. This structure allows the leader to extract value in three ways.

• Selective censorship: Deliberately excluding certain transactions while inserting ones favorable to themselves

• Sandwich attacks: Placing their own trades immediately before and after a user's transaction to exploit the resulting price difference

• Side deals: Collecting fees through off-protocol channels such as Jito bundle auctions, bypassing the protocol's fee burn mechanism

Constellation aims to dismantle the root cause of these problems at the protocol level: the fact that a single party holds simultaneous monopoly over both inclusion and ordering.

1.2 The New Pipeline and Censorship Resistance

In today's Solana, a single leader handles transaction collection, ordering, and block assembly all at once. Constellation explicitly separates this process into three distinct roles.

Source: Anza

• Proposers: Proposers collect user transactions and, every 50ms cycle, convert them into erasure-coded fragments (pshreds) for distribution to attester nodes. The key difference is that there are multiple proposers. Under the current spec, 16 proposers operate simultaneously, and users can send their transactions to more than one.

• Attesters: Attesters serve as watchdogs over the leader. A set of 256 attester nodes timestamps the pshreds received from each proposer, relays them to the leader, and issues attestations confirming receipt. Even if the leader tries to ignore a particular proposer's data, when enough attesters have confirmed and attested to its existence, the leader has no choice but to include it.

• Leader: The leader still assembles the final block, but with significantly reduced authority. Transactions that have received sufficient attestations must be included, and transaction ordering is deterministically decided by priority fees. The leader effectively has no discretion to rearrange the order.

In short, the old model where the leader decided everything has been restructured into a separation of powers among proposers, attesters, and the leader.

The way this structure prevents censorship relies on erasure coding. When a proposer submits transactions, it does not send the raw data directly. Instead, it generates fragments using Reed-Solomon erasure coding, the same technique used in Solana's existing block propagation system Turbine, and distributes them to attesters. Three thresholds are built on top of this property.

• Assembling a batch requires attestations from 50% of all attesters (128 out of 256). If this condition is not met, the batch is not produced.

• If 25% or more of attesters (64 out of 256) have received a particular proposer's pshreds, that proposer's data must be included.

• Reconstructing the original data likewise requires only 25% of the pshreds (64).

For a leader to censor a specific proposer's data, fewer than 64 out of 256 attesters would need to have received that proposer's pshreds. But preventing erasure-coded data from reaching even 64 out of 256 attesters would require physically controlling a significant portion of the network or bribing a large number of attesters, which is economically unrealistic.

Conversely, if overall attester participation falls below 50%, no batch is produced at all. The leader's only option is not selective censorship of individual transactions, but the self-defeating choice of forfeiting the batch entirely. The design raises the cost of censorship dramatically.

Proposer misconduct is also addressed. Signing pshreds with different commitment hashes or pslice roots for the same pslice index in the same cycle (equivocation) constitutes misconduct, as does malformed erasure coding that causes decoding to fail. In such cases, the leader includes a fault witness in the block and can legitimately exclude that proposer's data.

1.3 Redesigning the Fee Structure

Constellation redefines the existing fee system into two layers.

• Inclusion Fee: Calculated based on the transaction's size and number of signatures, paid directly to the proposer that included the transaction. This corresponds to the current base fee.

• Ordering Fee: Calculated as compute unit (CU) limit × bid price, serving as the criterion for ordering transactions when merging blocks from multiple proposers. This corresponds to the current priority fee.

The most interesting design decision here is that the ordering fee does not go to the leader. Instead, it is distributed across the entire validator set proportionally to stake weight, smoothed over epoch-length intervals.

The intent behind this is clear. If ordering fees went directly to the leader, the leader could assign high fees to their own transactions and effectively maintain ordering authority at no real cost. Constellation eliminates this incentive at the source by distributing fees across all validators.

The practical effect on validator economics is revenue equalization. Under the current structure, validators only earn priority fees during the slots where they are selected as leader, creating significant income variance depending on whether a validator happens to be assigned MEV-rich slots. Under Constellation, ordering fees are distributed by stake weight, so over time revenue converges regardless of the MEV density of any particular slot.

A new concept called Fee Payer Reserve is also introduced. In a multi-proposer environment, the same user's transaction can reach multiple proposers at once, creating the risk of duplicate fee charges. The fee payer reserve is a balance reservation mechanism that guarantees the ability to pay inclusion fees while preventing duplicate processing across proposers.

1.4 Execution Schedule and Timing

After transactions are included, a question remains: in what order and how should they be executed?

Included transactions are sorted by priority fee per CU and then placed into 4 parallel execution lanes. In the selection process described by Algorithm 6 in the whitepaper, each transaction is assigned based on account-level conflicts and the remaining capacity of each lane. The purpose of this schedule is to maintain predictability in block replay time. The CU limit per batch is approximately 2 million CU, and distributing this across 4 lanes yields roughly 2 million CU of sequential execution capacity per lane. If a transaction has a tx.expire tag set and lacks fee competitiveness in its current cycle, it is retried in subsequent cycles and discarded if it remains unexecuted by the cycle specified in tx.expire. Transactions without tx.expire attempt execution only in the first valid cycle.

This entire process runs on a 50ms cycle. Anza claims this is the fastest protocol-enforced economic tick of any existing blockchain. Each cycle completes one full round of "propose → attest → assemble batch," and a single slot (roughly 400ms) contains multiple such cycles. The combined batches from all cycles form the leader's final block payload.

This design was built with integration into Solana's next-generation consensus protocol, Alpenglow, as a given. Constellation is designed as a preprocessor for Alpenglow, and Anza is targeting mainnet deployment of Alpenglow for Q3 2026, with the first version of Constellation to follow shortly after.

2. Implications and Open Questions

2.1 How This Differs from Ethereum's Approach

Ethereum has addressed MEV through PBS (Proposer-Builder Separation): an auction model that separates block construction from block proposal, where specialized builders assemble MEV-optimized blocks and purchase the right to inclusion from proposers. Currently, this architecture is implemented outside the protocol through Flashbots' MEV-Boost, and the vast majority of the network uses it.

The philosophy of PBS is to redistribute MEV. Rather than eliminating MEV itself, the approach returns its revenue to proposers and improves efficiency through competition among builders.

Constellation differs from this in several ways. Instead of redistributing MEV, it targets the structural conditions that make MEV possible: the monopoly over ordering held by a single party. Multiple proposers submit transactions simultaneously, ordering is determined deterministically by fees, and blocks from leaders who fail to follow these rules are rejected. This leaves the leader with substantially less room to extract MEV through order manipulation.

Furthermore, while Ethereum's effort to enshrine PBS within the protocol remains a work in progress, Constellation was designed as a protocol-native feature from the start. If successfully implemented, Solana could become the first blockchain to integrate multiple simultaneous proposers and censorship resistance directly into its block production layer.

That said, the two approaches carry different tradeoffs. PBS maximizes the economic efficiency of blocks through builder competition, while Constellation focuses on fairness and censorship resistance at the expense of some economic optimization flexibility. Whether Constellation's deterministic ordering (based on priority fees) might constrain the flexibility needed for complex DeFi strategies is a question that remains empirically untested.

2.2 Dependence on Synchronized Clocks

Constellation's 50ms cycle requires time synchronization among network participants. For attesters to timestamp pshreds and for the leader to assemble batches on a per-cycle basis, clock drift between participating nodes must be small relative to the cycle length.

This raises two natural questions.

Solana originally used Proof-of-History to verify temporal ordering, but Alpenglow replaces this with a fixed 400ms block time. One might ask whether synchronization errors on the order of tens of milliseconds within a 50ms cycle could undermine the consistency of attester timestamps and affect inclusion threshold decisions.

Physical network latency is another variable. Solana validators are distributed globally, and intercontinental fiber optic latency alone can amount to tens of milliseconds. The requirement that "propose → attester receipt → leader relay" all complete within a 50ms cycle invites the concern that geographically disadvantaged nodes could face systematic penalties.

However, Constellation was designed with these concerns in mind, and the whitepaper shows that multiple layers of tolerance are built into the design.

First, the attestation window is not a single 50ms cycle. Each attestation covers the most recent λ = 6 cycles' worth of pslices, roughly 300ms. A pslice produced within a given cycle does not need to reach attesters within that same 50ms window; it has up to approximately 300ms of leeway.

Second, clock skew is explicitly accounted for in the design. The range of pslice indices that attesters will accept is widened by a configurable parameter (Δ_skew), so even if a proposer's and an attester's clocks differ by tens of milliseconds, the pslice can still fall within the valid range.

The whitepaper states explicitly that protocol performance depends on actual message delay δ, not on worst-case assumptions. While intercontinental fiber optic latency can reach 50 to 80ms, delays of this magnitude fit comfortably within the 300ms attestation window and the skew correction range. The situation is not one where nodes are racing against a hard 50ms deadline.

The whitepaper also references specific, widely used practical time sources: GPS receivers, chrony, Google TrueTime, and Amazon Time Sync Service. In data center and financial infrastructure environments, sub-millisecond accuracy is routinely achieved with these tools, and Solana validators already operate in such environments.

None of this means clock synchronization is a non-issue. If a significant portion of the validator set relies on low-quality time sources, or if the Δ_skew parameter is set too aggressively, there remains the possibility that proposals from geographically disadvantaged nodes could be attested less reliably. But the failure mode is closer to "if clocks drift, some proposals get included one cycle late" than "if clocks drift, the system breaks." How much this matters in practice, particularly for latency-sensitive DeFi activity, is something that will need to be validated in a live environment.

2.3 The Relationship with Jito

The whitepaper does not mention Jito directly. But how Constellation's design relates to Jito's bundle auctions, block engine, and the recently introduced BAM (Block Assembly Marketplace), all of which form the core infrastructure of Solana's MEV ecosystem, is an unavoidable question.

To start with what is clear: the leader's discretion over ordering is effectively eliminated. Under Constellation, transaction ordering is determined deterministically by priority fees, CU limits, and hash values. If a leader rearranges this order, the block itself becomes invalid. The current model, where searchers pay tips to the leader in exchange for guaranteed positioning, simply does not work in this structure.

This does not mean, however, that MEV infrastructure disappears entirely. The point worth watching is the proposer's discretion over inclusion. The whitepaper states explicitly that proposers are "completely free" to decide which valid transactions to accept and which to reject. Where the leader's monopoly once stood, the distributed inclusion authority of 16 proposers now takes its place.

The fee structure also deserves close attention in this context. Constellation splits fees into two layers: inclusion fees are paid directly to the proposer that included the transaction, while priority fees are distributed across all validators proportionally to stake. The fact that inclusion fees accrue directly to proposers leaves an economic foundation on which a new market for premium inclusion services could form at the proposer level.

Layered on top of this is the design allowing users to specify a target proposer bitmap on their transactions. Users can choose which proposers receive their transactions, making strategic relationships with specific proposers structurally possible. This suggests that the existing leader-searcher relationship could shift its axis toward a proposer-searcher relationship.

The fate of bundles is not straightforward. Because ordering is determined by fees, guarantees of the form "place my transaction right after this one" become impossible. But in an environment where multiple proposers are active simultaneously and the contents of any given cycle are difficult to predict, the difficulty of executing sandwich attacks rises substantially. It is not theoretically impossible for an attacker to observe a target's fee and adjust their own to achieve the desired relative position, but predicting the composition of the final batch in a multi-proposer environment is considerably harder. Rather than saying bundles disappear, it is more accurate to say the conditions under which bundles can operate, and their profitability, change fundamentally.

The question Constellation ultimately poses is not "does Jito survive," but rather "as the center of gravity of MEV infrastructure shifts from the leader to proposers, what form does Jito's role take?" If dismantling the leader's monopoly does not eliminate MEV entirely but instead narrows the extractable surface and raises its cost, what new competitive dynamics emerge within that narrower space is something that will need to play out in practice.