Constellation

Constellation is a protocol for Multiple Concurrent Proposers (MCP) on Solana. It achieves the fastest protocol-enforced, censorship-resistant economic tick of any decentralized blockchain in production. Censorship resistance comes from erasure coding, the same technology that powers Solana's Turbine block delivery system. Constellation is a proposal planned for implementation by Anza in the Agave client.

Read the Whitepaper
1234567891011121314ABCDEFGClient 1Client 2Client 31/11/21/31/41/51/62/12/22/32/42/52/63/13/23/33/43/53/6Proposer 1Proposer 2Proposer 31/12/13/11/22/23/21/32/33/31/42/43/41/52/53/51/62/63/6Attester 1Attester 2Attester 3Attester 4Attester 5Attester 6ConsensusLeaderConsensus PayloadAttester 1Attester 2Attester 3Attester 4Attester 5Attester 6Validator 1Validator 2Validator 3Validator 4PHASES1. Tx Submission2. Proposal3. Attester4. Consensus Leader5. Consensus Voting6. ReplayMESSAGESTransactionShredAttestationConsensus PayloadVoteMCP SPECIFICATIONDrawing: MCP-001ANZADate: 03/24/2026Interactive Diagram
PROTOCOL OVERVIEW

Cycles & Blocks

Users send transactions to one or multiple proposers. During each cycle (50ms), each proposer includes a set of transactions and sends erasure-coded pslices as pshreds to the attesters.

Each attester timestamps and forwards all pshreds to the leader, accompanied with an attestation. Per cycle, the leader compiles all transactions with enough attestations that fit the sequential compute limit of a batch.

The batches of all cycles of one slot constitute the payload of the leader's block. Validators check correctness and vote via Votor.

AttestersAtt. 1Att. 2ΔcycleΔblockConsensusLeader012Validators012ΔtimeoutcycleblockParentReady
INTERACTIVE DEMO

Aggregate Attestation Matrix

Constellation relies on erasure coding, the same underlying technology that powers Turbine, to guarantee censorship resistance. If enough attesters have seen shreds for a proposal, it MUST be included in the next execution cycle. To see how this works, toggle attestations to see which proposer blocks are included.

Example 1
Happy path
AGG ATTESTATION VALID
P0
P1
P2
P3
P4
Included
P0 0
P1 0
P2 0
P3 0
P4 0

Each column is an attester. Each row is a proposer. Toggling a cell represents an attester attesting to that proposer’s commitment. Click an attester header to enable/disable that attester’s attestation column without forcing every proposer to be attested. The block is skipped if attester attestations fail the 60% threshold. If a proposer misses the 40% threshold, only that proposer’s block is excluded.

Example 2
Double-sign detected
AGG ATTESTATION INCLUDED
Proposer P2 signed two conflicting block IDs for the same slot. Drop that proposer’s block regardless of attestation count.
R0
R1
R2
R3
R4
R5
R6
R7
P0
P1
P2
P3
P4
Included
P0 1
P1 1
P2 0
P3 1
P4 1
Yellow and blue highlight two different attesters reporting different valid signed shreds for the same proposer. The equivocation removes that proposer from the aggregate.
SIMD-0322 ↗
Serial Execution Replay Constraint
Once transactions are included, they are ordered by priority fee per CU and then assigned to a virtual parallel execution schedule that ensures we do not create blocks that take too long to replay. If transactions don't make it into the virtual execution schedule in the current cycle, they can be automatically passed on to the next execution cycle where there may be room for inclusion.
03.8M7.6M11.5M15.3M19.1M22.9M26.7M30.6M34.4M38.2Mtrack 0(114 txs)track 1(127 txs)track 2(147 txs)track 3(112 txs)Compute Units (CU)
MCP ProtocolSetup
1 / 19
Phase 0: Setup
CHANGE ORDER
CO-001

Protocol constants

SUMMARY

The constellation protocol calls for 16 proposers, 256 Attesters and a single leader in each slot. Attesters act as a timeliness comitee on a 50ms wall clock cadence. Each validator has a local sychronized clock that they use for attestation timings and only for attestation timings. The rest of the protocol does not rely on this synchronized wallclock at all.

Use to navigate
Setup