Solana Validator Operator Asks to Halve the Validator Admission Ticket to 0.4 SOL as SFDP Support Shrinks

A Solana validator operator has asked for the Validator Admission Ticket, the fee every validator pays to take part in consensus, to be cut in half. The request, opened on 10 November 2026 as discussion #730 in the Solana Improvement Documents repository by ansel, who ran the Tokamai validator, would take the ticket from 0.8 to 0.4 SOL per epoch. It lands as the Solana Foundation cuts back its delegation program, and on 11 November it drew replies on X from Anza engineer Alessandro Decina and Solana co-founder Anatoly Yakovenko (toly).

What discussion #730 proposes for the Validator Admission Ticket

The Validator Admission Ticket (VAT) replaced vote fees when Alpenglow went live on mainnet on 21 October 2026. Votes no longer travel as paid transactions, so each validator in the voting set instead pays a flat charge from its vote account every epoch, and the whole amount is burned. SIMD-0357, written by Wen Xu and Roger Wattenhofer of Anza, set it at 1.6 SOL per epoch to match the old cost of voting and to reduce "the likelihood there are too many voting validators."

SIMD-0525, by Brennan Watt of Anza, then scaled the ticket down with each slot-time step to keep it at "roughly 0.8 SOL per day." Solana has run at the last of those steps, 200ms slots, since 9 October 2026. The ask in #730 is one line: "VAT × 0.5 at every slot-time stage in SIMD-0525. At today's 200ms stage that's 0.8 → 0.4 SOL per epoch."

Only the 200ms row applies on mainnet today; the other halved values are the same arithmetic applied to SIMD-0525's table. The proposal is at the first stage of the process. It is a GitHub discussion, which ansel calls a draft SIMD, and "#730" is the thread number. It has no SIMD number, pull request, feature gate or vote yet.

Why the SFDP changes put the VAT in focus for small validators

The timing comes from the Solana Foundation Delegation Program (SFDP). Its new rules took effect on 6 November, limiting membership to 12 months and 100 validators at a time. Layer33, a group of independent validators, asked the Foundation to pause the weekly retirement of existing members, and the Foundation's Jacob Creech said the program "has done its job".

Ansel has a stake in the outcome and says so. In his thread on 11 November he wrote that he paid $500 a month for six months to test Alpenglow, that the Foundation cut his SFDP stake a few weeks after it shipped, "And I absolutely agree with the move. Directionally." He counted 337 validators in the program when the new rules arrived, "roughly half the network, kept alive by ~5% of staked SOL."

His argument is that the VAT now decides whether smaller validators survive. The ticket is flat, "whether you hold 5k SOL or 5M," and ansel argues the 2,000-validator cap that Alpenglow already places on the voting set does the job of limiting its size. Solana Compass's staking data counted 699 validators with active stake at epoch 1083 (10 November), a figure that held between 691 and 699 through the week the new SFDP rules took effect. In a follow-up post, ansel wrote that he "would rather we keep 150 of the 350 SFDP valis with decentralized stake and let the SFDP stop."

Ansel's validator P&L and the cost of a 0.8 SOL ticket

Discussion #730 opens with ansel's own books for two years on mainnet. By his accounting the validator earned 1,144 SOL, mostly block fees (772 SOL), and spent 790 SOL on vote fees, 239 SOL of which the SFDP covered in year one, plus 265 SOL on servers. That left 329 SOL over two years, with year two at -0.7 SOL. Almost all of that period came before Alpenglow, so those costs were vote fees rather than the VAT.

On his figures, halving the ticket takes a validator's yearly cost from 292 to 146 SOL. The stake a 5%-commission validator needs to cover the ticket from inflation commission falls from about 112,000 to about 56,000 SOL. The network would burn about 102,000 SOL a year less, "about 0.45% of annual issuance."

Those yearly numbers assume one epoch a day. Solana Compass's epoch data shows 200ms-stage epochs running about 25.7 hours (an average slot of about 214ms), so a validator pays the ticket about 340 times a year: roughly 273 SOL today and about 136 SOL halved. Our guide to validator revenue and costs uses different assumptions and puts the stake needed to cover the ticket at about 40,000 SOL.

What Anza's Alessandro Decina and toly said about rewards compute and the ticket

Decina, who works on Agave performance at Anza, replied to ansel's thread on 11 November that "this number is completely made up with literally zero reasoning grounded in reality," without saying in that post which number he meant. He went on: "It's already pretty costly to compute rewards on each block as things stand now (about 3ms - cutting this number down (from 15-20ms) is why we had to rush one last release before the switch) having said that, carry on." He then advised ansel to "drop the 2k framing, just say it's expensive, which it probably is."

Yakovenko answered directly. His post called the VAT "the made up one. It's synthetic," and said that if an implementation bug stops the ticket being lowered when people ask for it, the bug should be fixed. Decina quote-replied "we agree" and added that the rewards update was built on existing vote-state code to ship fast: "we can bring this <1ms as it is, and then akhi is already sketching a new mechanism."

Anza wrote the Alpenglow SIMDs and ships the Agave client that computes these rewards, so Decina was speaking as one of the engineers who would build any change. Neither post named a new value for the ticket, and both replies came on X. As of the afternoon of 11 November, the only reply in the GitHub discussion was from user Devour6: "I am in full support."

Next steps for discussion #730 in the SIMD process

Under the SIMD process, an idea moves from discussion to a draft pull request, whose number becomes the SIMD number. It then goes through review by core contributors and acceptance, followed by client implementation and a feature gate before activation. Ansel's thread describes the change as "1 constant table behind a feature gate," the same form SIMD-0525 used. No one has filed that pull request, and no client team has committed to a schedule.

The things to watch are whether a numbered SIMD appears, whether the per-block rewards work Decina described lands first, and how many operators answer ansel's request in #730 to "reply with your own numbers." The validator count, flat at about 700 so far, will show how the SFDP retirements play out in weekly tranches.