Constellation

Main Paper

WPRC SG [35] Constellation — Rongxin (WPRC) — 28 May 2026

Solana Constellation is a multiple concurrent proposers (MCP) protocol designed for Solana's Alpenglow consensus layer. It replaces the single-leader monopoly over transaction inclusion with ~16 simultaneous proposers, ~256 attesters operating on synchronized UTC clocks, and a highly constrained leader — achieving protocol-enforced selective censorship resistance at a 50 ms economic tick, claimed as the fastest among production blockchain protocols. Rather than accepting and redistributing MEV as Proposer-Builder Separation does, Constellation structurally removes the leader's ability to exploit users by making attestations into enforceable constraints on block content.

Current blockchains satisfy safety and liveness yet still allow designated leaders to front-run, reorder, and selectively censor transactions — extracting MEV at users' expense. The industry's dominant response (PBS) optimizes MEV redistribution among validators without reducing harm to users. Constellation takes the opposite approach: it transforms the leader from an unconstrained monopolist into a constrained assembler whose block content is dictated by cryptographic attestations from a decentralized attester layer. If this design works at scale, it establishes Solana as a structurally fair venue for global financial markets — enforcing ordering fairness through protocol design rather than reactive regulation, and potentially rendering entire categories of MEV extraction economically infeasible.

• Core problem: Single-leader block production grants a temporary monopoly over transaction inclusion and ordering, enabling front-running, censorship, and MEV extraction. Honest validators are economically disadvantaged, incentivizing a race to the bottom.
• Multiple Concurrent Proposers (MCP): ~16 simultaneous proposers submit transactions to ~256 attesters who enforce timely inclusion; the leader cannot unilaterally decide what enters a block.
• 50 ms economic ticks: UTC wall-clock time partitions time into strict 50 ms cycles, decoupling transaction inclusion intervals from global consensus delays — the fastest protocol-enforced censorship-resistant tick among production blockchains.
• Constrained leadership: The leader must include any pslice reaching the attestation threshold (γp = 64) or provide a cryptographic fault witness proving proposer misbehavior. Three block validity conditions make this directly verifiable by all validators.
• Selective censorship resistance: Correctly proposed, fee-competitive transactions must be included within λ ≈ 6 cycles (~300 ms) unless no batches are produced at all — a bounded, conditional guarantee.
• Two-tiered fee model with reserve: Transactions pay per-proposer inclusion fees and a one-time priority fee (bid × CU). A mandatory reserve balance (ϕ ≈ 0.001 SOL) prevents fee-payer abuse across concurrent proposers.
• Deterministic parallel scheduling: Transactions are sorted by bid, CU limit, and hash tiebreaker, then greedily assigned to m ≈ 4 parallel execution lanes respecting account conflicts — deterministic but acknowledged as sub-optimal (optimal packing is NP-complete).
• Stronger assumptions: Beyond Alpenglow's partial synchrony model, Constellation requires reasonably accurate UTC clocks across nodes — a meaningful additional dependency.

The MEV Problem and Constellation's Philosophical Stance

The paper's starting point is that a blockchain can satisfy classical consensus properties — safety and liveness — while still producing an abusive market structure for users. In existing single-leader designs, the designated leader at any given moment holds a temporary monopoly: they can observe pending transactions, reorder them, censor selectively, and insert their own transactions to front-run others. This monopoly becomes economically valuable as on-chain activity grows, creating Maximal Extractable Value (MEV). Worse, it creates a race to the bottom where honest validators are economically disadvantaged, incentivizing everyone to exploit users.

The industry's standard response, Proposer-Builder Separation (PBS), accepts MEV as inevitable and merely optimizes its distribution among network participants. Constellation takes the opposite approach: it aims to structurally remove the leader's ability to exploit their position, so that MEV extraction becomes infeasible by design rather than redistributed after the fact. This is analogous to how traditional financial markets enforce fair ordering through regulation — but Constellation does it cryptographically rather than relying on reactive, jurisdiction-dependent oversight.

