Introduction
We believe the Constellation whitepaper is the most structurally ambitious upgrade proposed to Solana* since the network launched. It is also, in its current form, a proposal that departs from its own academic foundations, defers its hardest technical problems to future work, and introduces a set of costs that have not been quantified against the alternatives Anza itself is already shipping.
Our position is direct. We support Multiple Concurrent Proposers as a direction. We do not support the current specification advancing to a SIMD vote without five specific gaps being closed first.
This is not a rejection of the proposal. Censorship resistance is a first-class property worth paying for, and the work Anza’s research team has done to bring a formal MCP design to a production network at Solana’s scale is genuinely significant. Our concerns are targeted. Each gap we raise is addressable. None of them have been addressed yet.
What follows is our analysis of what Constellation solves, what it leaves open, and what the SIMD process needs to deliver before this proposal is ready for the community’s vote.
Leader-Proposer Collusion Is an Unresolved MEV Vector
Under Constellation, a validator controlling meaningful stake will frequently hold both the proposer and leader roles in the same cycle. The combination creates extraction opportunities that did not exist under the single-leader model.
The math is simple. A validator with 5% of stake is the block leader roughly 5% of the time. With 16 active proposer slots, that same validator is a proposer in nearly every cycle. When the leader role and a proposer role land on the same entity, which for any meaningfully-staked actor is the modal case, that entity can see transactions flowing into its own pslice, observe competing front-run attempts it is also carrying, and push those competitors into cycle C plus one while slipping its own front-run into cycle C for the cost of a basic inclusion fee. The back-run lands in the same cycle. The user is sandwiched. The extraction is invisible to block validity rules because no censorship occurred. The competing transactions all got included, just one cycle too late.
Anza’s current answer to this attack is that tight infrastructure latencies will make it logistically difficult in practice. Brennan Watt has publicly acknowledged the concern, stating that Anza will need to make those latencies tight enough that this kind of extraction becomes hard to pull off. That is not a specification. It is an operational assumption that depends on network conditions the SIMD does not currently constrain.
Rational MEV economics plus stake-weighted role selection plus the absence of an explicit separation rule means leader-proposer overlap is the default outcome, not an edge case. Even if a protocol rule attempted to prevent same-entity overlap, side deals between cooperating entities would recreate it. The attack surface does not close.
The SIMD needs to address leader-proposer overlap explicitly. The viable paths are a protocol-level separation rule, a commitment to a hiding roadmap that removes the informational asymmetry, or a specified statistical slashing framework for detectable cross-cycle timing anomalies. The current design relies on none of these.
The Fee Mechanism Regresses From a Published Alternative by a Constellation Co-Author
Under the current whitepaper, a user who submits a transaction to n proposers for redundancy pays the inclusion fee n times. The stated justification is that each proposer independently performed the work of inclusion. On its face this is reasonable. It also happens to be the opposite of the transaction fee mechanism already published for exactly this problem.
Fox, Pai, and Resnick (2023), Censorship Resistance in On-Chain Auctions, proposed a conditional-tip TFM specifically designed for multi-proposer systems. Max Resnick is also a co-author of Constellation. Under the Fox-Pai-Resnick construction, a user submits a pair of bids (t, T) with t much less than T. If k proposers include the transaction, it pays kt, split among them. If only one proposer includes it, it pays T to that single proposer. The asymmetry creates a prisoner’s dilemma among proposers. Any single proposer can unilaterally break from a censorship attempt to capture T, so the cost to successfully censor a transaction grows with k while the expected cost to the user stays close to t.
Constellation’s flat n-times inclusion fee does the reverse. It punishes redundancy, which means rational users will under-submit, which means the effective active proposer count for any given transaction collapses toward one in practice. The censorship-resistance guarantee Constellation advertises is predicated on redundant submission. The TFM it currently specifies discourages it.
This is a live design question. Anza has stated publicly that the fee mechanics are underspecified in the current whitepaper and will be expanded in the SIMD. That makes this the moment to raise it.
The ask is narrow. The SIMD should either adopt the Fox-Pai-Resnick conditional-tip TFM or a direct variant, or publish a written justification for why a flat n-times inclusion fee is correct given the published alternative from Constellation’s own co-author. This is the cleanest technical ask available. It does not require disagreeing with Anza’s goals. It only requires disagreeing with the current execution of those goals.
Partial Hiding Is the Root Cause of Both Layer 2 and Layer 3 Attacks
Constellation ships partial hiding. The receiving proposer sees transaction plaintext. The leader sees everything after the cycle deadline. Anza has confirmed that threshold encryption and similar cryptographic hiding primitives are not in scope for the initial proposal.
The academic paper Constellation itself cites as its north star, Garimidi, Neu, and Resnick (2025), Multiple Concurrent Proposers: Why and How, proves that full hiding is achievable using Hiding Erasure-Correcting Codes combined with vector commitments, and that the construction adds one additional network round-trip after optimizations. Not an order of magnitude of latency. One round-trip.
The consequences of shipping partial hiding are material. Decentralizing the proposer set without addressing content visibility means every proposer a user routes to is an additional party who can sandwich them. The path dependency of information, from user to proposer to attesters to leader, creates multiple leak points where a single-leader system had one.
More importantly, partial hiding is the root cause of the timing manipulation problem the whitepaper already acknowledges is unsolved. The reason leader-proposer collusion is profitable is that the leader sees transaction content and can identify which transactions to selectively place in which cycles. If the leader cannot see content before ordering is committed, the economic incentive to selectively delay specific transactions largely disappears. Hiding addresses Layer 2 and Layer 3 simultaneously, which is exactly why the academic construction pursues both properties together.
Meanwhile, Jito’s* Block Assembly Marketplace is positioned to fill the hiding gap off-protocol using Trusted Execution Environments. By the time Constellation ships without a hiding roadmap, the privacy layer on Solana will be controlled by a single off-protocol actor and rooted in Intel and AMD trust assumptions. Anza either owns hiding in the protocol or cedes it permanently to an application-layer provider.
The SIMD should include a phased hiding roadmap with explicit trigger conditions for migrating from partial hiding to the HECC-based construction. If the engineering judgment is that full hiding cannot ship in v1, the roadmap should state what concretely must be true, including attester count, median round-trip time, and implementation maturity, before it does. Indefinite deferral is not acceptable for a protocol positioning itself as the infrastructure of Internet Capital Markets.
The Latency Cost Is Material and the Comparison Baseline Is Wrong
Constellation adds latency on the critical path for transaction observation. Anza has stated that shred observation latency under Constellation increases by approximately 75 milliseconds compared to well-behaving validators today. This is not in the noise. It is a material cost on a metric that market makers and trading infrastructure care about directly.
A fix is already on the table. Under “quick release,” attesters forward shreds directly to the cluster rather than funneling them through the leader. This trades a 2x bandwidth increase for eliminating the latency regression. Anza has publicly acknowledged that this is a live configuration choice and that community feedback will determine which way it lands.
Our view is that the community should push for quick release as the default. Bandwidth is abundant on modern validator infrastructure, particularly on DoubleZero-class networking. Seventy-five milliseconds of additional shred observation latency on the critical path to market makers is not. The sequence-latency-versus-inclusion-latency debate becomes much easier to resolve if the proposal adopts quick release. Inclusion latency improves, shred observation latency holds or improves, and the only cost is bandwidth overhead that the infrastructure is built to absorb.
The second problem is the comparison baseline Anza has been using. The 75-millisecond figure is relative to well-behaving validators today, a baseline that does not include the Alpenglow improvements Anza itself has already committed to shipping. 200-millisecond slots and two-slot leader windows are scheduled for the 4.1 release, before Constellation. Those improvements are not contingent on Constellation. They reduce the single-leader monopoly window substantially on their own.
The question the SIMD has to answer is not “Constellation versus today.” It is “Constellation versus Alpenglow with 200-millisecond slots and two-slot leader windows.” That is the marginal complexity and the marginal benefit that matter. Nobody has published those numbers, and without them the tradeoff cannot be evaluated.
The SIMD should include quick release as the default configuration. Anza should publish a full latency comparison table before the vote. The table should cover proposer acknowledgment, shred observation, and finalization latencies across five configurations: today’s median validator, today’s Byzantine-actor subset of stake, Alpenglow with 200-millisecond slots alone, Alpenglow plus Constellation as currently specified, and Alpenglow plus Constellation with quick release enabled. Without this table the SIMD is not votable in good faith.
The N-Choose-16 Defense Does Not Survive VaaS Concentration
The cleanest pro-Constellation framing on decentralization is n-choose-1 versus n-choose-16. Under single-leader, the odds of any entity being the block producer for a given slot are 1 over n. Under Constellation, they are 16 over n. More entities participate in block construction per unit time. This is a real improvement. We concede the point.
It does not survive contact with how Solana stake is actually distributed.
Both proposer and attester selection are stake-weighted. Solana stake is geographically concentrated and, increasingly, operationally concentrated through Validator-as-a-Service offerings where a single entity routinely operates many high-stake validators under nominally independent identities. With 16 active proposer slots and a VaaS operator holding 25% of stake, that operator expects roughly 4 simultaneous slots on average. The censorship-resistance guarantee assumes those 16 are independent. In any realistic production deployment, a non-trivial fraction will not be.
The sharper version is on the attester side. The whitepaper specifies that at least 60% of attesters must participate for the aggregate attestation to be valid, and that any pslice attested by at least 40% must be included by the leader. A coordinated bloc above 40% of attester stake can selectively withhold attestations from a target pslice, dropping it under the inclusion threshold without producing any individually malicious act. A bloc above 40% can also force block skips at will. This is censorship laundered as liveness failure, and it is invisible to the structural guarantee the protocol advertises.
We accept that naive anti-concentration mechanisms are gameable. A simple stake-decay rule incentivizes entities to split into multiple identities, which solves nothing. The answer is not to pretend the concentration problem is solved. The answer is to specify, measure, and defend.
The SIMD should specify three things. First, an operator-uniqueness or geographic-diversity component in proposer and attester selection, even if imperfect. Second, a published effective-independence metric for the active proposer set per cycle, tracked as a first-class network health metric the way reorg rates are tracked today. Third, a justification of the 40% and 60% thresholds against realistic worst-case collusion fractions rather than idealized stake distributions. The thresholds may be correct. They need to be defended with numbers.
Runtime Constraints Still Create a Delivery Problem
Constellation assumes that once a transaction has been proposed and attested, the remaining question is mostly whether it can fit inside the current cycle. In practice, Solana’s runtime constraints are much more complicated than that.
A leader still has to assemble transactions inside finite compute limits, writable-account limits, replay limits, account lock limits, and packet size constraints. Multiple proposers can independently include transactions that are all valid on their own but difficult or impossible to schedule together once they are merged into a single cycle batch. The harder the network is pushed, the more this becomes a constrained packing problem rather than a simple inclusion problem.
This matters because Solana already has a long history of user frustration around transaction delivery during periods of congestion. Users have repeatedly seen transactions fail, land late, require multiple retries, or require unexpectedly large priority fees just to get into a block at all. Constellation may improve censorship resistance, but it does not necessarily make delivery more deterministic.
In fact, it may make delivery more conditional from the user’s perspective. Today, the user mostly thinks in terms of whether their priority fee was high enough to get scheduled. Under Constellation, that same user can pay a high priority fee, get included in a proposer’s pslice, get attested on time, and still lose because the final cycle batch becomes too difficult to schedule when combined with other transactions.
A transaction may be individually valid and still lose because too many other high-fee transactions touched the same hot account, consumed too much block compute, or created too many write-lock conflicts once everything was packed together. That means users may end up paying not just for priority, but for scheduler compatibility with every other transaction in the cycle.
The result is that transaction delivery becomes less binary and more uncertain. Instead of asking “did I pay enough to get into this block?,” users may have to ask “did I pay enough, did my proposer get enough attestations, did my transaction fit into the final cycle budget, and did it avoid conflicting with the other high-fee transactions in the same cycle?”
That is not necessarily a reason to reject MCP. But it is a real user-facing tradeoff that should be acknowledged. Constellation may increase the probability that a transaction is eventually observed, while simultaneously making it harder for users to predict exactly when that transaction will actually execute.
The Empirical Motivation Problem
Running through every one of the above is a meta-critique that deserves direct statement. The current Constellation paper has no empirical motivation.
The economic claims about single-proposer MEV harm are not supported by data. There is no analysis of how much extraction actually occurs on Solana today. There is no projection of how much Constellation prevents. There is no modeling of the residual extraction surface the proposal leaves open. There is no benchmark against which to judge whether the proposed tradeoffs are worth it. The financial applications Constellation is designed to enable, including onchain auctions, order books with hard inclusion guarantees, and censorship-resistant DeFi primitives, largely do not exist at scale on Solana today. The trading applications that do exist, and that will bear the costs of the proposal, are well-documented and measurable.
Alessandro Decina has publicly argued from inside Anza that the proposal over-indexes on users who do not yet exist at the expense of users who do. That debate is unresolvable without numbers.
We believe this is the cheapest ask for Anza to satisfy. It is also the most important for the community to demand. Before the SIMD goes to vote, the motivating economics need to be quantified, not projected.
What the SIMD Needs to Close
The asks collapse into a single list.
First, address leader-proposer overlap explicitly, either through a separation rule, a commitment to hiding, or a specified statistical slashing framework. Operational assumptions are not specifications.
Second, either adopt the Fox-Pai-Resnick conditional-tip TFM or publicly justify departing from it. The alternative was published by a Constellation co-author.
Third, include a phased hiding roadmap with explicit trigger conditions. The HECC construction adds one round-trip. Indefinite deferral cedes the privacy layer to off-protocol actors.
Fourth, adopt quick release as the default, and publish the full latency comparison table across all five configurations. Seventy-five milliseconds of shred observation latency is not in the noise.
Fifth, specify anti-concentration mechanisms in role selection, publish an effective-independence metric, and defend the 40% and 60% thresholds against realistic collusion fractions.
And underneath all five, publish the empirical motivation. Show the extraction that Constellation prevents. Show the extraction it leaves open. Show the cost.
Conclusion
Constellation can become the proposal it wants to be. The version currently on the table is not that proposal yet. The SIMD is where the gap gets closed, or it doesn’t.
We believe Solana deserves the harder version.
This analysis draws on the Constellation whitepaper by Kniep, Resnick, Sliwinski, and Wattenhofer; Garimidi, Neu, and Resnick’s MCP paper, Multiple Concurrent Proposers: Why and How; Fox, Pai, and Resnick’s conditional-tip TFM paper, Censorship Resistance in On-Chain Auctions; Landers and Marsh’s MEV in Multiple Concurrent Proposer Blockchains; Helius’s analysis, Constellation: A Proposal for MCP on Solana; and ongoing public discussion across the Solana research community.
* Anagram Ltd. and its affiliates may have interest in companies or projects that are written about in this space. This content is for educational purposes only and does not constitute advice, marketing or solicitation for funding. Please see the disclaimer below for more information.
Legal Disclaimer
The information in this article has been prepared by Anagram Ltd. (“Anagram”) for educational and informational purposes only. Under no circumstances should this, or any post on this website, be construed as solicitation for investment in Anagram, its affiliates, or any projects named herein or otherwise. The contents herein, and content available on any associated distribution platforms, including Anagram online social media accounts, should not be construed as or relied upon as investment, legal, tax, or other advice.Certain information contained herein, including in charts and graphics, may have been obtained from third parties. While such sources are believed to be reliable, Anagram does not assume any responsibility for the accuracy or completeness of such information. No assurance is made by Anagram regarding the accuracy or completeness of the information or opinions set forth herein, whether or not obtained from third parties, and Anagram shall not be liable therefor. Certain statements herein are based on subjective beliefs, may differ from the views of other market participants, and are subject to change.This presentation contains “forward-looking statements,” which can be identified by the use of forward-looking terminology such as “may”, “will”, “should”, “expect”, “anticipate”, “project”, “estimate”, “intend”, “continue” or “believe” or the negatives thereof or other variations thereon or comparable terminology. Due to various risks and uncertainties, actual events or results may differ materially and adversely from those reflected or contemplated in the forward-looking statements.Anagram and its affiliates may consult, invest, build, or otherwise have interest in companies or projects that are written about in this space. This content is for educational purposes only and does not constitute advice, marketing or solicitation for funding.