Two Solana Foundation researchers have published a design that would let three validators build every Solana block together, with no leader. New Constellation, version 1.0 of a whitepaper by Quentin Kniep and Roger Wattenhofer dated 14 November 2026, adds multiple concurrent proposers (MCP) to Alpenglow, the consensus protocol Solana switched to on mainnet on 21 October.
Wattenhofer, an ETH Zurich professor who led the research team at Anza when it formed in 2024, posted the paper on X late on 14 November with the slides from his talk at Scale or Die, the Solana Accelerate technical summit held in London the day before Breakpoint 2026. Both files sit in a public GitHub repository.
New Constellation is a research paper. It has no Solana Improvement Document (SIMD) of its own, no implementation and no activation date. The paper does cite two companion proposals by the same authors, SIMD-0674 (validator location registration) and SIMD-0675 (a geography-aware leader schedule), as open pull requests.
How New Constellation differs from Anza's March Constellation proposal
The name needs untangling first. Anza published a different protocol called Constellation on 25 March 2026, with Kniep and Wattenhofer among the whitepaper's authors. The new paper's footnote says earlier drafts of the new protocol were called Spectral and were renamed Constellation "for marketing reasons", and that its design "differs fundamentally" from the March protocol. Inside the paper, the March design is called Legacy Constellation and the new one New Constellation.
Anza's March design was "a preprocessor to Alpenglow": proposers send transactions to attesters, which timestamp them and pass them to a leader that must build each batch from attested transactions. A Helius hSOL$84.17-6.9% explainer on that design puts it at about 16 concurrent proposers and 256 attesters. The new paper's own comparison lists what changes:
| Property | Constellation (March 2026) | New Constellation (November 2026) |
|---|---|---|
| Who assembles the block | A leader, constrained by attesters | Nobody: proposer blocks are merged by a fixed rule |
| Attesters | A separate attester layer | None; proposers vouch for each other's timing |
| Synchronised clocks | Required | Not required |
| Block and transaction hiding | No | Yes |
| Extra network hop | Yes, via attesters | No |
| Slot length | 50ms | 50ms |
| Ordering | By priority fee | By priority fee |
How three concurrent proposers build one Solana block every 50ms
Under New Constellation, every slot lasts 50 milliseconds and several proposers each build a block at the same time: the paper proposes three, starting with two or three and adding more later. Validators merge the accepted blocks into one order, sorted by the priority fee each transaction pays per unit of compute, so no proposer decides what comes first. The paper says jumping the queue "is expensive, since one has to outbid a transaction".
Each proposer encrypts its block as it streams it out. When a proposer finishes its block, it sends a signed fingerprint of that block (a hash) to the other two. Only after the hashes are swapped does each proposer reveal the key that unlocks its own block. That ordering means no proposer can see the others' transactions before its own block is fixed. Users can also split a transaction into encrypted pieces across several proposers, which the authors describe as "only partial" protection.
The headline claim is censorship resistance: unless a slot is skipped, a transaction needs only one honest proposer among the three to be included.
Validators still vote only every 200ms, four slots at a time, so Alpenglow's voting rounds do not multiply. With three proposers, one can crash without the slot being lost, and a proposer that is late or signs two different versions of its block can be identified and, for double-signing, proven at fault.
What co-location hubs would mean for Solana validators
The biggest change for operators is geography. The three proposers in any 800ms window must sit within about 10ms of network delay of each other, roughly the same city. The paper calls these groups hubs. Anyone can register a hub on-chain, and it becomes active once enough validators and stake join. Validators outside an active hub would still vote but would not propose blocks.
The authors estimate how much stake is not near a hub today, using IP geolocation of the 30 largest validator locations on 30 October 2026. With a generous 25ms limit and a 1% minimum stake per hub, 1.2% of stake would sit outside any hub. At the proposed 10ms limit with the same minimum, the figure is 3.7%. With a 5% minimum stake per hub, it rises to 10.4%.
The paper suggests starting with three or four hubs in New York, Frankfurt, Tokyo and London. Stake today is lopsided: the paper puts 46% of stake closest to Frankfurt and 27% closest to London (which includes Amsterdam), against 9% for New York and 5% for Tokyo. To stop one city dominating, half of the windows would be shared out by hub stake and half evenly across active hubs. A validator's proposing weight would be capped at a third of its hub's stake, and the authors write that a large validator "gains nothing from concentrating its stake in one hub".
MEV, open problems and Solana's current block market
Today a single leader controls each slot's ordering, and the paper argues that proposer-builder separation "optimizes and redistributes MEV rather than removing the harm to users". On Solana, much of that market runs through tips paid via Jito JTO$0.268-9.0%, on top of normal fees, to get transactions included and ordered. Jito tips ran between about 890 and 1,600 SOL a day over 1-14 November, roughly 18,900 SOL in total, according to Solana Compass fee data. The paper does not discuss Jito or how New Constellation would interact with it.
Jito tips paid on Solana ran between about 890 and 1,600 SOL a day in early November.
View on Solana Compass โThe authors list what the design leaves open. A malicious proposer can force the rest of a window to be skipped by sending conflicting signals to its co-proposers. The fee mechanism, including a new inclusion fee paid to proposers, is "left to future work". Letting hubs in several cities propose at once, which would put a proposer near users everywhere, is a direction whose "details, however, are far from clear". Fee payers would also need to keep a small reserve, such as 0.001 SOL, to cover fees proposers cannot yet see.
New Constellation joins other Solana MCP research, including the Gatling protocol published in June. Things to watch: whether SIMD-0674 and SIMD-0675 progress, how client teams and validators respond to the hub requirement, and whether either Constellation design becomes a formal SIMD with an implementation.