Architecture: Roles, Timing, and the Data Flow

Constellation introduces two new roles on top of Alpenglow's existing validator/relay/leader structure, all selected randomly by stake:

• Users send signed transactions to one or more of ~16 concurrent Proposers, each transaction specifying target proposers via a bitmap, a compute-unit limit (cu), and a priority fee (bid).
• Proposers collect transactions and, up to μ ≈ 4 times per 50 ms cycle, erasure-code them into pshreds (256 pieces, 64 needed to reconstruct) and distribute one pshred per attester.
• Attesters (~256) immediately forward received pshreds to the next κ ≈ 2 leaders, then at cycle end produce a signed attestation listing all proposer commitment hashes they observed over the last λ ≈ 6 cycles.
• The Leader waits for α = 128 attestations (half the attesters), reconstructs any pslice that appears in at least γp = 64 attestations, and assembles a batch per cycle. Multiple batches form a block's payload, disseminated via Alpenglow's Rotor protocol.
• Validators (~1,000) verify that the leader included all newly attested pslices (or valid fault witnesses for misbehaving proposers), execute transactions, and vote through Alpenglow's Votor.

The critical design choice is UTC wall-clock time. Unlike Alpenglow's purely logical time, Constellation partitions real time into strict 50 ms cycles (computed by dividing nanosecond Unix timestamps by 50,000,000). This decouples the economic tick — the interval at which transactions can be included — from global consensus delay. Proposers and attesters operate on this rapid real-time schedule, while the consensus layer (slots, blocks, finalization) runs on its own dynamic schedule driven by ParentReady events. Available time sources include GPS receivers, chrony, Google TrueTime, and Amazon Time Sync.

Roles rotate gradually: one proposer slot and one attester slot are replaced every τ ≈ 32 cycles via stake-weighted randomness. When a proposer index transitions, the schedule inserts a λ-cycle gap to ensure that each attestation list unambiguously corresponds to a single proposer.

Attestation-Enforced Inclusion and the Constrained Leader

The core mechanism preventing leader abuse is the attestation system. Each attestation contains, for each of the p proposer indices, a list of (c', t, h) tuples representing observed pslice commitments over a sliding ∆-window. Attesters serve a dual role: forwarding pshreds for data availability and signing attestations for accountability. They send to multiple future leaders (κ = 2) for resilience against leader failure.

The leader's discretion is sharply constrained by three block validity conditions:

1. Submission completeness: For each newly attested tuple, there must be exactly one submission with matching commitment hash h, and no extra submissions.
2. Omissions require proof: If attestation data for a proposer is replaced with a hash (omitting their transactions), the block's garbage pile must contain a valid fault witness — either two incompatible pshreds from the same proposer, or γp pshreds that fail to decode.
3. Cycle monotonicity: Batch cycle indices must be consecutive within a block and strictly increasing across the chain.

Two distinct commitments serve complementary purposes: the transaction-list hash h(T) constrains the leader (fixing what must be included if attested), while the Merkle root rt protects the leader (enabling provable detection of proposer misbehavior when erasure decoding fails). These conditions create a strong invariant: the leader cannot silently discard correctly attested data, nor invent content not backed by attestations.

Transaction Economics, Fee Payer Reserve, and Deterministic Scheduling

Constellation is not transaction-agnostic. Each transaction carries a compute-unit limit (cu), a priority bid (fee per CU), a nonce (bankhash) for deduplication, an inclusion fee, a target proposer bitmap, and an optional expire tag. Users sending to k proposers pay the inclusion fee k times but the execution fee (cu × bid) only once. The expire mechanism provides a built-in distinction between time-critical trades (immediate-or-nothing, no expire tag) and best-effort transactions (retry until expiry or execution).

A subtle problem arises from concurrent proposers: without global state visibility, proposers cannot verify whether a fee payer's account has already been drained at other proposers. The solution is a mandatory reserve balance (ϕ ≈ 0.001 SOL) that guarantees inclusion fees remain collectible, giving proposers a safe local admission rule. Additional enforcement: proposers reject transactions when the observed reserve is compromised; per-account inclusion fees are rate-limited; inclusion fees are always charged while priority fees are charged only if the reserve remains intact; execution fails if it would drain below the reserve.

Transaction selection is fully deterministic — essential because all validators must agree on exactly which transactions execute. Transactions are sorted by (1) higher priority bid, (2) smaller compute-unit limit, (3) hash tiebreaker, then greedily scheduled across m ≈ 4 parallel execution lanes respecting account conflicts. The paper openly acknowledges that optimal packing is NP-complete, but determinism matters more than optimality.

Security Model and Censorship Resistance Guarantees

Constellation inherits Alpenglow's security bounds: <20% byzantine stake, up to an additional 20% crashed, with the remainder correct. The protocol operates in the GST/partial synchrony model: safety holds always, while liveness requires periods of synchrony after GST.

The central new property is selective censorship resistance: if a correct proposer submits a transaction in cycle c, it will be included by cycle c+λ unless no batches are produced in that interval. Fee-competitiveness is defined at two levels — strong (among the highest bids fitting within the batch compute budget) and weak (survives the full deterministic selection algorithm including parallel scheduling and account conflicts) — and the selection algorithm guarantees strong implies weak. The fairness promise is not "every valid transaction is included" but rather: correctly proposed and sufficiently competitive transactions cannot be selectively excluded by the leader.

Cryptographic Machinery & Parameters

Constellation uses standard primitives: collision-resistant hashes (SHA-256), digital signatures, (Γp, γp) Reed-Solomon erasure coding, and Merkle trees. The decode procedure reconstructs a message, re-encodes, recomputes the Merkle root, and returns success only if it matches — if roots don't match, the failed pshreds become a fault witness. The erasure-coding and Merkle machinery thus serves dual purposes: data availability/resilience and fault attribution.

Relationship to Alpenglow

Constellation is not a standalone chain design; it sits atop Alpenglow, Solana's next-generation consensus protocol, which provides base consensus safety/liveness, leader scheduling, data dissemination via Rotor, voting via Votor, and the slot/epoch structure. Constellation modifies the payload-construction pipeline: proposers, attesters, and constrained leaders replace the single-leader mempool-to-block mapping. It should be understood as an economic fairness and transaction origination layer integrated into Solana's consensus, not a replacement for the consensus core itself.

1. Clock synchronization robustness: How robust is UTC synchronization under adversarial conditions? Clock skew tolerance is acknowledged but not deeply analyzed — a meaningful new dependency not present in purely logical-time protocols.
2. MEV migration: Does MEV simply migrate to proposers, wallets, or orderflow routing rather than disappearing? The selectTransactions() logic at proposers is left unspecified.
3. Attester incentives and penalties: Beyond stake-weighted selection, what are the specific incentive structures and slashing conditions for attesters?
4. Scalability of attestation overhead: How does the ~29 KiB attestation overhead per batch scale under heavy load, and what are the practical limits of cross-batch deduplication?
5. Parameter sensitivity: How sensitive are the censorship-resistance and performance properties to real-world variance in latency, validator count, and account contention?
6. Execution scheduling optimality: Given the NP-completeness acknowledgment, how much throughput is left on the table by the greedy scheduling algorithm under realistic workloads?

Thank you to Superteam SG for hosting us and offering us their amazing space! Please connect with us on Twitter and LinkedIn and check out all the summaries on the website: wprc.club. If you have suggestions on future topics, please let us know. We have chapters right now in Singapore, Kuala Lumpur, Taipei, Hong Kong, Bangkok, New York, San Francisco, and Lagos.